ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathieu Lirzin <mathieu.lir...@nereide.fr>
Subject Re: PortalPage / Portlet / parameters : SGBD versus XML file
Date Sun, 29 Dec 2019 10:36:26 GMT
Hello Olivier,

Olivier Heintz <holivier@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

Mime
View raw message