OFBiz In 2014
Locked
1234
1234
 
Administrator
|
At least it would be great to have a themeable backend OOTB. Hence, as much as possible, the widget form for consistency.
Also, though limited, you can always inject js in forms, the price rules and promotions below are good examples. Jacques On Saturday, January 04, 2014 7:09 PM [hidden email] wrote > My preference is to use freemarker. With Form widgets, Its nearly impossible to deliver UI/UX for todays users. > > Thanks and Regards > Anil Patel > Hotwax Media Inc > http://www.hotwaxmedia.com/ > ApacheCon US 2013 Gold Sponsor > http://na.apachecon.com/sponsors/ > > ----- Original Message ----- > From: "Jacques Le Roux" <[hidden email]> > To: [hidden email] > Sent: Saturday, January 4, 2014 11:52:34 AM > Subject: Re: OFBiz In 2014 > > To be pragmatic, rather than working on new features, a new framework or whatever, I'd like to work on "Widget & Application HTML > clean-up" https://issues.apache.org/jira/browse/OFBIZ-5040 > > I have heard much complaints about this and I'd really like to 1st replace as much as possible the Freemarker templates used in > backend by widget forms. > > I know already some cases where it's impossible, like the geo location. > But in most cases this should be possible and would much facilitate designers work, when themes or such are needed. > Because we would then have a consistent HTML generation. > And in most cases even a better (consistent) UI, compare the old Price Rules and Promotions for instance > (still available at > https://demo-old.ofbiz.apache.org/catalog/control/EditProductPriceRules?productPriceRuleId=9000 > https://demo-old.ofbiz.apache.org/catalog/control/EditProductPromoRules?productPromoId=9000 > ) > > Because it contained a new FTL template, I recently refused to commit a working patch for "Improve to allow purchase order ship > method options" https://issues.apache.org/jira/browse/OFBIZ-5387 > > > I though must say that I still want to finish pending new features (actually 2 new specialpurpose components) > > 1) I expect to merge the seo branch soon https://issues.apache.org/jira/browse/OFBIZ-5312. > I only see minor issues now, and anyway at some point you need to have your feet wet... > > 2) And to finish the Solr integration https://issues.apache.org/jira/browse/OFBIZ-5042. > I sill have to figure out how bad is the security issue. In a first step adding a credential acces to the the Solr admin should > be enough. But yes underneath is not totally secured as is... > > Jacques > > > On Tuesday, December 31, 2013 1:55 PM [hidden email] wrote >> Maybe we can use the start of the new year as an opportunity to consider >> the future of OFBiz and update our road map: >> >> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document |
|
Administrator
|
In reply to this post by Jacopo Cappellato-4
On Monday, January 06, 2014 10:03 AM, [hidden email] wrote
> Then, here is my personal wish list: > > * integrate Atomikos Transaction Manager (to replace the existing old and incomplete Geronimo Transaction Manager); I did most > of the work some time ago and also Scott helped me; but the effort is not completed (but we are close); this is on hold at the > moment and it would be great to give it a final push Just as a note: it seems David experienced some issue with Atomikos in Moqui OOTB http://tinyurl.com/pwefeoo And you have sometimes to use workaround config (Postgres needs it for instance, reported David) > * continue and improve the maintenance effort of the OFBiz codebase: upgrade of external jars to latest releases, removal of > old/unused stuff, better documentation of jar interdependencies, code review/enhancements, bug fixes, further modularization > and slim down etc... Reminder: I wonder if nobody is concerned like me about how we handle security at large and notably regarding embedded libs. I believe we should discuss this, and determine a policy. 1st thing to do would be to verify all libs are currently secure, then to take care of it. I now follow CERT for that, but I'm not sure about current status... Also a last wish for 2014 (no I don't like to repeat myself): I'd love to see active committers giving more attention to contributions. Not excluding other devs and users of course (test, review, etc.) Jacques |
|
In reply to this post by Jacques Le Roux
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 On Mon, Jan 6, 2014 at 1:07 PM, Jacques Le Roux < [hidden email]> wrote: > At least it would be great to have a themeable backend OOTB. Hence, as > much as possible, the widget form for consistency. > Also, though limited, you can always inject js in forms, the price rules > and promotions below are good examples. > > Jacques > > On Saturday, January 04, 2014 7:09 PM [hidden email] wrote > > My preference is to use freemarker. With Form widgets, Its nearly > impossible to deliver UI/UX for todays users. > > > > Thanks and Regards > > Anil Patel > > Hotwax Media Inc > > http://www.hotwaxmedia.com/ > > ApacheCon US 2013 Gold Sponsor > > http://na.apachecon.com/sponsors/ > > > > ----- Original Message ----- > > From: "Jacques Le Roux" <[hidden email]> > > To: [hidden email] > > Sent: Saturday, January 4, 2014 11:52:34 AM > > Subject: Re: OFBiz In 2014 > > > > To be pragmatic, rather than working on new features, a new framework or > whatever, I'd like to work on "Widget & Application HTML > > clean-up" https://issues.apache.org/jira/browse/OFBIZ-5040 > > > > I have heard much complaints about this and I'd really like to 1st > replace as much as possible the Freemarker templates used in > > backend by widget forms. > > > > I know already some cases where it's impossible, like the geo location. > > But in most cases this should be possible and would much facilitate > designers work, when themes or such are needed. > > Because we would then have a consistent HTML generation. > > And in most cases even a better (consistent) UI, compare the old Price > Rules and Promotions for instance > > (still available at > > > https://demo-old.ofbiz.apache.org/catalog/control/EditProductPriceRules?productPriceRuleId=9000 > > > https://demo-old.ofbiz.apache.org/catalog/control/EditProductPromoRules?productPromoId=9000 > > ) > > > > Because it contained a new FTL template, I recently refused to commit a > working patch for "Improve to allow purchase order ship > > method options" https://issues.apache.org/jira/browse/OFBIZ-5387 > > > > > > I though must say that I still want to finish pending new features > (actually 2 new specialpurpose components) > > > > 1) I expect to merge the seo branch soon > https://issues.apache.org/jira/browse/OFBIZ-5312. > > I only see minor issues now, and anyway at some point you need to have > your feet wet... > > > > 2) And to finish the Solr integration > https://issues.apache.org/jira/browse/OFBIZ-5042. > > I sill have to figure out how bad is the security issue. In a first step > adding a credential acces to the the Solr admin should > > be enough. But yes underneath is not totally secured as is... > > > > Jacques > > > > > > On Tuesday, December 31, 2013 1:55 PM [hidden email] > >> Maybe we can use the start of the new year as an opportunity to consider > >> the future of OFBiz and update our road map: > >> > >> > https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document > |
|
|
I would recommend that you create a Jira issue for it and enlist some help.
Adrian Crum Sandglass Software www.sandglass-software.com On 1/6/2014 8:31 AM, Gavin Mabie 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 > > > On Mon, Jan 6, 2014 at 1:07 PM, Jacques Le Roux < > [hidden email]> wrote: > >> At least it would be great to have a themeable backend OOTB. Hence, as >> much as possible, the widget form for consistency. >> Also, though limited, you can always inject js in forms, the price rules >> and promotions below are good examples. >> >> Jacques >> >> On Saturday, January 04, 2014 7:09 PM [hidden email] wrote >>> My preference is to use freemarker. With Form widgets, Its nearly >> impossible to deliver UI/UX for todays users. >>> >>> Thanks and Regards >>> Anil Patel >>> Hotwax Media Inc >>> http://www.hotwaxmedia.com/ >>> ApacheCon US 2013 Gold Sponsor >>> http://na.apachecon.com/sponsors/ >>> >>> ----- Original Message ----- >>> From: "Jacques Le Roux" <[hidden email]> >>> To: [hidden email] >>> Sent: Saturday, January 4, 2014 11:52:34 AM >>> Subject: Re: OFBiz In 2014 >>> >>> To be pragmatic, rather than working on new features, a new framework or >> whatever, I'd like to work on "Widget & Application HTML >>> clean-up" https://issues.apache.org/jira/browse/OFBIZ-5040 >>> >>> I have heard much complaints about this and I'd really like to 1st >> replace as much as possible the Freemarker templates used in >>> backend by widget forms. >>> >>> I know already some cases where it's impossible, like the geo location. >>> But in most cases this should be possible and would much facilitate >> designers work, when themes or such are needed. >>> Because we would then have a consistent HTML generation. >>> And in most cases even a better (consistent) UI, compare the old Price >> Rules and Promotions for instance >>> (still available at >>> >> https://demo-old.ofbiz.apache.org/catalog/control/EditProductPriceRules?productPriceRuleId=9000 >>> >> https://demo-old.ofbiz.apache.org/catalog/control/EditProductPromoRules?productPromoId=9000 >>> ) >>> >>> Because it contained a new FTL template, I recently refused to commit a >> working patch for "Improve to allow purchase order ship >>> method options" https://issues.apache.org/jira/browse/OFBIZ-5387 >>> >>> >>> I though must say that I still want to finish pending new features >> (actually 2 new specialpurpose components) >>> >>> 1) I expect to merge the seo branch soon >> https://issues.apache.org/jira/browse/OFBIZ-5312. >>> I only see minor issues now, and anyway at some point you need to have >> your feet wet... >>> >>> 2) And to finish the Solr integration >> https://issues.apache.org/jira/browse/OFBIZ-5042. >>> I sill have to figure out how bad is the security issue. In a first step >> adding a credential acces to the the Solr admin should >>> be enough. But yes underneath is not totally secured as is... >>> >>> Jacques >>> >>> >>> On Tuesday, December 31, 2013 1:55 PM [hidden email] >>>> Maybe we can use the start of the new year as an opportunity to consider >>>> the future of OFBiz and update our road map: >>>> >>>> >> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >> > |
|
|
In reply to this post by Gavin Mabie-2
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" <[hidden email]> 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 [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com |
|
|
In reply to this post by Jacques Le Roux
On Jan 6, 2014, at 5:09 AM, Jacques Le Roux <[hidden email]> wrote: > On Monday, January 06, 2014 10:03 AM, [hidden email] wrote >> Then, here is my personal wish list: >> >> * integrate Atomikos Transaction Manager (to replace the existing old and incomplete Geronimo Transaction Manager); I did most >> of the work some time ago and also Scott helped me; but the effort is not completed (but we are close); this is on hold at the >> moment and it would be great to give it a final push > > Just as a note: it seems David experienced some issue with Atomikos in Moqui OOTB http://tinyurl.com/pwefeoo > And you have sometimes to use workaround config (Postgres needs it for instance, reported David) Related to this I've been testing more with Bitronix BTM recently and it seems to be doing much better than Atomikos in various scenarios. Part of my frustration with Atomikos is the lack of bug fixes going into open source releases. They put them in the subscriber-only releases for a few months to over a year before putting them in the open source releases, meaning the lag time for bug fixes and support for open source users (including open source projects that may be used commercially) is significant. -David |
|
|
In reply to this post by Ean Schuessler
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 <[hidden email]> 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" <[hidden email]> 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 > [hidden email] > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com |
|
|
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. 2. They are not thread-safe. 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" <[hidden email]>: > > 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 <[hidden email]> 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" <[hidden email]> 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 >> [hidden email] >> 214-720-0700 x 315 >> Brainfood, Inc. >> http://www.brainfood.com > > |
|
|
In reply to this post by Adrian Crum-3
One of my top annoyances with OFBiz coding is the inconsistency of tools, especially the scripts and expressions within widgets and simple-methods. A first step would be to make all expressions, conditions, etc use Groovy instead of JUEL and the bits of BeanShell that are still used. Groovy has a lot of convenient stuff that JUEL and BeanShell do not, and when coding I find it takes so much more work to understand and work with the differences and the more cumbersome syntax that I (and I've noticed many others) hacking around this limitation with the ${groovy: ...} expressions, which are fine but then have type conversion issues as this is really a string expansion syntax. The whole FlexibleStringExpander could just call into Groovy for evaluation instead of the various things plus calling into JUEL that it currently does. A bigger step would be to change the simple-method processing to be just a FTL template that creates a Groovy script from the XML, and then compile/cache/run the Groovy script. This has the added benefits of dramatically simplifying the framework code (no need for a Java class for each XML element), and makes it easy to do inline Groovy scripts in simple-methods. With either approach it would be nice to make the simple-method and screen/form/etc actions blocks use the same XSD and be processed the same way for better consistency (fewer surprises during dev and testing, more general flexibility too). As I do development with both Moqui and OFBiz I find this to be one of the biggest differences that makes working with Moqui Framework faster and less frustrating than with OFBiz. There are many differences between the two frameworks, but this one stands out to me as perhaps the most significant when working day-to-day, and should be one of the easier ones to incorporate. Most existing expressions written for JUEL should evaluate fine in Groovy, but some would have to change... that would be the biggest impact of this change on existing code. -David On Dec 31, 2013, at 4:55 AM, Adrian Crum <[hidden email]> wrote: > Maybe we can use the start of the new year as an opportunity to consider the future of OFBiz and update our road map: > > https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document > > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com |
|
|
In reply to this post by Adrian Crum-3
On Jan 6, 2014, at 12:26 PM, [hidden email] 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" <[hidden email]>: > >> >> 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 <[hidden email]> 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" <[hidden email]> 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 >>> [hidden email] >>> 214-720-0700 x 315 >>> Brainfood, Inc. >>> http://www.brainfood.com >> >> > > > |
|
|
In reply to this post by David E. Jones-2
It would be interesting to see the performance impact of that approach.
I overhauled Mini-language recently and in the process I made sure the execution path was as short and straight as possible. That effort produced a 40% performance improvement. I wonder how Java's compile-time linking compares with Groovy's time spent in the reflection API. I agree it would be wonderful to have screen widgets inherit Mini-language in their <action> elements. -Adrian Quoting "David E. Jones" <[hidden email]>: > > One of my top annoyances with OFBiz coding is the inconsistency of > tools, especially the scripts and expressions within widgets and > simple-methods. > > A first step would be to make all expressions, conditions, etc use > Groovy instead of JUEL and the bits of BeanShell that are still > used. Groovy has a lot of convenient stuff that JUEL and BeanShell > do not, and when coding I find it takes so much more work to > understand and work with the differences and the more cumbersome > syntax that I (and I've noticed many others) hacking around this > limitation with the ${groovy: ...} expressions, which are fine but > then have type conversion issues as this is really a string > expansion syntax. The whole FlexibleStringExpander could just call > into Groovy for evaluation instead of the various things plus > calling into JUEL that it currently does. > > A bigger step would be to change the simple-method processing to be > just a FTL template that creates a Groovy script from the XML, and > then compile/cache/run the Groovy script. This has the added > benefits of dramatically simplifying the framework code (no need for > a Java class for each XML element), and makes it easy to do inline > Groovy scripts in simple-methods. > > With either approach it would be nice to make the simple-method and > screen/form/etc actions blocks use the same XSD and be processed the > same way for better consistency (fewer surprises during dev and > testing, more general flexibility too). > > As I do development with both Moqui and OFBiz I find this to be one > of the biggest differences that makes working with Moqui Framework > faster and less frustrating than with OFBiz. There are many > differences between the two frameworks, but this one stands out to > me as perhaps the most significant when working day-to-day, and > should be one of the easier ones to incorporate. Most existing > expressions written for JUEL should evaluate fine in Groovy, but > some would have to change... that would be the biggest impact of > this change on existing code. > > -David > > > On Dec 31, 2013, at 4:55 AM, Adrian Crum > <[hidden email]> wrote: > >> Maybe we can use the start of the new year as an opportunity to >> consider the future of OFBiz and update our road map: >> >> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >> >> >> -- >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com > > |
|
|
In reply to this post by David E. Jones-2
Re: parsed version is kept in memory.
Would that be per tenant in a multi tenant setup or only once per running Ofbiz instance? Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com |
|
|
In reply to this post by David E. Jones-2
Quoting "David E. Jones" <[hidden email]>:
> > On Jan 6, 2014, at 12:26 PM, [hidden email] 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" <[hidden email]>: >> >>> >>> 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 <[hidden email]> 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" <[hidden email]> 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 >>>> [hidden email] >>>> 214-720-0700 x 315 >>>> Brainfood, Inc. >>>> http://www.brainfood.com >>> >>> >> >> >> > > |
|
|
In reply to this post by Pierre Smits
I can't think of any reason to do it different from how it is now, ie the "parsed" version of the files are cached by their filename which is independent of the tenant. You can have files that are used by only one tenant, but any files that are used by more than one would be shared. -David On Jan 6, 2014, at 12:58 PM, Pierre Smits <[hidden email]> wrote: > Re: parsed version is kept in memory. > Would that be per tenant in a multi tenant setup or only once per running > Ofbiz instance? > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com |
|
|
In reply to this post by Adrian Crum-3
On Jan 6, 2014, at 12:58 PM, [hidden email] wrote: > Quoting "David E. Jones" <[hidden email]>: > >> >> On Jan 6, 2014, at 12:26 PM, [hidden email] 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? My concerns about performance were clearly overblown. After trying the direct node tree and profiling performance I now know it doesn't result in much of a performance difference. In other words, the direction you proposed is a good one and would simplify code, and letting FTL walk the node tree instead of Java code is just as fast and that little step eliminates a bunch more framework code and at the same time makes it far more flexible and extensible. IMO the minor impact on runtime performance is well worth the additional flexibility. It makes the tools usable in so many more situations where you would otherwise need to drop to plain FTL instead of using the form widget or certain parts of the screen widget, and addresses many of the concerns that push people to using other web UI frameworks. BTW, from profiling work in Moqui Framework I found it was really other stuff that killed performance, little things you wouldn't expect sometimes like how long it takes to call System.currentTimeMillis(). FTL and Groovy are impressively fast for what they do and JVMs do so much better with Map and List operations (iteration, add/put, get, etc) than they did when OFBiz was young, especially once the JIT natively compiles that frequently used code, that the overhead barely shows up in profiling results. BTW2, in early profiling a few years ago with Groovy there was noticeable overhead from on the fly object and method binding and such, but much of this changed with Groovy 2 when they incorporated features from Groovy++ to more quickly bind based on types declared or casted in the code, so it runs quite a bit faster with a little more effort in declaring types (as opposed to using Object or def all over the place). There is still somewhat of a performance difference in doing simplified method names (like foo.bar versus foo.getBar()), but even that doesn't show up in profilers like it used to with Groovy (so all the effort I put into Moqui making such changes don't matter so much any more :) ). One thing about thread safety with this approach is that there is SO little code, the vast bulk of it is in the FTL macros. The framework code just has to parse the XML file, grab the desired top-level node, wrap it so FTL can use it (in Moqui I implemented a simple wrapper for the Groovy Node object to implement the FTL node interface), then pass it to FTL when rendering the template. That's really it. The FTL macros will also need framework code to call back into to do things like including forms, FTL files, other screens, etc... but that is also pretty small/simple code. I was hesitant about this approach at first, in spite of the great flexibility, but in Moqui it has worked well... the code for that is about 3 years old now with hundreds of screens running on various production instances (that I'm aware of anyway, it's like OFBiz in that I often don't find out about projects and even deployed instances either at all or until well after they are in production). -David |
|
|
Thanks for the info - that was informative!
I'm still not sold on keeping the DOM tree though. I seem to recall Adam Heath doing a memory-use analysis a few years ago and he discovered that even keeping a reference to a String from the DOM kept the whole tree in memory. That is why he did all those String.intern()s in the models. I can't be sure though, my memory is a bit foggy on that. Adrian Crum Sandglass Software www.sandglass-software.com On 1/6/2014 5:49 PM, David E. Jones wrote: > > On Jan 6, 2014, at 12:58 PM, [hidden email] wrote: > >> Quoting "David E. Jones" <[hidden email]>: >> >>> >>> On Jan 6, 2014, at 12:26 PM, [hidden email] 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? > > My concerns about performance were clearly overblown. After trying the direct node tree and profiling performance I now know it doesn't result in much of a performance difference. > > In other words, the direction you proposed is a good one and would simplify code, and letting FTL walk the node tree instead of Java code is just as fast and that little step eliminates a bunch more framework code and at the same time makes it far more flexible and extensible. IMO the minor impact on runtime performance is well worth the additional flexibility. It makes the tools usable in so many more situations where you would otherwise need to drop to plain FTL instead of using the form widget or certain parts of the screen widget, and addresses many of the concerns that push people to using other web UI frameworks. > > BTW, from profiling work in Moqui Framework I found it was really other stuff that killed performance, little things you wouldn't expect sometimes like how long it takes to call System.currentTimeMillis(). FTL and Groovy are impressively fast for what they do and JVMs do so much better with Map and List operations (iteration, add/put, get, etc) than they did when OFBiz was young, especially once the JIT natively compiles that frequently used code, that the overhead barely shows up in profiling results. > > BTW2, in early profiling a few years ago with Groovy there was noticeable overhead from on the fly object and method binding and such, but much of this changed with Groovy 2 when they incorporated features from Groovy++ to more quickly bind based on types declared or casted in the code, so it runs quite a bit faster with a little more effort in declaring types (as opposed to using Object or def all over the place). There is still somewhat of a performance difference in doing simplified method names (like foo.bar versus foo.getBar()), but even that doesn't show up in profilers like it used to with Groovy (so all the effort I put into Moqui making such changes don't matter so much any more :) ). > > One thing about thread safety with this approach is that there is SO little code, the vast bulk of it is in the FTL macros. The framework code just has to parse the XML file, grab the desired top-level node, wrap it so FTL can use it (in Moqui I implemented a simple wrapper for the Groovy Node object to implement the FTL node interface), then pass it to FTL when rendering the template. That's really it. The FTL macros will also need framework code to call back into to do things like including forms, FTL files, other screens, etc... but that is also pretty small/simple code. > > I was hesitant about this approach at first, in spite of the great flexibility, but in Moqui it has worked well... the code for that is about 3 years old now with hundreds of screens running on various production instances (that I'm aware of anyway, it's like OFBiz in that I often don't find out about projects and even deployed instances either at all or until well after they are in production). > > -David > > |
|
Administrator
|
In reply to this post by Adrian Crum-3
For instance you could there share your thoughts about VisualThemeResource...
Jacques On Monday, January 06, 2014 2:45 PM, [hidden email] wrote > I would recommend that you create a Jira issue for it and enlist some help. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/6/2014 8:31 AM, Gavin Mabie 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 >> >> >> On Mon, Jan 6, 2014 at 1:07 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> At least it would be great to have a themeable backend OOTB. Hence, as >>> much as possible, the widget form for consistency. >>> Also, though limited, you can always inject js in forms, the price rules >>> and promotions below are good examples. >>> >>> Jacques >>> >>> On Saturday, January 04, 2014 7:09 PM [hidden email] wrote >>>> My preference is to use freemarker. With Form widgets, Its nearly >>> impossible to deliver UI/UX for todays users. >>>> >>>> Thanks and Regards >>>> Anil Patel >>>> Hotwax Media Inc >>>> http://www.hotwaxmedia.com/ >>>> ApacheCon US 2013 Gold Sponsor >>>> http://na.apachecon.com/sponsors/ >>>> >>>> ----- Original Message ----- >>>> From: "Jacques Le Roux" <[hidden email]> >>>> To: [hidden email] >>>> Sent: Saturday, January 4, 2014 11:52:34 AM >>>> Subject: Re: OFBiz In 2014 >>>> >>>> To be pragmatic, rather than working on new features, a new framework or >>> whatever, I'd like to work on "Widget & Application HTML >>>> clean-up" https://issues.apache.org/jira/browse/OFBIZ-5040 >>>> >>>> I have heard much complaints about this and I'd really like to 1st >>> replace as much as possible the Freemarker templates used in >>>> backend by widget forms. >>>> >>>> I know already some cases where it's impossible, like the geo location. >>>> But in most cases this should be possible and would much facilitate >>> designers work, when themes or such are needed. >>>> Because we would then have a consistent HTML generation. >>>> And in most cases even a better (consistent) UI, compare the old Price >>> Rules and Promotions for instance >>>> (still available at >>>> >>> https://demo-old.ofbiz.apache.org/catalog/control/EditProductPriceRules?productPriceRuleId=9000 >>>> >>> https://demo-old.ofbiz.apache.org/catalog/control/EditProductPromoRules?productPromoId=9000 >>>> ) >>>> >>>> Because it contained a new FTL template, I recently refused to commit a >>> working patch for "Improve to allow purchase order ship >>>> method options" https://issues.apache.org/jira/browse/OFBIZ-5387 >>>> >>>> >>>> I though must say that I still want to finish pending new features >>> (actually 2 new specialpurpose components) >>>> >>>> 1) I expect to merge the seo branch soon >>> https://issues.apache.org/jira/browse/OFBIZ-5312. >>>> I only see minor issues now, and anyway at some point you need to have >>> your feet wet... >>>> >>>> 2) And to finish the Solr integration >>> https://issues.apache.org/jira/browse/OFBIZ-5042. >>>> I sill have to figure out how bad is the security issue. In a first step >>> adding a credential acces to the the Solr admin should >>>> be enough. But yes underneath is not totally secured as is... >>>> >>>> Jacques >>>> >>>> >>>> On Tuesday, December 31, 2013 1:55 PM [hidden email] >>>>> Maybe we can use the start of the new year as an opportunity to consider >>>>> the future of OFBiz and update our road map: >>>>> >>>>> >>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document |
|
Administrator
|
In reply to this post by Adrian Crum-3
Done, please double-check
Jacques On Sunday, January 05, 2014 2:37 PM, [hidden email] wrote > In addition, I would like to see the completed items removed. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/5/2014 8:35 AM, Pierre Smits wrote: >> As for the topics in the roadmap document referenced >> (this<https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document>) >> here are my remarks: >> >> Please ask each individual directly whether they are still interested in >> the subject or are still willing to assist/champion enhancements. And if >> so, invite those to address the issues stated per component, update the >> short description of the topic and (if not already done) create and/or >> update a specific topic page on the subject. >> >> I fear that a lot of persons stating interest and/or willingness on the >> page have moved on to other fields of interest. >> >> Regards, >> >> Pierre Smits >> >> *ORRTIZ.COM <http://www.orrtiz.com>* >> Services & Solutions for Cloud- >> Based Manufacturing, Professional >> Services and Retail & Trade >> http://www.orrtiz.com |
|
|
Thanks Jacques! That looks much better.
I agree with Pierre that we need to contact the people who expressed interest in the Roadmap items. I believe some of those items are finished (like VAT and Accounting) and some of the people are no longer active in the OFBiz community (like Si Chen). From my perspective, keeping those items there indefinitely with no activity looks bad for the project. I understand we all had good intentions when we added ourselves to those items (myself included), but we need to be realistic and remove ourselves if we will not be able to do the work. Adrian Crum Sandglass Software www.sandglass-software.com On 1/11/2014 5:40 PM, Jacques Le Roux wrote: > Done, please double-check > > Jacques > > On Sunday, January 05, 2014 2:37 PM, [hidden email] wrote >> In addition, I would like to see the completed items removed. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 1/5/2014 8:35 AM, Pierre Smits wrote: >>> As for the topics in the roadmap document referenced >>> (this<https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document>) >>> here are my remarks: >>> >>> Please ask each individual directly whether they are still interested in >>> the subject or are still willing to assist/champion enhancements. And if >>> so, invite those to address the issues stated per component, update the >>> short description of the topic and (if not already done) create and/or >>> update a specific topic page on the subject. >>> >>> I fear that a lot of persons stating interest and/or willingness on the >>> page have moved on to other fields of interest. >>> >>> Regards, >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM <http://www.orrtiz.com>* >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com |
|
Administrator
|
On Sunday, January 12, 2014 12:23 AM, [hidden email] wrote
> Thanks Jacques! That looks much better. > > I agree with Pierre that we need to contact the people who expressed > interest in the Roadmap items. I believe some of those items are > finished (like VAT and Accounting) and some of the people are no longer > active in the OFBiz community (like Si Chen). Clearly for Si, for VAT there is still something missing: the reporting part (taxAuthorityVATReport request). I began long ago but did not finish (I must have it pending somewhere, almost lost...) > From my perspective, keeping those items there indefinitely with no > activity looks bad for the project. I understand we all had good > intentions when we added ourselves to those items (myself included), but > we need to be realistic and remove ourselves if we will not be able to > do the work. Totally agree, not need to fossilize Jacques > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 1/11/2014 5:40 PM, Jacques Le Roux wrote: >> Done, please double-check >> >> Jacques >> >> On Sunday, January 05, 2014 2:37 PM, [hidden email] wrote >>> In addition, I would like to see the completed items removed. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 1/5/2014 8:35 AM, Pierre Smits wrote: >>>> As for the topics in the roadmap document referenced >>>> (this<https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document>) >>>> here are my remarks: >>>> >>>> Please ask each individual directly whether they are still interested in >>>> the subject or are still willing to assist/champion enhancements. And if >>>> so, invite those to address the issues stated per component, update the >>>> short description of the topic and (if not already done) create and/or >>>> update a specific topic page on the subject. >>>> >>>> I fear that a lot of persons stating interest and/or willingness on the >>>> page have moved on to other fields of interest. >>>> >>>> Regards, >>>> >>>> Pierre Smits >>>> >>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>> Services & Solutions for Cloud- >>>> Based Manufacturing, Professional >>>> Services and Retail & Trade >>>> http://www.orrtiz.com |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |