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

Hi Matt, your feedback is important. can nail down your vision and experience on what responsive design should be in GateIn layout (i.e from this point of view and not from the layout editing point of view) in a document ?

thanks Julien On Feb 26, 2013, at 7:56 PM, Julien Viet <julien(a)julienviet.com&gt; wrote: > On Feb 26, 2013, at 7:22 PM, Matt Wringe <mwringe(a)redhat.com&gt; wrote: > >> >> On Tue 26 Feb 2013 11:14:36 AM EST, Julien Viet wrote: >>> On Feb 26, 2013, at 4:43 PM, Matt Wringe <mwringe(a)redhat.com&gt; wrote: >>> >>>> My biggest concern with this and in place editing is that its meant for people who don't know how to use css/html/js and just want a drag and drop solution. This makes it simple for them to do very simple layouts, but it becomes impossible to do anything outside of what we have decided is a "good layout approach". And if we want to add in new features later (like responsive layouts) it becomes more and more complex to it in a simple drag and drop application. >>>> >>> The "edit in place" is a front end for the underlying solution. It should not exclude what you are saying and I think that's what you propose to do below (advanced mode). This "duality" is a must have. >>> >>>> If a web designer can't jump in and make changes using the technology they already know (html/css/js), then there is a problem. I assume that most customers are probably going to have web designers anyways, since they will probably have at least one custom portlet/gadget. >>>> >>>> What I would really like to see is an 'advance mode' where I can specify the html, css and javascript for a particular container (note: not inline css like we currently do with the limited width/height approach, but add css and javascript to the page if containerXYZ is loaded. Like what currently happens with portlets). If I want to use media queries, or float one container inside another, there should be a way that I can do that easily by accessing and modifying the source. >>>> >>>> The advance mode should be the preferred way to handle anything more complex than a simple static row/column layout. I don't think we should handle responsive design in the drag and drop application, only through the advance mode. >>> We can handle responsive design in the drag and drop application by specifying how some items should behave with "responsive utility classes" (see there in bootstrap : http://twitter.github.com/bootstrap/scaffolding.html#responsive). >> Responsive utility classes in twitter bootstrap are used to specify if something should be displayed on a particular 'device' or not. This really has nothing to do with responsive design and is extremely limited in what it can do. > I think today the use case about responsive design configuration are not well known because we have a lack of feedback from customers: from RedHat customers AND from eXo customers (those customers don't have the same needs as we know). eXo customers usually needs a simple and powerful visual experience, Red Hat customers prefers to edit XML (joking). > > There is likely work to do in the responsive part, the "Edit In Place" specification was not written initially with that in mind. I will check with Benjamin Paillereau (perhaps he's reading that list too) on this item for the "Edit In Place" spec. I know he did some experiment recently with responsive design (http://blog.exoplatform.com/2013/01/24/juzu-day-3-the-coolness). > >>>> My other hope with a new layout approach is that we get rid of all the complexities in the html for the containers. Each container should ideally be just one div. Someone looking at the source for the page should see nice clean html code. >>> The new approach does not use anymore concept of nested containers but instead flat regions (pretty much like in JBoss Portal 2.x). The portal is responsible for translating those regions into a serie of div with the correct styles for performing the layout. >>> >>>> Is it possible to remove the shared layout and move everything there to the site layout? >>> There is a definitive need for shared layout. >> Why is there a definitive need for shared layout? I don't get why we need it when we could just add it to the site layout by default when a new site is created. > in early version of GateIn 3.x , the shared design was handled like you are suggesting and it was creating several issues: > > 1/ during site layout edition the toolbar was displayed (because it was part of layout): > - it creates a confusing UI experience > - it creates visual UI bugs > > 2/ usually the shared layout contains "meta user interface", i.e the toolbar which itself allows to enter or exit edit mode, perform login / logout, etc… it is obvious that this part should not be edited > > when we moved to shared layout, all those issues magically vanished. > >>>> I think that individual sites should be able to specify what they want instead of having to share it between all sites. Or at least give a site an option to disable the shared layout if they so wish. >>> That's a good option to what you said above. >>> >>>> On Mon 25 Feb 2013 06:39:06 PM EST, Julien Viet wrote: >>>>> 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 > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev