[gatein-dev] Layouts and In Place Editing [was Re: GateIn 4.0.0]

I dropped some ideas for the layout technical specification in this document: https://docs.google.com/document/d/1Y9CtdMytJ5VVUzSmhooJXJxTPy0SpXlfqAn9P... This document aims to define the technical part in relationship with the "In Place Editing" spec : https://community.jboss.org/wiki/InPlaceEditing I wanted at least to drop the relationship between grid system (and more abstract typographic grid) and the nested layouts. Please forgive the usage of gdocs but for now it's here as it is a WIP, later it will go in wiki as well. The doc is open for comments and the gatein-dev list is a good place to discuss this. On Jan 23, 2013, at 5:23 PM, Nick Scavelli <nscavell(a)redhat.com&gt; wrote: > > Thanks Julien, awesome work so far. Looking forward to 4.x > > On 01/23/2013 11:05 AM, Julien Viet wrote: >> >> As I think it is important to explain I blogged about it there: >> >> http://www.dzone.com/links/gatein_40_development.html >> >> >> On Jan 23, 2013, at 12:07 AM, Julien Viet <julien(a)julienviet.com&gt; wrote: >> >>> >>> actually 5: reimplement the NG service **persistence** using the in >>> memory store and validate it with the tests decoupled from Step 3. >>> >>> persistence are quite low level and easy to implement, for instance: >>> >>> https://github.com/gatein/gatein-portal/blob/4.0.0/component/portal/src/m... >>> >>> and also I repackaged the NG services to org.gatein.portal.mop >>> >>> On Jan 23, 2013, at 12:03 AM, Julien Viet <julien(a)julienviet.com&gt; >>> wrote: >>> >>>> >>>> Hi, >>>> >>>> here is a status update with a milestone reached. The ram >>>> persistence and the data import are working which is a good news, >>>> let me explain the details here: >>>> >>>> The goal is to get rid of DataStorage interface for many reasons. >>>> A few services have been developed for 3 years with goal to >>>> supplement it one day: NavigationService, DescriptionService and >>>> PageService . They have all been developed to fix a particular >>>> issue with DataStorage (performance or scalability). So a few >>>> things were still managed by the DataStorage : sites and layouts. >>>> >>>> -------------------- >>>> >>>> Step1: extraction of the framework used in the NavigationService >>>> that is very powerful for managing hierarchy synchronization (i.e >>>> load/update/rebase/save) and make it generic enough for reuse. >>>> Added a couple of missing features on it. >>>> >>>> Step2: new services have been created to replace to finish this >>>> replacement : SiteService for managing sites (similar to >>>> PageService) and LayoutService that takes care of loading the >>>> layout of a page or a site. (consider a layout as an attachment of >>>> a navigation node or a page). Those services have been implemented >>>> with existing MOP and the goal was to make nearly all existing >>>> module pass. Only tests for dashboard do not pass because the >>>> dashboard impl is a hack that should not survive a long time (but >>>> persistence is very fine). The SiteService is quite trivial >>>> (pretty much like PageService). The LayoutService was also trivial >>>> because of the reuse of the Step 1 (which is a **big** win). >>>> >>>> Step3: all the NG services have been decoupled from MOP >>>> introducing an abstraction layer (SitePersistence for SiteService, >>>> PagePersistence for PageService, etc…). At this point the NG >>>> services tests are decoupled too. >>>> >>>> Step4: code an in memory store for ram storage . >>>> >>>> Step5: reimplement the NG services using the in memory store and >>>> validate it with the tests decoupled from Step 3. >>>> >>>> Step6: now there is still some work on the import of data. It must >>>> be decoupled from the UserPortalConfigService because it is legacy >>>> and nearly fix it. The import code was decoupled from the >>>> NewPortalConfigListener (a component plugin of >>>> UserPortalConfigService). Then a new class wrapping this has been >>>> created for importing data. >>>> >>>> Step7: update the web portal created 2 weeks ago to boot it (with >>>> Arquillian of course) >>>> >>>> -------------------- >>>> >>>> So the good news is that it works fine and is reliable enough for >>>> continuing the web portal development. >>>> >>>> The boot is fast enough for providing productivity, running a >>>> single test takes 5 seconds on my laptop: >>>> 1/ web server boot >>>> 2/ data import >>>> 3/ juzu boot >>>> 4/ invoke a controller with selenium >>>> >>>> For the fun here is a snapshot of the content of the ram store I >>>> made for checking the entire content was loaded : >>>> https://gist.github.com/4599534 >>>> >>>> Julien >>>> >>>> On Jan 16, 2013, at 2:18 PM, Bolesław Dawidowicz >>>> <boleslaw.dawidowicz(a)gmail.com&gt; wrote: >>>> >>>>> >>>>> Sounds good >>>>> >>>>> On Wed 16 Jan 2013 02:07:31 PM CET, Julien Viet wrote: >>>>>> >>>>>> I was thinking about renaming the services those services to use >>>>>> the org.gatein package: >>>>>> >>>>>> NavigationService, PageService, DescriptionService and the new >>>>>> LayoutService and SiteService >>>>>> >>>>>> WDYT ? >>>>>> >>>>>> On Jan 16, 2013, at 11:46 AM, Julien Viet >>>>>> <julien(a)julienviet.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> it is not possible because the data model is simplified >>>>>>> according to the InPlaceEditing spec >>>>>>> (https://community.jboss.org/wiki/InPlaceEditing) >>>>>>> >>>>>>> On Jan 16, 2013, at 10:35 AM, Thomas Heute <theute(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> Thanks for the update ! >>>>>>>> >>>>>>>> Does some of that work could be incorporated into incremental >>>>>>>> 3.x releases ? >>>>>>>> >>>>>>>> Thomas >>>>>>>> >>>>>>>> On 01/15/2013 04:24 PM, Julien Viet wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> here is a short update. >>>>>>>>> >>>>>>>>> Focusing on the services for data that are all JCR based, >>>>>>>>> which is an issue for testing the portal rewrite, so for now >>>>>>>>> focusing on improving this part. The goal is to have in >>>>>>>>> memory implementation of the services for testing purposes. >>>>>>>>> >>>>>>>>> At the moment I'm working on the rewrite of the remaining >>>>>>>>> legacy service DataStorage. This service has a strong >>>>>>>>> coupling to JCR, the new services introduced >>>>>>>>> (NavigationService, PageService, etc…) are coupled but not >>>>>>>>> that much. >>>>>>>>> >>>>>>>>> I started the LayoutService that focus on the layout aspect >>>>>>>>> of a UI structure and extracted code from NavigationService >>>>>>>>> for reusing in NavigationService. The DataStorage now uses it >>>>>>>>> for loading and saving pages. This is a good step forward. >>>>>>>>> >>>>>>>>> I'm keeping the DataStorage at the moment for two reasons: >>>>>>>>> >>>>>>>>> - we want to continue to use the normal gatein with webui for >>>>>>>>> a little while >>>>>>>>> - the data storage is heavily tested so the testing of the >>>>>>>>> underlying services through data storage is a good thing to have >>>>>>>>> >>>>>>>>> The next step is to write a SiteService that load and save >>>>>>>>> sites without their template. When it is done, the >>>>>>>>> DataStorage loading/saving PortalConfig will combine the >>>>>>>>> SiteService and the LayoutService for loading configs. >>>>>>>>> >>>>>>>>> Julien >>>>>>>>> >>>>>>>>> On Jan 7, 2013, at 3:51 PM, Julien Viet >>>>>>>>> <julien(a)julienviet.com&gt; wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just to let you know that I'm starting 4.0.0 in my github >>>>>>>>>> repository :-) >>>>>>>>>> >>>>>>>>>> Initial plan is to come with a basic implementation rapidly >>>>>>>>>> (1 month?) and then make it formal with a spec when it >>>>>>>>>> becomes complex but for now: >>>>>>>>>> >>>>>>>>>> - get away from UI component oriented programming and uses >>>>>>>>>> simple MVC programming >>>>>>>>>> - rely Juzu for the web application framework >>>>>>>>>> - uses javax.inject for IOC controllers and bridge with the >>>>>>>>>> kernel >>>>>>>>>> - uses Arquillian for developing with testing >>>>>>>>>> - reuses existing services (i.e stuff in components/*) >>>>>>>>>> >>>>>>>>>> For now dev is there >>>>>>>>>> https://github.com/vietj/gatein-portal/tree/4.0.0 but it can >>>>>>>>>> be moved to the gatein organization any time. >>>>>>>>>> >>>>>>>>>> The current stuff of course is quite empty but I hope it >>>>>>>>>> will become quickly something, but there is Juzu and >>>>>>>>>> Arquillian which are very productive. >>>>>>>>>> >>>>>>>>>> If you want to help, it's open for business! >>>>>>>>>> >>>>>>>>>> Julien >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the >>>>>>>> Google Groups "JBoss / eXo" group. >>>>>>>> To post to this group, send email to jbossexo(a)googlegroups.com. >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> jbossexo+unsubscribe(a)googlegroups.com. >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/jbossexo?hl=en. >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev