On Jan 23, 2013, at 12:07 AM, Julien Viet <julien(a)julienviet.com> 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> 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> 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>
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>
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> 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
>>
>>
>