Hello Olivier, Olivier Heintz <holiv...@apache.org> writes:
> In OFBiz, > * definition of portalPortlets, > * definition and content of the portalPages (column and which portlet in > each one) > * portalPortlet attributes for a portalPage > * and some other details about the organization of the portal > are stored in the ofbiz database. > > As Nicolas says, it is not practical/advisable to manage/sharing GUI > changes in a development process (and continuous integration) because > they are not managed by a VCS (svn or git). I share the feeling that it is not advisable to store complex behavioral elements like screen configurations inside the database because of the number of moving parts, which given the lack of safety nets when developping OFBiz screens is likely to end up in hours of debugging. > So I propose to > * create a widget-portal.xsd I have no opinion regarding the pertinence of portal screens in term of UI/UX so I let others judge on that, I am just a bit worry about the growth of the catalog of screen/form/... elements which for unfamiliar UI developper like me is already daunting. In any case providing a precise XML schema for screen/form elements is definitely a good idea. > * a new general property to read (or not) the database for the > organization of the portal > > * some modifications on include-portal to read the portal > information on the xml file and if the property is Yes the > complementary elements in the database. > > With these modifications it will be possible to dynamically add > portalPage or Portlet and use editParam features when working with > ProductOwner/keyUser/endUser but not in a production environment. > > After the workshop, the consultant will have to formalize what has > been validated in the appropriate xml file and commit it in order to > have it in production environment if the GUI test are ok (the > modifications don't break anything ;-) I think the scenario of letting “ProductOwner/keyUser/endUser” design a screen to convey their expectations to developpers would be a nice thing to have. As I understand it, such requirement does not imply the need for a general mechanism allowing the portal configuration to be retrieved from the database which would result in adding a lot of moving parts. One idea would be to have a specific webtools screen taking the form of a client-side Javascript program allowing users to compose a screen graphically and to export it as XML. This would fit the scenario you describe without the need of adding a general screen configuration mechanism inside the database. What do you think? -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
