You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Nicolas Malin <ni...@nereide.fr> on 2017/02/07 21:06:19 UTC
[DISCUSSION] Widget refactoring, create a new configuration object ?
Hi,
After continued my work on common-theme to refactoring UI interface, I
found a limitation with the current system.
At this time, on many case we resolve some widget configuration directly
from a property call on widget.property file.
If you check the string : '<property-to-field resource="widget"' or
'getPropertyValue("widget"' on trunk we are more than one hundred call.
But to be more flexible with the theme, I need to resolve dynamically
some configuration like the ftl template location and I'm locked.
After some reflexion, I tried to resolve the configuration by the theme
but this appear like just a patch and not a solution.
I think we need a dedicate class to manage theses widget configurations
on the user context, like we have the dispatcher for soa, the delegator
for the data, security (for security), we can have an object like
widgetTheme instantiate by an xml definition in each theme.
It would be a referent to resolve all widget configuration that the
screen renderer need, always present or quickly build with default value
if it is required and why not help to define some specific element
dedicate for a theme.
It's an open discussion, just to understand on what foot i need to dance :)
Nicolas
--
logoNrd <https://nereide.fr/>
Nicolas Malin
The apache way <http://theapacheway.com/> : *Openness* Technical
decisions are made publicly
information@nereide.fr
8 rue des D�port�s 37000 TOURS, 02 47 50 30 54
Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
<http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|r�seau LE
<http://www.libre-entreprise.org/>
Re: [DISCUSSION] Widget refactoring, create a new configuration
object ?
Posted by Nicolas Malin <ni...@nereide.fr>.
Hello Taher,
The better example come from resolve the freemarker template.
Currently we have this on MacroScreenViewHandler :
String screenMacroLibraryPath =
UtilProperties.getPropertyValue("widget", getName() + ".screenrenderer");
String formMacroLibraryPath =
UtilProperties.getPropertyValue("widget", getName() + ".formrenderer");
String treeMacroLibraryPath =
UtilProperties.getPropertyValue("widget", getName() + ".treerenderer");
String menuMacroLibraryPath =
UtilProperties.getPropertyValue("widget", getName() + ".menurenderer");
For the common-theme, we can change the library location to surcharge it
by a theme, so I set configurable the the properties file.
But do to that, we need to know the Theme, and with the theme define new
data for define the visual theme.
After that, we need to change all call like this :
* CMSEvent.java : FormStringRenderer formStringRenderer = new
MacroFormRenderer(EntityUtilProperties.getPropertyValue("widget",
"screen.formrenderer", delegator), request, response);
* FoPrintServerEvent.java : ScreenStringRenderer screenStringRenderer =
new MacroScreenRenderer(EntityUtilProperties.getPropertyValue("widget",
"screen.name", dctx.getDelegator()),
EntityUtilProperties.getPropertyValue("widget", "screen.screenrenderer",
dctx.getDelegator()));
My suggest would be write a class dedicate to the prepare the screen
engine throw the theme definition and replace VisualThemeResources data
by a xml definition for each theme. The class instanciation would
beinitialize at the top level like the dispatcher and delegator on the
user session and It would be more simple to manage the different
properties than the currently case.
And I'm sure we can found some other case cover by this class :)
Nicolas
Le 08/02/2017 � 12:38, Taher Alkhateeb a �crit :
> Hi Nicolas,
>
> Why do you need to resolve some configurations dynamically? Can you
> provide a concrete example to something you are facing which requires
> this?
>
> Cheers,
>
> Taher Alkhateeb
>
> On Wed, Feb 8, 2017 at 12:06 AM, Nicolas Malin
> <nicolas.malin@nereide.fr <ma...@nereide.fr>> wrote:
>
> Hi,
>
> After continued my work on common-theme to refactoring UI
> interface, I found a limitation with the current system.
>
> At this time, on many case we resolve some widget configuration
> directly from a property call on widget.property file.
>
> If you check the string : '<property-to-field resource="widget"'
> or 'getPropertyValue("widget"' on trunk we are more than one
> hundred call.
>
> But to be more flexible with the theme, I need to resolve
> dynamically some configuration like the ftl template location and
> I'm locked.
>
> After some reflexion, I tried to resolve the configuration by the
> theme but this appear like just a patch and not a solution.
>
> I think we need a dedicate class to manage theses widget
> configurations on the user context, like we have the dispatcher
> for soa, the delegator for the data, security (for security), we
> can have an object like widgetTheme instantiate by an xml
> definition in each theme.
>
> It would be a referent to resolve all widget configuration that
> the screen renderer need, always present or quickly build with
> default value if it is required and why not help to define some
> specific element dedicate for a theme.
>
> It's an open discussion, just to understand on what foot i need to
> dance :)
>
> Nicolas
> --
> logoNrd <https://nereide.fr/>
> Nicolas Malin
> The apache way <http://theapacheway.com/> : *Openness* Technical
> decisions are made publicly
> information@nereide.fr <ma...@nereide.fr>
> 8 rue des D�port�s 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> <http://theapacheway.com/>|ofbiz-fr
> <http://www.ofbiz-fr.org/>|r�seau LE
> <http://www.libre-entreprise.org/>
>
>
Re: [DISCUSSION] Widget refactoring, create a new configuration
object ?
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Nicolas,
Why do you need to resolve some configurations dynamically? Can you provide
a concrete example to something you are facing which requires this?
Cheers,
Taher Alkhateeb
On Wed, Feb 8, 2017 at 12:06 AM, Nicolas Malin <ni...@nereide.fr>
wrote:
> Hi,
>
> After continued my work on common-theme to refactoring UI interface, I
> found a limitation with the current system.
>
> At this time, on many case we resolve some widget configuration directly
> from a property call on widget.property file.
>
> If you check the string : '<property-to-field resource="widget"' or
> 'getPropertyValue("widget"' on trunk we are more than one hundred call.
>
> But to be more flexible with the theme, I need to resolve dynamically some
> configuration like the ftl template location and I'm locked.
>
> After some reflexion, I tried to resolve the configuration by the theme
> but this appear like just a patch and not a solution.
>
> I think we need a dedicate class to manage theses widget configurations on
> the user context, like we have the dispatcher for soa, the delegator for
> the data, security (for security), we can have an object like widgetTheme
> instantiate by an xml definition in each theme.
>
> It would be a referent to resolve all widget configuration that the screen
> renderer need, always present or quickly build with default value if it is
> required and why not help to define some specific element dedicate for a
> theme.
>
> It's an open discussion, just to understand on what foot i need to dance :)
> Nicolas
> --
> [image: logoNrd] <https://nereide.fr/>
> Nicolas Malin
> The apache way <http://theapacheway.com/> : *Openness* Technical
> decisions are made publicly
> information@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> <http://theapacheway.com/>|ofbiz-fr <http://www.ofbiz-fr.org/>|réseau LE
> <http://www.libre-entreprise.org/>
>