PortalPage / Portlet / parameters : SGBD versus XML file

[holivier]

Hello, community,

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).

So I propose to
  * create a widget-portal.xsd
  * 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 ;-)

What do you think about this ?

Olivier

[Mathieu Lirzin]

Hello Olivier,

Olivier Heintz <[hidden email]> 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

[Nicolas Malin-2]

Hello,

Ten years ago I would've leaned over on a solution to improve on this way, but now with practical field experience I understood that it was a chimera on business production site.

All is currently present on screen-widget.xsd to define easily a screen structure.

The scenario “ProductOwner/keyUser/endUser” is already supported, I didn't hear at Néréide for functional developer that they are some difficulties to translate business specifications from any of these roles through screen definition.

Rather than concentrating on adding model layers, we will win not to let the code grow too much and identify what is really missing on screens and rely on portal page only for cases where the end user can edit his own configuration page.

I'm more in favor to put away all current portal page out of the framework, keep only one plugin as example and convert them with good practice to help other developers and functional developers to extend the framework.

In this way I found the Mathieu's below idea: fun :)

Nicolas

On 29/12/2019 11:36, Mathieu Lirzin wrote:

Hello Olivier,[...]

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?

[holivier]

Thank you Mathieu and Nicolas for your remarks
They help me identify the highest priority tasks...


some comments in line

Le 30/12/2019 à 17:43, Nicolas Malin a écrit :
> Hello,
>
> Ten yearsagoI would've leaned over on a solution to improve on this way, but now with practical field experience I understood that it was a chimera on
> business production site.
>
> All is currently present on screen-widget.xsd to define easily a screen structure.
>
> The scenario “ProductOwner/keyUser/endUser” is already supported, I didn't hear at Néréide for functional developer that they are some difficulties to
> translate businessspecificationsfromany of theserolesthrough screen definition.

Currently, without portal-portlet, it's necessary to have a functional developer with its development environment to change some screen parameters, or
page organization. Parameters available are not easily readable.

With current PortalPage tools, I have already seen some ProductOwner/keyUsers test some solutions alone before choosing the right one (for them), it's
very efficient for functional consultant.

>
> Rather than concentrating on adding model layers, we willwin not to let the code grow too much and identify what is really missing on screensand rely
> on portal page only for caseswhere the end user can edit his own configuration page.

You are totally right, and clearly my next priority will be to check if I find a Portal-Portlet configuration feature that I can't easily achieve with
"classical" screen / decorator.

If I find one, I will ask you how to solve the issue, because I already assume it will be possible. ;-)

>
> I'm more in favor to put away all current portal page out of the framework, keep only one plugin as example and convert them with good practice to
> help other developersand functional developersto extend the framework.
>
> In this way I found the Mathieu'sbelowidea: fun :)
>
> Nicolas
>
> On 29/12/2019 11:36, Mathieu Lirzin wrote:
>> Hello Olivier,[...]
>>
>> 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?

That's a part of my proposal, and your implementation proposition give me a better idea of how to present it..
Well, first of all.
   I will re-uses portalPage, column, portlet, attribute entities to be able to design a short POC.
   I'm not sure to generate the xml directly, but something similar; the goal being a ready-to-use XML
In the second stage
   This will involve identifying the screens that can be used as a "component" (in a GUI point of view)



>>