Hello Michael
Nice questions :) in line
Le 17/08/2017 à 11:06, Michael Brohl a écrit :
Hi Nicolas,
During my work on the bootstrap theme [1] (which got stuck due to
other tasks) I stumbled upon some problems which possibly get solved
by your approach or we can consider a solution for it during the work.
In detail, I'm referring to [2] where you had the same problem I'm
facing: Instead of displaying the application menu bar when it is
active I want to have the menu items as sub level items in a global
navigation sidebar. It does not seem to be possible completely
dynamically because of the configuration inside the screen definitions
but it might be better doable if we would have a configuration
standard for the menus, using always the same patterns (convention
over configuration).
Do you already have an idea how to solve this/ will the new approach
help with this?
With this problematic we have two aspects :
* access to the model
* rendering the model
The first aspect isn't manage by themes, we need to understand what
missed on the modelScreen to improve it by technology or by convention.
But for the second it's completely cover by themes. To do that, you can
surcharge just the decorator definition or the macro ftl library that
you need.
Another base question is how we can provide different style classes
and ids to the base html code so that we can reuse the html but use
different UI frameworks with their specific style class terminology.
It would be great if users can choose their preferred UI framework
like Bootstrap, Foundation & Co. to build new themes. Will this be
covered by your approach?
The screen definition need to embed the minimum css set as convention
and maximum ids element. After that, you can define your own decorator
to load needed library or something like that and rewrite the macro ftl
to adapt the rendering.
With the theme dependency, you can also create a base theme like
boostrap-base that implement common-theme for all non html macro,
surchage all html macro library. Each new boostrap-theme can be
implement boostrap-base for all specific technical rendering and just
import their own class
Cheers,
Nicolas
[1]
https://lists.apache.org/thread.html/de49bb2fd2f9c82ab99bd08e603e9625c9c5a532a80b5226ccd5a4fc@%3Cdev.ofbiz.apache.org%3E
[2]
https://lists.apache.org/thread.html/91e3e5cab3b233f9587d69f0419eb652744cc5afcd39bc97df269ace@1444926106@%3Cuser.ofbiz.apache.org%3E
Thanks,
Michael
Am 16.08.17 um 13:49 schrieb Nicolas Malin:
Hello;
To continue the common-theme subject, I haven't see negative return
to the issue Create a common theme (OFBIZ-9138) [1] and on threads on
the same subject [2] and the additional theme xml definition [3], I
suggest to create a documentation on the wiki how work the "theme
engine" and commit the current git branch [4] [5] on trunk
After that, the engine will be present on the trunk and we continue
the work to :
* Clean the common-theme and create a real theme
* Migrate properly the current theme with the new structure
* Analyze more how organize the screen api
But don't panic, before that I'm listening to all suggest or remarks ;)
Nicolas
[1] https://issues.apache.org/jira/browse/OFBIZ-9138
[2]
https://lists.apache.org/thread.html/6ab61eb5ddeb4669f6e8e15fff44db724a596ecfece34ba4e34ef490@%3Cdev.ofbiz.apache.org%3E
[3]
https://lists.apache.org/thread.html/8c40f261d2d818aed6f38abe231030204f8f8d6ca8a366b9f040f326@%3Cdev.ofbiz.apache.org%3E
[4] https://github.com/nmalin/ofbiz-framework/tree/common-theme
[5]
https://github.com/apache/ofbiz-framework/compare/trunk...nmalin:common-theme?expand=1
