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