I recently put forth some ideas that would enable easy customization of the
OFBiz UI (back office applications, not eCommerce) -
http://jira.undersunconsulting.com/browse/OFBIZ-880 .
Jacopo has contributed some work to get a few foundational items in place for
this to work. At the same time, Si is trying to develop a sophisticated
user-configured UI. Since we have some interest in this subject, I'd like to
propose another minor change.
Since much of the layout is hard-coded into the Global Decorator, the only way
to change the layout is to modify or replace the
framework/common/widget/CommonScreens.xml file. It's great that we have the
ability to change OFBiz's appearance by swapping out one file, but I'd like to
see the framework support customized UIs without the need to replace this file.
The Global Decorator could be slightly modified to make custom "skins" easier to
implement.
Inside the Global Decorator is this great piece of code:
<widgets>
<platform-specific><html><html-template
location="${appheaderTemplate}"/></html></platform-specific>
</widgets>
which implements a component-specified application header ftl file. Putting the
template location in a variable is a great idea.
Farther up in the Global Decorator is:
<widgets>
<!-- render header -->
<platform-specific><html><html-template
location="component://common/webcommon/includes/header.ftl"/></html></platform-specific>
<!-- render appbar -->
<platform-specific><html><html-template
location="component://common/webcommon/includes/appbar.ftl"/></html></platform-specific>
which implements hard-coded layout ftl files. There is no way to change these
without modifying the XML file. This is what keeps us from implementing
user-selected skins.
So, my Global Decorator proposal is this: let's keep all references to ftl files
in variables - just like the application header (appheaderTemplate). An <action>
section could be inserted in the decorator for now which would initialize the
variables to the default UI. Later, that section will call a service that loads
the variables based upon the user's UI preferences.
The implementation we have working here uses an XML file to configure "skins"
that the user can choose from. Si is considering using a collection of entities
to configure the same thing. Whichever route is taken, at some point in time we
will have the ability to dynamically control the UI layout - WITHOUT having to
hack into code.
Any thoughts?
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Locked
