Quoting "David E. Jones" <d...@me.com>:
On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:
There are two problems with using DOM trees in OFBiz:
1. They consume a lot of memory. Keep in mind the entire XML file
is kept in memory, not just the bits you are interested in.
The parsed version is kept in memory, that is true, but for each
screen/form/etc you just keep the node object for the top-level
element. Under that element the only stuff it would keep around by
default that you don't need/want (but could be eliminated with a
little code) is comment elements.
2. They are not thread-safe.
They should be used read-only, so unless someone does something
funny thread safety isn't an issue. On that note, the same is true
for the shared objects in the current OFBiz widget implementations.
And that is the problem we have now. Many contributors/committers will
not understand what should and shouldn't be done with DOM nodes, and
consequently they will do things they shouldn't. History has proven
that, given the opportunity, OFBiz developers will "do something
funny" with the code.
Over the last few years, the framework code-base has been moving
toward immutable shared objects, and I think that is the safest
strategy to use. We have fixed numerous bugs going that route.
I understand your perspective and I appreciate it - make code
thread-unsafe for the sake of convenience. But that strategy exists
currently in OFBiz legacy code and it keeps hurting us.
What I find interesting about your proposal is how similar it is to
what I proposed years ago - make the widgets lightweight
representations of their XML files. The screen widget models would
contain Lists of model Elements, and the model Elements would contain
Maps of Element Attributes. At the time you rejected that idea - you
said performance would suffer by making the widget models that
generic. Now you're suggesting we skip the models altogether and just
use the DOM tree. So, what has changed your opinion?
-Adrian
-David
I did some refactoring a while ago where I replaced that approach
with a thread-safe approach. But that was done in other parts of
the framework, not in the screen widgets.
-Adrian
Quoting "David E. Jones" <d...@me.com>:
One way to make the OFBiz Form/Screen/etc widgets more useful and
extensible would be to take another step beyond what Jacopo did a
number of years ago with the FTL macros to produce HTML/CSV/XML/etc.
The current implementation in OFBiz parses the XML file into Java
classes and then when rendering generates macro calls to pass the
parameters (XML attribute values, etc) to the FTL macros. A more
flexible and extensible approach is to use the FTL XML processing
features directly instead of going through Java classes. With this
approach adding an attribute or support for a whole new element in
the widget XML files is just a matter of adding it to the FTL
macros that process XML elements.
This is the approach that Moqui Framework uses and it makes it
much easier to improve the supported elements in the framework
itself, and for users to add their own elements without touching
any framework code or templates (using a FTL macros file that
includes and then overrides and/or expands the XML processing
macros). For example the FTL macro for processing the "text-area"
element for a form field looks like this (from the
DefaultScreenMacros.html.ftl file; this of course has some
Moqui-specific stuff in it, but the general pattern would be the
same in OFBiz):
<#macro "text-area">
<textarea name="<@fieldName .node/>"
cols="${.node["@cols"]!"60"}" rows="${.node["@rows"]!"3"}"<#if
.node["@read-only"]!"false" == "true">
readonly="readonly"</#if><#if .node["@maxlength"]?has_content>
maxlength="${.node["@maxlength"]}"</#if> id="<@fieldId
.node/>"<#if .node?parent["@tooltip"]?has_content>
title="${.node?parent["@tooltip"]}"</#if>>${sri.getFieldValueString(.node?parent?parent, .node["@default-value"]!"",
null)?html}</textarea>
</#macro>
As you can see there are no parameters to the FTL macro, it just
uses the built-in ".node" variable that FTL makes available when
processing XML elements to get attributes, child elements, parent
elements, etc.
This is still server-side HTML generation, but would make the tool
more flexible. The current approach in OFBiz supports users
changing the text output and could actually be used to drive files
that are used for client-side HTML generation, this just makes it
a bit easier to do so and to use the widget XML files for more
instead of having to revert to plain FTL files or some other tool
for the UI (and doing so for the entire screen/form/etc as opposed
to just doing so for certain complex parts of it).
Another enhancement is some simple tags to drop in HTML in various
places (FTL templates or whatever). This can currently be done in
OFBiz in various parts of screen widgets, but for form widget
fields and other places it would be useful.
-David
On Jan 6, 2014, at 10:09 AM, Ean Schuessler <e...@brainfood.com> wrote:
I agree that we should migrate FTL templates to ofbiz widgets for the sake
of consistency throughout the interfaces. However, I do have to say that
I would not use form widgets to develop a customer facing site. At this
point, Brainfood is pretty much at a consensus that we do not want to do
"page template" oriented development in the server at all. When
you look at
applications like Google Maps it becomes clear that the "send post, alter
state, regenerate and send page" workflow is incredibly limited.
The future
seems to look a lot more like applications written in Javascript that
generate HTML directly in the browser.
So, for us, the important feature is the JSON-RPC interface for
this remote
applications. It would be genuinely interesting if we could write a client
side form widget interpreter that would delegate generation of
the interface
to the client side and then supply the "action" interface via
AJAX. That is
something we would be very interested in.
Refactoring the widget generation code to support greater
modularity in the HTML
could be another target of such an effort. I made some modest
efforts towards
a Bootstrap based OFBiz theme and I found it difficult to make
progress with the
current setup.
----- "Gavin Mabie" <kwikst...@gmail.com> wrote:
It appears that the citing of Drupal/WordPress/Magento solicited quite
a
lot of comment. It's a side issue really and whether some houses
prefer to
integrate existing solutions is besides the point. More importantly,
most
commentators would agree that theme developement in Ofbiz does require
more
attention. The vast majority of threads on this ML focuss on backend
business rules and processes. That in itself is not a problem - if
you
regard Ofbiz as a Framework only. It only means that, as far as
frameworks
go, we need a better framework for theming as well. This will
encourage
more participation from developers who have more of a front-end
orientation. I would support a drive towards better "themeability"
in
2014. In this regard I would like to suggest that we take a look at
the
VisualThemeResource entity which currently is currently poorly
defined.
Gavin
--
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com