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
> <
[hidden email] <mailto:
[hidden email]>> 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
>
[hidden email] <mailto:
[hidden email]>
> 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/>
>
>
Locked
