You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2014/01/04 17:52:34 UTC
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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes, maybe indeed
Jacques
On Saturday, January 04, 2014 7:03 PM adrian.crum@sandglass-software.com wrote
> Why is geo location impossible with screen widgets? We could create a
> map widget.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/4/2014 11:52 AM, Jacques Le Roux wrote:
>> 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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
Why is geo location impossible with screen widgets? We could create a
map widget.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/4/2014 11:52 AM, Jacques Le Roux wrote:
> 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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
Gavin I added you in the related section
Jacques
On Saturday, January 04, 2014 6:28 PM, kwikstore@gmail.com wrote
> Hi Guys
>
> Best wishes to everybody for 2014. I would like to support the
> prioritisation of theme development for 2014. Jacques, I noticed that you
> are specifically talking about backend widget
> forms. What about ecommerce? IMO that little attention is given to
> frontend design and even less is done to accommodate design-orientated
> developers. Theme developement in Ofbiz has a long way to go if it is to
> reach the levels of standardisation, ease and portability attained and used
> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
> Magento. Keep up the good work.
>
> Gavin
>
>
> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> 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 adrian.crum@sandglass-software.comwrote
>>> 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
Re: OFBiz In 2014
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jan 5, 2014, at 1:52 PM, Pierre Smits <pi...@gmail.com> wrote:
> *Re: slimdown*
> The path set in the recent past regarding slim down is a good path. This
> should be continued. But, slim down should not be about only focussing on
> the framework. More visibility on the website should be created regarding
> vision and roadmap. In the past also several apps/components/functions have
> been earmarked as eligible for slimdown roadmap, but little actions have
> been undertaken.
I agree that a lot more still needs to be done, but we actually did a lot of progress in this directions if we look at release branches, rather than the trunk: in fact the new release branch 13.07, that will generate the new releases (the first one will be released in a few weeks), is considerably lighter that the previous releases.
This trend can be better appreciated by considering the approx sizes of release tarballs:
09 releases: 58MB
10 releases: 93MB
11 releases: 112MB
12 releases: 113MB
13 releases: 83MB
If I well remember, the slimdown effort started between 11 and 12: it took some time to stop the uncontrolled growth trend and move in the other direction.
It is important to focus on quality: I still see too many commits that would not meet the minimum quality standards of any decent software company and I really would like to see this resolved; our goal should be that the quality of OFBiz code, and all its commits should shine in perfection.
Jacopo
Re: OFBiz In 2014
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On Jan 5, 2014, at 1:52 PM, Pierre Smits <pi...@gmail.com> wrote:
> With regards to integration with other solutions I would like to see the
> uptake of a solution like Apache Shiro regarding authentication,
> authorization, etc.
+1
Jacopo
Re: OFBiz In 2014
Posted by Pierre Smits <pi...@gmail.com>.
It seems that a lot of links in the
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Documentare
broken.
Besides this, if (and when) subjects are to be removed the short
descriptions of the subject should move to somewhere else.
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sun, Jan 12, 2014 at 1:03 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> On Sunday, January 12, 2014 12:23 AM, adrian.crum@sandglass-software.comwrote
> > 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, adrian.crum@sandglass-software.comwrote
> >>> 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
>
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
On Sunday, January 12, 2014 12:23 AM, adrian.crum@sandglass-software.com 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, adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.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, adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
Done, please double-check
Jacques
On Sunday, January 05, 2014 2:37 PM, adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>
Re: OFBiz In 2014
Posted by Pierre Smits <pi...@gmail.com>.
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
Re: OFBiz In 2014
Posted by Pierre Smits <pi...@gmail.com>.
First of all, let me say that it is good to reflect on the roadmap again.
This should be done at regular intervals.
Secondly, I feel that this thread should have been initiated in the other
mailing list. Though many may follow this mailing list, not all do.
Discussions regarding vision and roadmap should involve all members of the
community.
Thirdly, I feel its a pity that many of the PMC and Committers don't jump
to the gun to share their opinions, visions and insights regarding the
future.
Apart/beyond the above I herewith share (some of) my thoughts on the more
technical topics the roadmap for 2014 and beyond should address.
I agree with Adrian and Jacques on the subject of CMS. Transformation of
OFBiz to solutions like Drupal et al is not needed. However, these
solutions have an evolved set of functionalities in order to integrate
components/plug-ins/add-ons, whether they are in the area of themes or
bespoke solutions like payment and shipment processors and others.
If I am correct, solutions like the big-fish (by Nick Rosser and his team)
, and the add-on manager (in Apache Extra - by the people of Nereide) are
steps in that direction. Maybe we can learn from these and others and
expand on them.
*Re: slimdown*
The path set in the recent past regarding slim down is a good path. This
should be continued. But, slim down should not be about only focussing on
the framework. More visibility on the website should be created regarding
vision and roadmap. In the past also several apps/components/functions have
been earmarked as eligible for slimdown roadmap, but little actions have
been undertaken. I believe this has to do with fear. Fear that OFBiz is on
a path of self-destruction (becoming a framework-only solution, as seen
from the original viewpoint of the project), or - when not in a
framework-only roadmap - that there will be a diminished ownership by the
project. More communication regarding this issue should be undertaken.
As for payment and shipment processors, these all should move from current
place in applications (accounting and product) to hot-deployable components
(per payment processor, per shipment processor).. This way, each processor
can be selected and deployed when needed. It also creates more visibility
regarding the flexibility of the system, due to the fact that there are
plugins available that cater to customers/users specific needs. Plus it
might attract new solution developers to build/maintain these optionals.
But that requires more and unified communication.
I recently undertook the endeavour to move the iDEAL payment processor from
accounting to Apache Extra (see issues
OFBIZ-5303<https://issues.apache.org/jira/browse/OFBIZ-5303>
and OFBIZ-5443 <https://issues.apache.org/jira/browse/OFBIZ-5443>), and
after evaluating the solution I came to conclusion that it is
broken/malfunctioning in its current design. While it is a pity that it is
as it is, and a shame that it was incorporated in accounting without
due-diligence, it is good that it is moved (as part of slimdown). It
improves the quality of the base component and makes the solution more
accessible. When more specific solutions move this way, the better it is.
Perceived quality of the total package is then less defined by the
individual component/solution/function (depending of course on the
viewpoint of the viewer).
*Focus should (also) be on performance, scalability and configurability*
Good performance increases the user experience. This involves both
Above-the-Line (screen build up - client side) and Below-the-Line (data
retrieval, logging, mail processing, etc - server side).
Regarding AtL (Above-the-Line) this means leaving the concept that we
should only have web 1.0 functionality in components and apply web 2.0
functionality more and more.
Good performance also means minimizing the loops to include javascript
functions in screens and forms. Think of the date and lookup renderers. Per
line in overviews these functions are included whereas they could (and
should) be in a javascript file and called from there.
Of course, given the number of screens and forms in all the components this
means a lot of work, but Rome wasn't built in one day either.
Regarding BtL (Below-the-Line) this means more (better?) scalability
functions, but also configurability of where and when functions and
processes should be executed. Of course, this is related to multi-server
setups and multi-tenancy implementations.
This should also include deployability on external servers. This seems to
be broken and outdated.
Regarding configurability I see that we currently have over 1200
configurable properties in .properties files. Some of these are used for
startup, some for development, some for deployment and some for testing.
And there are overlapping situations. But the majority of the properties
are to be used in production environment. In single (internal)
organisation, single tenant (default) and single server setup this is ok
as it works. But in a multi (internal) organisation, multi tenant and multi
server setup this is inadequate. In such scenarios the default values on
user, organisation and tenant level must also be set and act like in
.properties files act like failovers
Properties like accounting.payment.salesorder.autocreate,
finaccount.decimals, java.naming.provider.url (for ldap configuration) and
eventReminders.emailFromAddress, to name but a few . Though I haven't gone
through the entire list extensively to date and Adrian stated in a comment
regarding issue
OFBIZ-5458<https://issues.apache.org/jira/browse/OFBIZ-5458> that
several (property defined) values are retrieved from database as an
override to the property definition, but where it is done is ambiguous and
un-clear.
In my opinion this should work as follows:
1. retrieve from user preference, with failing over to
2. retrieve from organisation preference/setup, with failing over to
3. retrieve from tenant preference/setup, with failing over to
4. retrieve from .property file
I believe this should be taken up, thus ensuring that it get clearer where
and when a value is retrieved. Ensuring also increase of quality and
decrease of ambiguity.
*Re: maintainability*
Over the past year several add-ons have been included in Ant build
functions to use Apache Ivy as the engine to download jars required by
specific functions. E.g. for PostgreSQL Activemq, Cobertura and Sonar. This
should be expanded more, as it lessens the burden on maintenance and size
of svn checkouts and distributions. Given that always a build phase is
required when having downloaded OFBiz, this build phase could retrieve the
jar (and other) files required. Using Apache Ivy more, could also
circumvent the licensing issues regarding external products, as none of the
external products are actually included in distributions.
*Re: integrateability*
With regards to integration with other solutions I would like to see the
uptake of a solution like Apache Shiro regarding authentication,
authorization, etc. Especially related to multi-tenancy.
In general, the pool of solutions in the Apache Marketspace (top level
project, etc) is vast and I would say that there are plenty that could be
integrated with. And we already re-use a lot of functionalities of other
products. But this could go further.
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
No, the issue isn't closed. I was merely expressing an opinion. This
type of thread is all about everyone sharing their ideas and opinions
and when we find a consensus or general support for an idea we add it to
the Wiki page. So, please don't feel like I am shutting the idea down.
I agree the eCommerce application needs work, and I agree its appearance
could have an effect on adoption.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/4/2014 3:57 PM, Gavin Mabie wrote:
> Hi Adrian
>
> Interesting historical perspective. Quick question .. does this mean that
> the issue has been closed? By the way, I'm not suggesting that Ofbiz be
> made more Drupal/WordPress-like generally. That would be ridiculous. I'm
> also not talking about CMS. Rather, my idea is more focussed on the theme
> development area, a functionality already existing in Ofbiz but which does
> not enjoy much attention. The ecommerce frontend is the first impression
> that most first time users get about the system and as such it represents
> the whole Ofbiz brand. I would venture to say that most first time
> visitors would be inclined to abandon any further exploration based on
> their first impression. It is therefore imperative that more attention be
> given to this area.
>
> Regards
>
> Gavin
>
>
> On Sat, Jan 4, 2014 at 8:09 PM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
>> I have participated in a number of discussions along this line -
>> beginning with the 2007 developers conference. My perspective back then
>> hasn't changed - instead of trying to make OFBiz more Drupal-like or more
>> WordPress-like, let's leave the job of CMS to existing products and find
>> ways to connect those products to OFBiz.
>>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 1/4/2014 12:28 PM, Gavin Mabie wrote:
>>
>>> Hi Guys
>>>
>>> Best wishes to everybody for 2014. I would like to support the
>>> prioritisation of theme development for 2014. Jacques, I noticed that you
>>> are specifically talking about backend widget
>>> forms. What about ecommerce? IMO that little attention is given to
>>> frontend design and even less is done to accommodate design-orientated
>>> developers. Theme developement in Ofbiz has a long way to go if it is to
>>> reach the levels of standardisation, ease and portability attained and
>>> used
>>> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
>>> Magento. Keep up the good work.
>>>
>>> Gavin
>>>
>>>
>>> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> 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 adrian.crum@sandglass-
>>>> software.comwrote
>>>>
>>>>> 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
>>>>
>>>>
>>>
>
Re: OFBiz In 2014
Posted by Gavin Mabie <kw...@gmail.com>.
Hi Adrian
Interesting historical perspective. Quick question .. does this mean that
the issue has been closed? By the way, I'm not suggesting that Ofbiz be
made more Drupal/WordPress-like generally. That would be ridiculous. I'm
also not talking about CMS. Rather, my idea is more focussed on the theme
development area, a functionality already existing in Ofbiz but which does
not enjoy much attention. The ecommerce frontend is the first impression
that most first time users get about the system and as such it represents
the whole Ofbiz brand. I would venture to say that most first time
visitors would be inclined to abandon any further exploration based on
their first impression. It is therefore imperative that more attention be
given to this area.
Regards
Gavin
On Sat, Jan 4, 2014 at 8:09 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> I have participated in a number of discussions along this line -
> beginning with the 2007 developers conference. My perspective back then
> hasn't changed - instead of trying to make OFBiz more Drupal-like or more
> WordPress-like, let's leave the job of CMS to existing products and find
> ways to connect those products to OFBiz.
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/4/2014 12:28 PM, Gavin Mabie wrote:
>
>> Hi Guys
>>
>> Best wishes to everybody for 2014. I would like to support the
>> prioritisation of theme development for 2014. Jacques, I noticed that you
>> are specifically talking about backend widget
>> forms. What about ecommerce? IMO that little attention is given to
>> frontend design and even less is done to accommodate design-orientated
>> developers. Theme developement in Ofbiz has a long way to go if it is to
>> reach the levels of standardisation, ease and portability attained and
>> used
>> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
>> Magento. Keep up the good work.
>>
>> Gavin
>>
>>
>> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> 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 adrian.crum@sandglass-
>>> software.comwrote
>>>
>>>> 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
>>>
>>>
>>
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
I plently agree, this is what http://www.cato-commerce.com/ do for instance
OFBiz ecommerce frontend is just there to show what's possible to do with OFBiz in this area.
Jacques
On Saturday, January 04, 2014 7:09 PM adrian.crum@sandglass-software.com wrote
> I have participated in a number of discussions along this line -
> beginning with the 2007 developers conference. My perspective back then
> hasn't changed - instead of trying to make OFBiz more Drupal-like or
> more WordPress-like, let's leave the job of CMS to existing products and
> find ways to connect those products to OFBiz.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/4/2014 12:28 PM, Gavin Mabie wrote:
>> Hi Guys
>>
>> Best wishes to everybody for 2014. I would like to support the
>> prioritisation of theme development for 2014. Jacques, I noticed that you
>> are specifically talking about backend widget
>> forms. What about ecommerce? IMO that little attention is given to
>> frontend design and even less is done to accommodate design-orientated
>> developers. Theme developement in Ofbiz has a long way to go if it is to
>> reach the levels of standardisation, ease and portability attained and used
>> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
>> Magento. Keep up the good work.
>>
>> Gavin
>>
>>
>> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> 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 adrian.crum@sandglass-software.comwrote
>>>> 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
Re: OFBiz In 2014
Posted by Young Gu <hy...@gmail.com>.
Freemarker? For template, thymeleaf maybe a better alternative, it's UI
designer friendly.
Cheers
Young Gu | Senior Software Engineer | www.infor.com <http://killgfw.com/>
On Sun, Jan 5, 2014 at 2:09 AM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> I have participated in a number of discussions along this line -
> beginning with the 2007 developers conference. My perspective back then
> hasn't changed - instead of trying to make OFBiz more Drupal-like or more
> WordPress-like, let's leave the job of CMS to existing products and find
> ways to connect those products to OFBiz.
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 1/4/2014 12:28 PM, Gavin Mabie wrote:
>
>> Hi Guys
>>
>> Best wishes to everybody for 2014. I would like to support the
>> prioritisation of theme development for 2014. Jacques, I noticed that you
>> are specifically talking about backend widget
>> forms. What about ecommerce? IMO that little attention is given to
>> frontend design and even less is done to accommodate design-orientated
>> developers. Theme developement in Ofbiz has a long way to go if it is to
>> reach the levels of standardisation, ease and portability attained and
>> used
>> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
>> Magento. Keep up the good work.
>>
>> Gavin
>>
>>
>> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> 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 adrian.crum@sandglass-
>>> software.comwrote
>>>
>>>> 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
>>>
>>>
>>
Re: OFBiz In 2014
Posted by Ean Schuessler <ea...@brainfood.com>.
Heartily agreed. At Brainfood we also feel it is a better strategy to integrate with those systems than to compete with them. That is the direction we have been moving in with our client development work.
----- "Adrian Crum" <ad...@sandglass-software.com> wrote:
> I have participated in a number of discussions along this line -
> beginning with the 2007 developers conference. My perspective back
> then
> hasn't changed - instead of trying to make OFBiz more Drupal-like or
> more WordPress-like, let's leave the job of CMS to existing products
> and
> find ways to connect those products to OFBiz.
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
I have participated in a number of discussions along this line -
beginning with the 2007 developers conference. My perspective back then
hasn't changed - instead of trying to make OFBiz more Drupal-like or
more WordPress-like, let's leave the job of CMS to existing products and
find ways to connect those products to OFBiz.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/4/2014 12:28 PM, Gavin Mabie wrote:
> Hi Guys
>
> Best wishes to everybody for 2014. I would like to support the
> prioritisation of theme development for 2014. Jacques, I noticed that you
> are specifically talking about backend widget
> forms. What about ecommerce? IMO that little attention is given to
> frontend design and even less is done to accommodate design-orientated
> developers. Theme developement in Ofbiz has a long way to go if it is to
> reach the levels of standardisation, ease and portability attained and used
> in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
> Magento. Keep up the good work.
>
> Gavin
>
>
> On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> 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 adrian.crum@sandglass-software.comwrote
>>> 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
>>
>
Re: OFBiz In 2014
Posted by Gavin Mabie <kw...@gmail.com>.
Hi Guys
Best wishes to everybody for 2014. I would like to support the
prioritisation of theme development for 2014. Jacques, I noticed that you
are specifically talking about backend widget
forms. What about ecommerce? IMO that little attention is given to
frontend design and even less is done to accommodate design-orientated
developers. Theme developement in Ofbiz has a long way to go if it is to
reach the levels of standardisation, ease and portability attained and used
in CMS apps like Drupal, WordPress etc. and Ecommerce packages like
Magento. Keep up the good work.
Gavin
On Sat, Jan 4, 2014 at 6:52 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> 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 adrian.crum@sandglass-software.comwrote
> > 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
>
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
Looking at it another way, with screen widgets you can replace the
existing FreeMarker macros with your own - so the UI can look like anything.
I recently did that for 1Tech Ltd - where I replaced the HTML markup
with Sencha JavaScript.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 1/4/2014 1:09 PM, Anil K Patel 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" <ja...@les7arts.com>
> To: dev@ofbiz.apache.org
> 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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
For instance you could there share your thoughts about VisualThemeResource...
Jacques
On Monday, January 06, 2014 2:45 PM, adrian.crum@sandglass-software.com 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 <
>> jacques.le.roux@les7arts.com> 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 anil.patel@hotwaxmedia.com 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" <ja...@les7arts.com>
>>>> To: dev@ofbiz.apache.org
>>>> 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 adrian.crum@sandglass-software.comwrote
>>>>> 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
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
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 <
> jacques.le.roux@les7arts.com> 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 anil.patel@hotwaxmedia.com 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" <ja...@les7arts.com>
>>> To: dev@ofbiz.apache.org
>>> 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 adrian.crum@sandglass-software.comwrote
>>>> 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
>>
>
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Raj,
I added your propostion in the section
Services exposed as RESTful web services
Jacques
On Wednesday, January 29, 2014 5:29 AM, rajbsaini@yahoo.com wrote
> I like this idea and I have been working for a while for the front end
> e-commerce sites. We have been using custom themes based on Bootstrap
> and backbone.js and AngularJS. You can see this in action at
> http://www.thecharmworks.com/.
>
> For the back office application, I would like to see all services
> exposed as RESTful web services and client side UI using a MVC framework
> such as AngularJS with responsive CSS framework such as Bootstrap.
> Client side UI will mainly use the Ajax requests and AngularJS MVC takes
> care of updating the UI.
>
> Thanks,
>
> Raj
>
>
> On Monday, January 06, 2014 7:09 PM, ean@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" <kw...@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
Re: OFBiz In 2014
Posted by Rajbir Saini <ra...@yahoo.com>.
I like this idea and I have been working for a while for the front end
e-commerce sites. We have been using custom themes based on Bootstrap
and backbone.js and AngularJS. You can see this in action at
http://www.thecharmworks.com/.
For the back office application, I would like to see all services
exposed as RESTful web services and client side UI using a MVC framework
such as AngularJS with responsive CSS framework such as Bootstrap.
Client side UI will mainly use the Ajax requests and AngularJS MVC takes
care of updating the UI.
Thanks,
Raj
On Monday, January 06, 2014 7:09 PM, ean@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" <kw...@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
Re: OFBiz In 2014
Posted by Ean Schuessler <ea...@brainfood.com>.
Yes. I do have interest in the UI approach. You might just call it
"client UI refactoring".
----- "Jacques Le Roux" <ja...@les7arts.com> wrote:
> Ean should I create a specific section for this feature (please name
> it), and would you be interested to help?
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
Ean should I create a specific section for this feature (please name it), and would you be interested to help?
Jacques
On Monday, January 06, 2014 7:09 PM, ean@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" <kw...@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
Re: OFBiz In 2014
Posted by Adrian Crum <ad...@sandglass-software.com>.
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, adrian.crum@sandglass-software.com wrote:
>
>> Quoting "David E. Jones" <de...@me.com>:
>>
>>>
>>> On Jan 6, 2014, at 12:26 PM, adrian.crum@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?
>
> 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
>
>
Re: OFBiz In 2014
Posted by "David E. Jones" <de...@me.com>.
On Jan 6, 2014, at 12:58 PM, adrian.crum@sandglass-software.com wrote:
> Quoting "David E. Jones" <de...@me.com>:
>
>>
>> On Jan 6, 2014, at 12:26 PM, adrian.crum@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?
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
Re: OFBiz In 2014
Posted by ad...@sandglass-software.com.
Quoting "David E. Jones" <de...@me.com>:
>
> On Jan 6, 2014, at 12:26 PM, adrian.crum@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" <de...@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 <ea...@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" <kw...@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
>>>> ean@brainfood.com
>>>> 214-720-0700 x 315
>>>> Brainfood, Inc.
>>>> http://www.brainfood.com
>>>
>>>
>>
>>
>>
>
>
Re: OFBiz In 2014
Posted by "David E. Jones" <de...@me.com>.
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 <pi...@gmail.com> 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
Re: OFBiz In 2014
Posted by Pierre Smits <pi...@gmail.com>.
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
Re: OFBiz In 2014
Posted by "David E. Jones" <de...@me.com>.
On Jan 6, 2014, at 12:26 PM, adrian.crum@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.
-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" <de...@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 <ea...@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" <kw...@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
>>> ean@brainfood.com
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>
>>
>
>
>
Re: OFBiz In 2014
Posted by ad...@sandglass-software.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" <de...@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 <ea...@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" <kw...@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
>> ean@brainfood.com
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>
>
Re: OFBiz In 2014
Posted by "David E. Jones" <de...@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 <ea...@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" <kw...@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
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
Re: OFBiz In 2014
Posted by Ean Schuessler <ea...@brainfood.com>.
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" <kw...@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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: OFBiz In 2014
Posted by Gavin Mabie <kw...@gmail.com>.
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 <
jacques.le.roux@les7arts.com> 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 anil.patel@hotwaxmedia.com 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" <ja...@les7arts.com>
> > To: dev@ofbiz.apache.org
> > 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 adrian.crum@sandglass-software.comwrote
> >> 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
>
Re: OFBiz In 2014
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 anil.patel@hotwaxmedia.com 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" <ja...@les7arts.com>
> To: dev@ofbiz.apache.org
> 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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Anil K Patel <an...@hotwaxmedia.com>.
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" <ja...@les7arts.com>
To: dev@ofbiz.apache.org
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 adrian.crum@sandglass-software.com 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
Re: OFBiz In 2014
Posted by Anil K Patel <an...@hotwaxmedia.com>.
My preference is to use freemarker. With Form widgets, Its nearly impossible to deliver UI/UX for todays.
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" <ja...@les7arts.com>
To: dev@ofbiz.apache.org
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 adrian.crum@sandglass-software.com 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