On Jan 6, 2014, at 12:26 PM, [email protected] 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. -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" <[email protected]>: > >> >> 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 <[email protected]> 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" <[email protected]> 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 >>> [email protected] >>> 214-720-0700 x 315 >>> Brainfood, Inc. >>> http://www.brainfood.com >> >> > > >
