subject:"Re\: OFBiz In 2014"

Maybe it is of no issue, but no comments can be added as well.

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Feb 7, 2014 at 4:43 PM, Pierre Smits  wrote:

> Jacques,
>
> I can see the changes in the restrictions, but still am not able to
> update. Maybe there is some delay, or other constraint.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Fri, Feb 7, 2014 at 4:28 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> This question because I followed
>> https://confluence.atlassian.com/display/CONF50/Setting+a+Page%27s+Restrictionsand
>>  added the contributors (edit mode) with the other groups (admin and
>> committers)
>> And since it seems to not work, being curious I looked into the
>> restrained pages in the OFBADMIN space and I saw that the PMC page has been
>> restrained to all users (confluence-users in edit mode)
>> So you should be able to edit this page also.
>>
>> It seems something does not work with the groups.
>>
>> Now I have added you only, could you retry? Weirdly when I add you, it
>> adds me also  :/ (can't be removed, not a big deal, but weird)
>>
>> Jacques
>>
>> On Friday, February 07, 2014 3:13 PM, pierre.sm...@gmail.com wrote
>> > Hi Jacques,
>> >
>> > No, I can't. Nor should I be able to, as I am not a member of either
>> group
>> > op persons mentioned there.
>> >
>> > Regards,
>> >
>> > Pierre Smits
>> >
>> > *ORRTIZ.COM *
>> > Services & Solutions for Cloud-
>> > Based Manufacturing, Professional
>> > Services and Retail & Trade
>> > http://www.orrtiz.com
>> >
>> >
>> > On Fri, Feb 7, 2014 at 2:20 PM, Jacques Le Roux <
>> > jacques.le.r...@les7arts.com> wrote:
>> >
>> >> Can you modify this page
>> >>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+%28Project+Management+Committee%29+Members+and+Committers
>> ?
>> >>
>> >> Jacques
>> >>
>> >> On Friday, February 07, 2014 12:40 PM, pierre.sm...@gmail.com wrote
>> >>> Jacques,
>> >>>
>> >>> I don't see any changes.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Pierre Smits
>> >>>
>> >>> *ORRTIZ.COM *
>> >>> Services & Solutions for Cloud-
>> >>> Based Manufacturing, Professional
>> >>> Services and Retail & Trade
>> >>> http://www.orrtiz.com
>>
>
>

Re: OFBiz In 2014

Jacques,

I can see the changes in the restrictions, but still am not able to update.
Maybe there is some delay, or other constraint.

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Feb 7, 2014 at 4:28 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> This question because I followed
> https://confluence.atlassian.com/display/CONF50/Setting+a+Page%27s+Restrictionsand
>  added the contributors (edit mode) with the other groups (admin and
> committers)
> And since it seems to not work, being curious I looked into the restrained
> pages in the OFBADMIN space and I saw that the PMC page has been restrained
> to all users (confluence-users in edit mode)
> So you should be able to edit this page also.
>
> It seems something does not work with the groups.
>
> Now I have added you only, could you retry? Weirdly when I add you, it
> adds me also  :/ (can't be removed, not a big deal, but weird)
>
> Jacques
>
> On Friday, February 07, 2014 3:13 PM, pierre.sm...@gmail.com wrote
> > Hi Jacques,
> >
> > No, I can't. Nor should I be able to, as I am not a member of either
> group
> > op persons mentioned there.
> >
> > Regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> >
> > On Fri, Feb 7, 2014 at 2:20 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Can you modify this page
> >>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+%28Project+Management+Committee%29+Members+and+Committers
> ?
> >>
> >> Jacques
> >>
> >> On Friday, February 07, 2014 12:40 PM, pierre.sm...@gmail.com wrote
> >>> Jacques,
> >>>
> >>> I don't see any changes.
> >>>
> >>> Regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM *
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
>

Re: OFBiz In 2014

2014-02-07 Thread Jacques Le Roux

This question because I followed 
https://confluence.atlassian.com/display/CONF50/Setting+a+Page%27s+Restrictions 
and added the contributors (edit mode) with the other groups (admin and 
committers)
And since it seems to not work, being curious I looked into the restrained 
pages in the OFBADMIN space and I saw that the PMC page has been restrained to 
all users (confluence-users in edit mode) 
So you should be able to edit this page also. 

It seems something does not work with the groups. 

Now I have added you only, could you retry? Weirdly when I add you, it adds me 
also  :/ (can't be removed, not a big deal, but weird)

Jacques

On Friday, February 07, 2014 3:13 PM, pierre.sm...@gmail.com wrote
> Hi Jacques,
> 
> No, I can't. Nor should I be able to, as I am not a member of either group
> op persons mentioned there.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Fri, Feb 7, 2014 at 2:20 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Can you modify this page
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+%28Project+Management+Committee%29+Members+and+Committers?
>> 
>> Jacques
>> 
>> On Friday, February 07, 2014 12:40 PM, pierre.sm...@gmail.com wrote
>>> Jacques,
>>> 
>>> I don't see any changes.
>>> 
>>> Regards,
>>> 
>>> Pierre Smits
>>> 
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com

Re: OFBiz In 2014

Hi Jacques,

No, I can't. Nor should I be able to, as I am not a member of either group
op persons mentioned there.

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Fri, Feb 7, 2014 at 2:20 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Can you modify this page
> https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+%28Project+Management+Committee%29+Members+and+Committers?
>
> Jacques
>
> On Friday, February 07, 2014 12:40 PM, pierre.sm...@gmail.com wrote
> > Jacques,
> >
> > I don't see any changes.
> >
> > Regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
>

Re: OFBiz In 2014

2014-02-07 Thread Jacques Le Roux

Can you modify this page 
https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+PMC+%28Project+Management+Committee%29+Members+and+Committers
 ?

Jacques

On Friday, February 07, 2014 12:40 PM, pierre.sm...@gmail.com wrote
> Jacques,
> 
> I don't see any changes.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com

Re: OFBiz In 2014

Jacques,

I don't see any changes.

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-02-05 Thread Jacques Le Roux

I guess you mean 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Should be done normally, I have temporarilly added the modification permission 
to all contributors for this page, please check.

Jacques

On Wednesday, February 05, 2014 1:54 PM, pierre.sm...@gmail.com wrote
> Jacques,
> 
> Would you please add me to the editors of the document.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com

Re: OFBiz In 2014

2014-02-05 Thread Pierre Smits

Jacques,

Would you please add me to the editors of the document.

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-02-03 Thread Jacques Le Roux

OK, By and large, I think it's better to let people handle change in this page 
themselves (those who have no access should ask of course)

I'd love to have a roadmap page derived from this one (simplified). But if it's 
only wishful thinking I don't see any interests.

Jacques

On Friday, January 31, 2014 11:30 AM, jacques.le.r...@les7arts.com wrote
> Jacopo,
> 
> While at it, should I create sections and add you in the
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>  page? 
> 
> Jacques
> 
> On Monday, January 06, 2014 10:03 AM, jacopo.cappell...@hotwaxmedia.com wrote
>> First of all, I would like to mention our tentative roadmap for the releases:
>> 
>> • February 2014 - Apache OFBiz 13.07.01
>> • March 2014 - Apache OFBiz 12.04.03
>> • April 2014 - Apache OFBiz 11.04.04 (last release of the 11.04 series?)
>> • August 2014 - Apache OFBiz 13.07.02
>> • September 2014 - Apache OFBiz 12.04.04
>> 
>> Summarizing, the new year 2014 will see the last release in the 11.04 series 
>> and the new releases in the 13.07 series; we will
>> also issue 2 maintenance releases in the 12.04 series. We will also probably 
>> create a new release branch (14.?). This is going to
>> be a lot of work and if we will be able to implement this release roadmap it 
>> will be a good achievement for the community.
>> 
>> Then, here is my personal wish list:
>> 
>> * integrate Atomikos Transaction Manager (to replace the existing old and 
>> incomplete Geronimo Transaction Manager); I did most of
>> the work some time ago and also Scott helped me; but the effort is not 
>> completed (but we are close); this is on hold at the
>> moment and it would be great to give it a final push
>> * refactor the Product Search engine (and related data model) and replace it 
>> with a Lucene/Solr driven search; the same pattern
>> could then be applied to other areas of the system; this would make the 
>> searches fast and scalable and also reduce greatly the
>> codebase and remove load from the relational database
>> * redesign security/authorization; there are different paths here (Adrian 
>> did some refactoring work already) but I would love to
>> consider the integration with something like Apache Shiro: this would help 
>> to enhance the features we offer and also remove a big
>> chunk of framework code
>> * complete the support for the Groovy DSL: I have a working patch to extend 
>> its support to all screen/widget code: with it you
>> can write the same groovy code for services, events and widgets (data prep 
>> scripts): in order to complete the support for data
>> prep scripts my patch needs more work
>> * continue and improve the maintenance effort of the OFBiz codebase: upgrade 
>> of external jars to latest releases, removal of
>> old/unused stuff, better documentation of jar interdependencies, code 
>> review/enhancements, bug fixes, further modularization and
>> slim down etc...
>> * about releases: start (again) the discussion and define a plan for issuing 
>> separately the framework from the applications
>> 
>> Jacopo
>> 
>> On Dec 31, 2013, at 1:55 PM, Adrian Crum 
>>  wrote:
>> 
>>> Maybe we can use the start of the new year as an opportunity to consider 
>>> the future of OFBiz and update our road map:
>>> 
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>>> 
>>> 
>>> --
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com

Re: New+Features+Roadmap+-+Living+Document [was Re: OFBiz In 2014]

2014-02-03 Thread Jacques Le Roux

Hi,

It's now more than a week that I sent this message. I will begin to prune the 
page.
Please correct yourself (no needs to ask me), using the history in case of 
issues

Jacques

On Sunday, January 26, 2014 8:35 PM, jacques.le.r...@les7arts.com wrote
> Hi All,
> 
> I send a copy to all persons who have expressed the *will to help* on this 
> page
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
> 
> Please confirm you still want to do so, and if we should keep those entries 
> open, what are their status, etc.
> In other words, please help to keep this page up to date, before we get to a 
> new step
> 
> Without answers for specific sections, I will simply remove them.
> 
> For instance I confirm the VAT support is not complete. I have a draft for 
> reports I never completed (not a high priority for
> now) but would want to commit one day, so I don't close this entry. 
> Also I still want to improve SFA, but I must day it depends on clients 
> request I will cross... or not... Still I prefer to not
> close. 
> 
> Are the followintg entries not completed?
> * Implement Asset management application
> * Implement Project Management Application
> * Complete the implementation of the Accounting component
> 
> Should we keep?
> * Improve the Content Management Component
> 
> Should we not add a reference to the JackRabbit branch? Sascha put 
> respectable efforts in it...
> 
> I will continue, when I will have some time, to prune the "UI (User 
> Interface) enhancements" section...
> 
> Like Pierre suggested, rather than to have new dicussions on dev ML where 
> consensus and goals are sometimes lost in time
> afterward,  this could be a good place to build an up to date roadmap which 
> OFBiz really lacks. It would be excellent if we could
> put dates in regard to goals, even if they are not reached, then we will 
> update... This does not mean that we should not have
> dicussions in dev ML, but that the status and goals should be updated on this 
> page.  
> 
> Let me knonw if you think it's realistic for OFBiz to have a roadmap, and it 
> this page fits for a start.
> 
> Thanks
> 
> Jacques
> 
> On Wednesday, January 22, 2014 3:16 PM, pierre.sm...@gmail.com wrote
>> Thanks for bringing up the issue. I had forgotten that one.
>> 
>> Pierre Smits
>> 
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>> 
>> 
>> On Wed, Jan 22, 2014 at 3:16 PM, Pierre Smits wrote:
>> 
>>> Christian, all,
>>> 
>>> Actually, the original intent of 
>>> OFBIZ-5307 is
>>> covered in current functionality. But yes, the ' in-situ adding
>>> materials, production resources and outputs of end and by-products' aspects
>>> regarding my help with the Manufacturing component align to my comments
>>> made in that issue.
>>> 
>>> Pierre Smits
>>> 
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>> 
>>> 
>>> On Wed, Jan 22, 2014 at 2:39 PM, Christian Carlow <
>>> christian.car...@gmail.com> wrote:
>>> 
 Pierre,
 
 I assume you are referring to OFBIZ-5307 - Reverse/Inverted/Breeder Bill
 Of Materials?
 
 If so it's relevant for my needs as well so if I would be of any help I
 will likely to provide it.
 
 
 On 01/21/2014 05:08 PM, Pierre Smits wrote:
 
> Jacques,
> 
> I am willing to help on:
> 
> Manufacturing improvement, especially regarding lifecycle mgt of recipes
> (BoM and production schema) and on in-situ adding materials, production
> resources and outputs of end and by-products (like we had the discussion
> about back in September last year).
> 
> Expense Declaration
> (OFBIZ-5473
> 
> )
> 
> And on the ivy integration
> (OFBIZ-5464
> 
> ).
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>  Hi Nicolas,
>> 
>> That's a good news. I will soon follow Pierre's suggestion to email all
>> persons who registered on this page to clean the status of each entry.
>> 
>> Jacques
>> 
>> On Monday, January 20, 2014 9:39 PM, malin.nicolas@librenberry.netwrote
>> 
>>> Le 31/12/2013 13:55, Adrian Crum a écrit :
>>> 
 Maybe we can use the start of the new year as an opportunity to
 consider the future of OFBiz and update our road map:

Re: OFBiz In 2014

2014-01-31 Thread Jacques Le Roux

Jacopo,

While at it, should I create sections and add you in the 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
 page?

Jacques

On Monday, January 06, 2014 10:03 AM, jacopo.cappell...@hotwaxmedia.com wrote
> First of all, I would like to mention our tentative roadmap for the releases:
> 
> • February 2014 - Apache OFBiz 13.07.01
> • March 2014 - Apache OFBiz 12.04.03
> • April 2014 - Apache OFBiz 11.04.04 (last release of the 11.04 series?)
> • August 2014 - Apache OFBiz 13.07.02
> • September 2014 - Apache OFBiz 12.04.04
> 
> Summarizing, the new year 2014 will see the last release in the 11.04 series 
> and the new releases in the 13.07 series; we will
> also issue 2 maintenance releases in the 12.04 series. We will also probably 
> create a new release branch (14.?). This is going to
> be a lot of work and if we will be able to implement this release roadmap it 
> will be a good achievement for the community.  
> 
> Then, here is my personal wish list:
> 
> * integrate Atomikos Transaction Manager (to replace the existing old and 
> incomplete Geronimo Transaction Manager); I did most of
> the work some time ago and also Scott helped me; but the effort is not 
> completed (but we are close); this is on hold at the
> moment and it would be great to give it a final push  
> * refactor the Product Search engine (and related data model) and replace it 
> with a Lucene/Solr driven search; the same pattern
> could then be applied to other areas of the system; this would make the 
> searches fast and scalable and also reduce greatly the
> codebase and remove load from the relational database  
> * redesign security/authorization; there are different paths here (Adrian did 
> some refactoring work already) but I would love to
> consider the integration with something like Apache Shiro: this would help to 
> enhance the features we offer and also remove a big
> chunk of framework code  
> * complete the support for the Groovy DSL: I have a working patch to extend 
> its support to all screen/widget code: with it you
> can write the same groovy code for services, events and widgets (data prep 
> scripts): in order to complete the support for data
> prep scripts my patch needs more work  
> * continue and improve the maintenance effort of the OFBiz codebase: upgrade 
> of external jars to latest releases, removal of
> old/unused stuff, better documentation of jar interdependencies, code 
> review/enhancements, bug fixes, further modularization and
> slim down etc...  
> * about releases: start (again) the discussion and define a plan for issuing 
> separately the framework from the applications
> 
> Jacopo
> 
> On Dec 31, 2013, at 1:55 PM, Adrian Crum  
> wrote:
> 
>> Maybe we can use the start of the new year as an opportunity to consider the 
>> future of OFBiz and update our road map:
>> 
>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>> 
>> 
>> --
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com

Re: OFBiz In 2014

2014-01-30 Thread Jacques Le Roux

Hi Nicolas,

Before engaging an effort on the "UI (User Interface) enhancements" section, I 
want to check and possibly split this section into
more accurate sub-sections, to clarify things. But this part is clearly 
identified, so I see no problems with your proposition. 

To be sure we are on the same page. For this case, the idea was to offer an 
alternative to non ending menus bars with tons of
buttons which are barely legible (beware you get used to it, which distorts 
your perception). So, by default, to keep only visible
the main ones and to hide the others in a dropdown menu. With also a repetition 
of the menu bar at bottom if necessary (long pages, implies dropdown in both 
directions, mmm). This is now more obvious with FlatGrey than the other themes 
which use dropdown menus. But only for the main options, so the problem remains 
there also.

Keep also in mind that only Tomahawk and FlatGrey are now released, though the 
others are not (yet?) deprecated. I wonder about
that, because really the evolutions which ended with Tomahawk are not as good, 
though very similar apart the colors. For now it's
not a pain to maintain, since we did not change much things. But if we try to 
improve it could be an issue. I experienced it a bit
when upgrading the javascript libs and plugins recently...   

Nevertheless, if we engage in such an effort, we need to create an user 
preference to allow both modes. Also, as it seems you
suggested, maybe a something more modern than that could be done using 
portlets... 
Thinking about it, I think what we miss is a main option (like languages or 
themes) to allow an user to set her/his preferences.

Jacques


On Wednesday, January 29, 2014 11:19 PM, malin.nico...@librenberry.net wrote
> Thanks jacques :)
> 
> For the UI (User Interface) enhancements do you have a preference to
> would be interesting to work ? (all of course ! but  priority and
> interest :) ).
> 
> I have little experience and feedback on screen/portlet, I can start by
> the second screenlet subject :
>  "It was also suggesteed to use screenlet like how gmail does. Notably
> 
>  * Three buttons max
>  * Dropdown for other actions
>  * The idea of duplicating at bottom"
> 
> Nicolas
> 
> 
> 
> 
> Le 27/01/2014 22:51, Jacques Le Roux a écrit :
>> Hi Nicolas,
>> 
>> You are in: 
>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>> 
>> Jacques
>> 
>> On Monday, January 20, 2014 10:03 PM, jacques.le.r...@les7arts.com wrote
>>> Hi Nicolas,
>>> 
>>> That's a good news. I will soon follow Pierre's suggestion to email all 
>>> persons who registered on this page to clean the status
>>> of each entry.
>>> 
>>> Jacques
>>> 
>>> On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
 Le 31/12/2013 13:55, Adrian Crum a écrit :
> Maybe we can use the start of the new year as an opportunity to
> consider the future of OFBiz and update our road map:
> 
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
> 
> 
> 
 I'm interested  to help some commiter on subject as :
   * Screen and Form widget enhancements
   * Complete the migration of older bsh/ftl files to widgets
   * UI (User Interface) enhancements
 
 We have some good feedback on UI (and some error that I prefer escape ;) ).
 I planned between 2 and 4 hours per week to works only on OFBiz.
 
 Regards,
 
 Nicolas

Re: OFBiz In 2014

2014-01-29 Thread Nicolas Malin

Thanks jacques :)

For the UI (User Interface) enhancements do you have a preference to
would be interesting to work ? (all of course ! but priority and
interest :) ).

I have little experience and feedback on screen/portlet, I can start by
the second screenlet subject :

"It was also suggesteed to use screenlet like how gmail does. Notably

* Three buttons max
* Dropdown for other actions
* The idea of duplicating at bottom"

Nicolas

Le 27/01/2014 22:51, Jacques Le Roux a écrit :

Hi Nicolas,

You are in:
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

On Monday, January 20, 2014 10:03 PM, jacques.le.r...@les7arts.com wrote

Hi Nicolas,

That's a good news. I will soon follow Pierre's suggestion to email all persons
who registered on this page to clean the status
of each entry.

Jacques

On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote

Le 31/12/2013 13:55, Adrian Crum a écrit :

Maybe we can use the start of the new year as an opportunity to
consider the future of OFBiz and update our road map:

https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

I'm interested to help some commiter on subject as :
* Screen and Form widget enhancements
* Complete the migration of older bsh/ftl files to widgets
* UI (User Interface) enhancements

We have some good feedback on UI (and some error that I prefer escape ;) ).
I planned between 2 and 4 hours per week to works only on OFBiz.

Regards,

Nicolas

Re: OFBiz In 2014

2014-01-29 Thread Jacques Le Roux

Ean,

Your are in for 2 new sections: Client UI refactoring & Introduce Websocket 
usage and as interested by 
Theme framework (Bootstrap, Zurb, etc.) integration (for both back and frontend)

See: 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

On Wednesday, January 29, 2014 1:42 AM, e...@brainfood.com wrote
> I can help refit the existing widget templates. However, As I said in my 
> message,
> we are much less focused on server side generation these days. It may be
> interesting to approach this as a "bridge" where we begin to layer dynamic 
> AJAX
> functionality more aggressively onto the existing widgets.
> 
> - "Jacques Le Roux"  wrote:
> 
>> Maybe 2 sections, if you would want to extend your effort with
>> Boostrap?
>> The idea is to gather work force, you should not be alone. Jonatan for
>> instance also expressed an interest about this feature
>> http://markmail.org/message/i7fnxid55cq5uiiz
>> Adrian suggested that an external framework would not be necessary but
>> it seems he spoke only about ecommerce
>> I think we should think also (only for now?) about backend

Re: OFBiz In 2014

2014-01-29 Thread Jacques Le Roux

Thanks Raj,

I added your propostion in the section 
Services exposed as RESTful web services

Jacques

On Wednesday, January 29, 2014 5:29 AM, rajbsa...@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, e...@brainfood.com wrote
>>> I agree that we should migrate FTL templates to ofbiz widgets for the sake
>>> of consistency throughout the interfaces. However, I do have to say that
>>> I would not use form widgets to develop a customer facing site. At this
>>> point, Brainfood is pretty much at a consensus that we do not want to do
>>> "page template" oriented development in the server at all. When you look at
>>> applications like Google Maps it becomes clear that the "send post, alter
>>> state, regenerate and send page" workflow is incredibly limited. The future
>>> seems to look a lot more like applications written in Javascript that
>>> generate HTML directly in the browser.
>>> 
>>> So, for us, the important feature is the JSON-RPC interface for this remote
>>> applications. It would be genuinely interesting if we could write a client
>>> side form widget interpreter that would delegate generation of the interface
>>> to the client side and then supply the "action" interface via AJAX. That is
>>> something we would be very interested in.
>>> 
>>> Refactoring the widget generation code to support greater modularity in the 
>>> HTML
>>> could be another target of such an effort. I made some modest efforts 
>>> towards
>>> a Bootstrap based OFBiz theme and I found it difficult to make progress 
>>> with the
>>> current setup.
>>> 
>>> - "Gavin Mabie"  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

2014-01-28 Thread Rajbir Saini

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, e...@brainfood.com wrote

I agree that we should migrate FTL templates to ofbiz widgets for the sake
of consistency throughout the interfaces. However, I do have to say that
I would not use form widgets to develop a customer facing site. At this
point, Brainfood is pretty much at a consensus that we do not want to do
"page template" oriented development in the server at all. When you look at
applications like Google Maps it becomes clear that the "send post, alter
state, regenerate and send page" workflow is incredibly limited. The future
seems to look a lot more like applications written in Javascript that
generate HTML directly in the browser.

So, for us, the important feature is the JSON-RPC interface for this remote
applications. It would be genuinely interesting if we could write a client
side form widget interpreter that would delegate generation of the interface
to the client side and then supply the "action" interface via AJAX. That is
something we would be very interested in.

Refactoring the widget generation code to support greater modularity in the HTML
could be another target of such an effort. I made some modest efforts towards
a Bootstrap based OFBiz theme and I found it difficult to make progress with the
current setup.

- "Gavin Mabie"  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

2014-01-28 Thread Ean Schuessler

I can help refit the existing widget templates. However, As I said in my 
message, 
we are much less focused on server side generation these days. It may be
interesting to approach this as a "bridge" where we begin to layer dynamic AJAX
functionality more aggressively onto the existing widgets.

- "Jacques Le Roux"  wrote:

> Maybe 2 sections, if you would want to extend your effort with
> Boostrap?
> The idea is to gather work force, you should not be alone. Jonatan for
> instance also expressed an interest about this feature 
> http://markmail.org/message/i7fnxid55cq5uiiz 
> Adrian suggested that an external framework would not be necessary but
> it seems he spoke only about ecommerce
> I think we should think also (only for now?) about backend

-- 
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: OFBiz In 2014

2014-01-28 Thread Ean Schuessler

Yes. I do have interest in the UI approach. You might just call it
"client UI refactoring".

- "Jacques Le Roux"  wrote:

> Ean should I create a specific section for this feature (please name
> it), and would you be interested to help?

-- 
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: OFBiz In 2014

Gavin I added you in the related section

Jacques

On Saturday, January 04, 2014 6:28 PM, kwikst...@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.r...@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

Ean,

Maybe 2 sections, if you would want to extend your effort with Boostrap?
The idea is to gather work force, you should not be alone. Jonatan for instance 
also expressed an interest about this feature 
http://markmail.org/message/i7fnxid55cq5uiiz 
Adrian suggested that an external framework would not be necessary but it seems 
he spoke only about ecommerce
I think we should think also (only for now?) about backend

Jonatan,
I added you at the section 
Theme framework (Bootstrap, Zurb, etc.) integration (for both back and frontend)

Jacques

On Tuesday, January 28, 2014 11:26 PM, jacques.le.r...@les7arts.com wrote
> 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, e...@brainfood.com wrote
>> I agree that we should migrate FTL templates to ofbiz widgets for the sake
>> of consistency throughout the interfaces. However, I do have to say that
>> I would not use form widgets to develop a customer facing site. At this
>> point, Brainfood is pretty much at a consensus that we do not want to do
>> "page template" oriented development in the server at all. When you look at
>> applications like Google Maps it becomes clear that the "send post, alter
>> state, regenerate and send page" workflow is incredibly limited. The future
>> seems to look a lot more like applications written in Javascript that
>> generate HTML directly in the browser.
>> 
>> So, for us, the important feature is the JSON-RPC interface for this remote
>> applications. It would be genuinely interesting if we could write a client
>> side form widget interpreter that would delegate generation of the interface
>> to the client side and then supply the "action" interface via AJAX. That is
>> something we would be very interested in.
>> 
>> Refactoring the widget generation code to support greater modularity in the 
>> HTML
>> could be another target of such an effort. I made some modest efforts towards
>> a Bootstrap based OFBiz theme and I found it difficult to make progress with 
>> the
>> current setup.
>> 
>> - "Gavin Mabie"  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

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, e...@brainfood.com wrote
> I agree that we should migrate FTL templates to ofbiz widgets for the sake
> of consistency throughout the interfaces. However, I do have to say that
> I would not use form widgets to develop a customer facing site. At this
> point, Brainfood is pretty much at a consensus that we do not want to do
> "page template" oriented development in the server at all. When you look at
> applications like Google Maps it becomes clear that the "send post, alter
> state, regenerate and send page" workflow is incredibly limited. The future
> seems to look a lot more like applications written in Javascript that
> generate HTML directly in the browser.
> 
> So, for us, the important feature is the JSON-RPC interface for this remote
> applications. It would be genuinely interesting if we could write a client
> side form widget interpreter that would delegate generation of the interface
> to the client side and then supply the "action" interface via AJAX. That is
> something we would be very interested in.
> 
> Refactoring the widget generation code to support greater modularity in the 
> HTML
> could be another target of such an effort. I made some modest efforts towards
> a Bootstrap based OFBiz theme and I found it difficult to make progress with 
> the
> current setup.
> 
> - "Gavin Mabie"  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

Hi Pierre,

You are in: 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

On Wednesday, January 22, 2014 12:08 AM, pierre.sm...@gmail.com wrote
> Jacques,
> 
> I am willing to help on:
> 
> Manufacturing improvement, especially regarding lifecycle mgt of recipes
> (BoM and production schema) and on in-situ adding materials, production
> resources and outputs of end and by-products (like we had the discussion
> about back in September last year).
> 
> Expense Declaration
> (OFBIZ-5473
> )
> 
> And on the ivy integration
> (OFBIZ-5464
> ).
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> 
>> Hi Nicolas,
>> 
>> That's a good news. I will soon follow Pierre's suggestion to email all
>> persons who registered on this page to clean the status of each entry.
>> 
>> Jacques
>> 
>> On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
>>> Le 31/12/2013 13:55, Adrian Crum a écrit :
 Maybe we can use the start of the new year as an opportunity to
 consider the future of OFBiz and update our road map:
 
 
>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
 
 
 
>>> I'm interested  to help some commiter on subject as :
>>>  * Screen and Form widget enhancements
>>>  * Complete the migration of older bsh/ftl files to widgets
>>>  * UI (User Interface) enhancements
>>> 
>>> We have some good feedback on UI (and some error that I prefer escape ;) ).
>>> I planned between 2 and 4 hours per week to works only on OFBiz.
>>> 
>>> Regards,
>>> 
>>> Nicolas

Re: New+Features+Roadmap+-+Living+Document [was Re: OFBiz In 2014]

2014-01-27 Thread Jacques Le Roux

Hi Paul,

I totally agree for the priority

You are in: 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

On Monday, January 27, 2014 10:30 AM, p...@ilscipio.com wrote
> Hi Jacques,
> 
> personally I think that the clean-up and reimplementation of
> HTML&Supprt-Macros is the biggest challenge for 2014
> (https://issues.apache.org/jira/browse/OFBIZ-5040). You can write me on the
> list of supporters for that task.
> 
> Regards,
> Paul

Re: OFBiz In 2014

2014-01-27 Thread Jacques Le Roux

Hi Nicolas,

You are in: 
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

On Monday, January 20, 2014 10:03 PM, jacques.le.r...@les7arts.com wrote
> Hi Nicolas,
> 
> That's a good news. I will soon follow Pierre's suggestion to email all 
> persons who registered on this page to clean the status
> of each entry. 
> 
> Jacques
> 
> On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
>> Le 31/12/2013 13:55, Adrian Crum a écrit :
>>> Maybe we can use the start of the new year as an opportunity to
>>> consider the future of OFBiz and update our road map:
>>> 
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>>> 
>>> 
>>> 
>> I'm interested  to help some commiter on subject as :
>>  * Screen and Form widget enhancements
>>  * Complete the migration of older bsh/ftl files to widgets
>>  * UI (User Interface) enhancements
>> 
>> We have some good feedback on UI (and some error that I prefer escape ;) ).
>> I planned between 2 and 4 hours per week to works only on OFBiz.
>> 
>> Regards,
>> 
>> Nicolas

Re: New+Features+Roadmap+-+Living+Document [was Re: OFBiz In 2014]

2014-01-27 Thread Paul Piper

Hi Jacques,

personally I think that the clean-up and reimplementation of
HTML&Supprt-Macros is the biggest challenge for 2014
(https://issues.apache.org/jira/browse/OFBIZ-5040). You can write me on the
list of supporters for that task.

Regards,
Paul



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/OFBiz-In-2014-tp4646641p4647757.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

New+Features+Roadmap+-+Living+Document [was Re: OFBiz In 2014]

2014-01-26 Thread Jacques Le Roux

Hi All,

I send a copy to all persons who have expressed the *will to help* on this page
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Please confirm you still want to do so, and if we should keep those entries 
open, what are their status, etc.
In other words, please help to keep this page up to date, before we get to a 
new step

Without answers for specific sections, I will simply remove them.

For instance I confirm the VAT support is not complete. I have a draft for 
reports I never completed (not a high priority for now) but would want to 
commit one day, so I don't close this entry.
Also I still want to improve SFA, but I must day it depends on clients request 
I will cross... or not... Still I prefer to not close.

Are the followintg entries not completed?
* Implement Asset management application
* Implement Project Management Application
* Complete the implementation of the Accounting component

Should we keep?
* Improve the Content Management Component

Should we not add a reference to the JackRabbit branch? Sascha put respectable 
efforts in it...

I will continue, when I will have some time, to prune the "UI (User Interface) 
enhancements" section...

Like Pierre suggested, rather than to have new dicussions on dev ML where 
consensus and goals are sometimes lost in time afterward,  this could be a good 
place to build an up to date roadmap which OFBiz really lacks. It would be 
excellent if we could put dates in regard to goals, even if they are not 
reached, then we will update...
This does not mean that we should not have dicussions in dev ML, but that the 
status and goals should be updated on this page.

Let me knonw if you think it's realistic for OFBiz to have a roadmap, and it 
this page fits for a start.

Thanks

Jacques

On Wednesday, January 22, 2014 3:16 PM, pierre.sm...@gmail.com wrote
> Thanks for bringing up the issue. I had forgotten that one.
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Wed, Jan 22, 2014 at 3:16 PM, Pierre Smits wrote:
> 
>> Christian, all,
>> 
>> Actually, the original intent of 
>> OFBIZ-5307 is
>> covered in current functionality. But yes, the ' in-situ adding
>> materials, production resources and outputs of end and by-products' aspects
>> regarding my help with the Manufacturing component align to my comments
>> made in that issue.
>> 
>> Pierre Smits
>> 
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>> 
>> 
>> On Wed, Jan 22, 2014 at 2:39 PM, Christian Carlow <
>> christian.car...@gmail.com> wrote:
>> 
>>> Pierre,
>>> 
>>> I assume you are referring to OFBIZ-5307 - Reverse/Inverted/Breeder Bill
>>> Of Materials?
>>> 
>>> If so it's relevant for my needs as well so if I would be of any help I
>>> will likely to provide it.
>>> 
>>> 
>>> On 01/21/2014 05:08 PM, Pierre Smits wrote:
>>> 
 Jacques,

 I am willing to help on:

 Manufacturing improvement, especially regarding lifecycle mgt of recipes
 (BoM and production schema) and on in-situ adding materials, production
 resources and outputs of end and by-products (like we had the discussion
 about back in September last year).

 Expense Declaration
 (OFBIZ-5473

 )

 And on the ivy integration
 (OFBIZ-5464

 ).

 Regards,

 Pierre Smits

 *ORRTIZ.COM *
 Services & Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail & Trade
 http://www.orrtiz.com

 On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
 jacques.le.r...@les7arts.com> wrote:

  Hi Nicolas,
> 
> That's a good news. I will soon follow Pierre's suggestion to email all
> persons who registered on this page to clean the status of each entry.
> 
> Jacques
> 
> On Monday, January 20, 2014 9:39 PM, malin.nicolas@librenberry.netwrote
> 
>> Le 31/12/2013 13:55, Adrian Crum a écrit :
>> 
>>> Maybe we can use the start of the new year as an opportunity to
>>> consider the future of OFBiz and update our road map:
>>> 
>>> 
>>>  https://cwiki.apache.org/confluence/display/OFBADMIN/
> New+Features+Roadmap+-+Living+Document
> 
>> 
>>> 
>>>  I'm interested  to help some commiter on subject as :
>>   * Screen and Form widget enhancements
>>   * Complete the migration of older bsh/ftl files to widgets
>>   * UI (User Interface) enhancements
>> 
>> We have some good feedback on UI (and some error that I prefer escap

Re: OFBiz In 2014

2014-01-22 Thread Pierre Smits

Thanks for bringing up the issue. I had forgotten that one.

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Wed, Jan 22, 2014 at 3:16 PM, Pierre Smits wrote:

> Christian, all,
>
> Actually, the original intent of 
> OFBIZ-5307 is
> covered in current functionality. But yes, the ' in-situ adding
> materials, production resources and outputs of end and by-products' aspects
> regarding my help with the Manufacturing component align to my comments
> made in that issue.
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Wed, Jan 22, 2014 at 2:39 PM, Christian Carlow <
> christian.car...@gmail.com> wrote:
>
>> Pierre,
>>
>> I assume you are referring to OFBIZ-5307 - Reverse/Inverted/Breeder Bill
>> Of Materials?
>>
>> If so it's relevant for my needs as well so if I would be of any help I
>> will likely to provide it.
>>
>>
>> On 01/21/2014 05:08 PM, Pierre Smits wrote:
>>
>>> Jacques,
>>>
>>> I am willing to help on:
>>>
>>> Manufacturing improvement, especially regarding lifecycle mgt of recipes
>>> (BoM and production schema) and on in-situ adding materials, production
>>> resources and outputs of end and by-products (like we had the discussion
>>> about back in September last year).
>>>
>>> Expense Declaration
>>> (OFBIZ-5473
>>>
>>> )
>>>
>>> And on the ivy integration
>>> (OFBIZ-5464
>>>
>>> ).
>>>
>>> Regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>>
>>> On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>>  Hi Nicolas,

 That's a good news. I will soon follow Pierre's suggestion to email all
 persons who registered on this page to clean the status of each entry.

 Jacques

 On Monday, January 20, 2014 9:39 PM, malin.nicolas@librenberry.netwrote

> Le 31/12/2013 13:55, Adrian Crum a écrit :
>
>> Maybe we can use the start of the new year as an opportunity to
>> consider the future of OFBiz and update our road map:
>>
>>
>>  https://cwiki.apache.org/confluence/display/OFBADMIN/
 New+Features+Roadmap+-+Living+Document

>
>>
>>  I'm interested  to help some commiter on subject as :
>   * Screen and Form widget enhancements
>   * Complete the migration of older bsh/ftl files to widgets
>   * UI (User Interface) enhancements
>
> We have some good feedback on UI (and some error that I prefer escape
> ;)
>
 ).

> I planned between 2 and 4 hours per week to works only on OFBiz.
>
> Regards,
>
> Nicolas
>

>>
>

Re: OFBiz In 2014

2014-01-22 Thread Pierre Smits

Christian, all,

Actually, the original intent of
OFBIZ-5307 is
covered in current functionality. But yes, the ' in-situ adding materials,
production resources and outputs of end and by-products' aspects regarding
my help with the Manufacturing component align to my comments made in that
issue.

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Wed, Jan 22, 2014 at 2:39 PM, Christian Carlow <
christian.car...@gmail.com> wrote:

> Pierre,
>
> I assume you are referring to OFBIZ-5307 - Reverse/Inverted/Breeder Bill
> Of Materials?
>
> If so it's relevant for my needs as well so if I would be of any help I
> will likely to provide it.
>
>
> On 01/21/2014 05:08 PM, Pierre Smits wrote:
>
>> Jacques,
>>
>> I am willing to help on:
>>
>> Manufacturing improvement, especially regarding lifecycle mgt of recipes
>> (BoM and production schema) and on in-situ adding materials, production
>> resources and outputs of end and by-products (like we had the discussion
>> about back in September last year).
>>
>> Expense Declaration
>> (OFBIZ-5473
>>
>> )
>>
>> And on the ivy integration
>> (OFBIZ-5464
>>
>> ).
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>  Hi Nicolas,
>>>
>>> That's a good news. I will soon follow Pierre's suggestion to email all
>>> persons who registered on this page to clean the status of each entry.
>>>
>>> Jacques
>>>
>>> On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
>>>
 Le 31/12/2013 13:55, Adrian Crum a écrit :

> Maybe we can use the start of the new year as an opportunity to
> consider the future of OFBiz and update our road map:
>
>
>  https://cwiki.apache.org/confluence/display/OFBADMIN/
>>> New+Features+Roadmap+-+Living+Document
>>>

>
>  I'm interested  to help some commiter on subject as :
   * Screen and Form widget enhancements
   * Complete the migration of older bsh/ftl files to widgets
   * UI (User Interface) enhancements

 We have some good feedback on UI (and some error that I prefer escape ;)

>>> ).
>>>
 I planned between 2 and 4 hours per week to works only on OFBiz.

 Regards,

 Nicolas

>>>
>

Re: OFBiz In 2014

2014-01-22 Thread Christian Carlow


Pierre,

I assume you are referring to OFBIZ-5307 - Reverse/Inverted/Breeder Bill 
Of Materials?


If so it's relevant for my needs as well so if I would be of any help I 
will likely to provide it.


On 01/21/2014 05:08 PM, Pierre Smits wrote:

Jacques,

I am willing to help on:

Manufacturing improvement, especially regarding lifecycle mgt of recipes
(BoM and production schema) and on in-situ adding materials, production
resources and outputs of end and by-products (like we had the discussion
about back in September last year).

Expense Declaration
(OFBIZ-5473
)

And on the ivy integration
(OFBIZ-5464
).

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi Nicolas,

That's a good news. I will soon follow Pierre's suggestion to email all
persons who registered on this page to clean the status of each entry.

Jacques

On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote

Le 31/12/2013 13:55, Adrian Crum a écrit :

Maybe we can use the start of the new year as an opportunity to
consider the future of OFBiz and update our road map:



https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document




I'm interested  to help some commiter on subject as :
  * Screen and Form widget enhancements
  * Complete the migration of older bsh/ftl files to widgets
  * UI (User Interface) enhancements

We have some good feedback on UI (and some error that I prefer escape ;)

).

I planned between 2 and 4 hours per week to works only on OFBiz.

Regards,

Nicolas

Re: OFBiz In 2014

2014-01-21 Thread Pierre Smits

Jacques,

I am willing to help on:

Manufacturing improvement, especially regarding lifecycle mgt of recipes
(BoM and production schema) and on in-situ adding materials, production
resources and outputs of end and by-products (like we had the discussion
about back in September last year).

Expense Declaration
(OFBIZ-5473
)

And on the ivy integration
(OFBIZ-5464
).

Regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Mon, Jan 20, 2014 at 10:03 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Nicolas,
>
> That's a good news. I will soon follow Pierre's suggestion to email all
> persons who registered on this page to clean the status of each entry.
>
> Jacques
>
> On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
> > Le 31/12/2013 13:55, Adrian Crum a écrit :
> >> Maybe we can use the start of the new year as an opportunity to
> >> consider the future of OFBiz and update our road map:
> >>
> >>
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
> >>
> >>
> >>
> > I'm interested  to help some commiter on subject as :
> >  * Screen and Form widget enhancements
> >  * Complete the migration of older bsh/ftl files to widgets
> >  * UI (User Interface) enhancements
> >
> > We have some good feedback on UI (and some error that I prefer escape ;)
> ).
> > I planned between 2 and 4 hours per week to works only on OFBiz.
> >
> > Regards,
> >
> > Nicolas
>

Re: OFBiz In 2014

2014-01-20 Thread Jacques Le Roux

Hi Nicolas,

That's a good news. I will soon follow Pierre's suggestion to email all persons 
who registered on this page to clean the status of each entry.

Jacques

On Monday, January 20, 2014 9:39 PM, malin.nico...@librenberry.net wrote
> Le 31/12/2013 13:55, Adrian Crum a écrit :
>> Maybe we can use the start of the new year as an opportunity to
>> consider the future of OFBiz and update our road map:
>> 
>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>> 
>> 
>> 
> I'm interested  to help some commiter on subject as :
>  * Screen and Form widget enhancements
>  * Complete the migration of older bsh/ftl files to widgets
>  * UI (User Interface) enhancements
> 
> We have some good feedback on UI (and some error that I prefer escape ;) ).
> I planned between 2 and 4 hours per week to works only on OFBiz.
> 
> Regards,
> 
> Nicolas

Re: OFBiz In 2014

2014-01-20 Thread Malin Nicolas


Le 31/12/2013 13:55, Adrian Crum a écrit :
Maybe we can use the start of the new year as an opportunity to 
consider the future of OFBiz and update our road map:


https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document 





I'm interested  to help some commiter on subject as :
 * Screen and Form widget enhancements
 * Complete the migration of older bsh/ftl files to widgets
 * UI (User Interface) enhancements

We have some good feedback on UI (and some error that I prefer escape ;) ).
I planned between 2 and 4 hours per week to works only on OFBiz.

Regards,

Nicolas

Re: OFBiz In 2014

2014-01-12 Thread Pierre Smits

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 *
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.r...@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 *
>  Services & Solutions for Cloud-
>  Based Manufacturing, Professional
>  Services and Retail & Trade
>  http://www.orrtiz.com
>

Re: OFBiz In 2014

2014-01-11 Thread Jacques Le Roux

On Sunday, January 12, 2014 12:23 AM, adrian.c...@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.c...@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)
 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 *
 Services & Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail & Trade
 http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-11 Thread Adrian Crum


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.c...@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)
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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-11 Thread Jacques Le Roux

Done, please double-check

Jacques

On Sunday, January 05, 2014 2:37 PM, adrian.c...@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)
>> 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 *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-07 Thread Jacques Le Roux

For instance you could there share your thoughts about VisualThemeResource...

Jacques

On Monday, January 06, 2014 2:45 PM, adrian.c...@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.r...@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.pa...@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" 
>>>> 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

2014-01-06 Thread Adrian Crum


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.c...@sandglass-software.com wrote:


Quoting "David E. Jones" :



On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:


There are two problems with using DOM trees in OFBiz:

1. They consume a lot of memory. Keep in mind the entire XML file is kept in 
memory, not just the bits you are interested in.


The parsed version is kept in memory, that is true, but for each 
screen/form/etc you just keep the node object for the top-level element. Under 
that element the only stuff it would keep around by default that you don't 
need/want (but could be eliminated with a little code) is comment elements.


2. They are not thread-safe.


They should be used read-only, so unless someone does something funny thread 
safety isn't an issue. On that note, the same is true for the shared objects in 
the current OFBiz widget implementations.



And that is the problem we have now. Many contributors/committers will not understand 
what should and shouldn't be done with DOM nodes, and consequently they will do things 
they shouldn't. History has proven that, given the opportunity, OFBiz developers will 
"do something funny" with the code.

Over the last few years, the framework code-base has been moving toward 
immutable shared objects, and I think that is the safest strategy to use. We 
have fixed numerous bugs going that route.

I understand your perspective and I appreciate it - make code thread-unsafe for 
the sake of convenience. But that strategy exists currently in OFBiz legacy 
code and it keeps hurting us.

What I find interesting about your proposal is how similar it is to what I 
proposed years ago - make the widgets lightweight representations of their XML 
files. The screen widget models would contain Lists of model Elements, and the 
model Elements would contain Maps of Element Attributes. At the time you 
rejected that idea - you said performance would suffer by making the widget 
models that generic. Now you're suggesting we skip the models altogether and 
just use the DOM tree. So, what has changed your opinion?


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), th

Re: OFBiz In 2014

On Jan 6, 2014, at 12:58 PM, adrian.c...@sandglass-software.com wrote:

> Quoting "David E. Jones" :
> 
>> 
>> On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:
>> 
>>> There are two problems with using DOM trees in OFBiz:
>>> 
>>> 1. They consume a lot of memory. Keep in mind the entire XML file is kept 
>>> in memory, not just the bits you are interested in.
>> 
>> The parsed version is kept in memory, that is true, but for each 
>> screen/form/etc you just keep the node object for the top-level element. 
>> Under that element the only stuff it would keep around by default that you 
>> don't need/want (but could be eliminated with a little code) is comment 
>> elements.
>> 
>>> 2. They are not thread-safe.
>> 
>> They should be used read-only, so unless someone does something funny thread 
>> safety isn't an issue. On that note, the same is true for the shared objects 
>> in the current OFBiz widget implementations.
> 
> 
> And that is the problem we have now. Many contributors/committers will not 
> understand what should and shouldn't be done with DOM nodes, and consequently 
> they will do things they shouldn't. History has proven that, given the 
> opportunity, OFBiz developers will "do something funny" with the code.
> 
> Over the last few years, the framework code-base has been moving toward 
> immutable shared objects, and I think that is the safest strategy to use. We 
> have fixed numerous bugs going that route.
> 
> I understand your perspective and I appreciate it - make code thread-unsafe 
> for the sake of convenience. But that strategy exists currently in OFBiz 
> legacy code and it keeps hurting us.
> 
> What I find interesting about your proposal is how similar it is to what I 
> proposed years ago - make the widgets lightweight representations of their 
> XML files. The screen widget models would contain Lists of model Elements, 
> and the model Elements would contain Maps of Element Attributes. At the time 
> you rejected that idea - you said performance would suffer by making the 
> widget models that generic. Now you're suggesting we skip the models 
> altogether and just use the DOM tree. So, what has changed your opinion?

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 n

Re: OFBiz In 2014

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  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 *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-06 Thread adrian . crum

Quoting "David E. Jones" :

On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:

There are two problems with using DOM trees in OFBiz:

1. They consume a lot of memory. Keep in mind the entire XML file
is kept in memory, not just the bits you are interested in.

The parsed version is kept in memory, that is true, but for each
screen/form/etc you just keep the node object for the top-level
element. Under that element the only stuff it would keep around by
default that you don't need/want (but could be eliminated with a
little code) is comment elements.

2. They are not thread-safe.

They should be used read-only, so unless someone does something
funny thread safety isn't an issue. On that note, the same is true
for the shared objects in the current OFBiz widget implementations.

And that is the problem we have now. Many contributors/committers will
not understand what should and shouldn't be done with DOM nodes, and
consequently they will do things they shouldn't. History has proven
that, given the opportunity, OFBiz developers will "do something
funny" with the code.

Over the last few years, the framework code-base has been moving
toward immutable shared objects, and I think that is the safest
strategy to use. We have fixed numerous bugs going that route.

I understand your perspective and I appreciate it - make code
thread-unsafe for the sake of convenience. But that strategy exists
currently in OFBiz legacy code and it keeps hurting us.

What I find interesting about your proposal is how similar it is to
what I proposed years ago - make the widgets lightweight
representations of their XML files. The screen widget models would
contain Lists of model Elements, and the model Elements would contain
Maps of Element Attributes. At the time you rejected that idea - you
said performance would suffer by making the widget models that
generic. Now you're suggesting we skip the models altogether and just
use the DOM tree. So, what has changed your opinion?

-Adrian

-David

I did some refactoring a while ago where I replaced that approach
with a thread-safe approach. But that was done in other parts of
the framework, not in the screen widgets.

-Adrian

Quoting "David E. Jones" :

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">
cols="${.node["@cols"]!"60"}" rows="${.node["@rows"]!"3"}"<#if
.node["@read-only"]!"false" == "true">
readonly="readonly"<#if .node["@maxlength"]?has_content>
maxlength="${.node["@maxlength"]}" id="<@fieldId
.node/>"<#if .node?parent["@tooltip"]?has_content>
title="${.node?parent["@tooltip"]}">${sri.getFieldValueString(.node?parent?parent, .node["@default-value"]!"",
null)?html}

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 wo

Re: OFBiz In 2014

2014-01-06 Thread Pierre Smits

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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-06 Thread adrian . crum

It would be interesting to see the performance impact of that approach.

I overhauled Mini-language recently and in the process I made sure the
execution path was as short and straight as possible. That effort
produced a 40% performance improvement. I wonder how Java's
compile-time linking compares with Groovy's time spent in the
reflection API.

I agree it would be wonderful to have screen widgets inherit
Mini-language in their elements.

-Adrian

Quoting "David E. Jones" :

One of my top annoyances with OFBiz coding is the inconsistency of
tools, especially the scripts and expressions within widgets and
simple-methods.

A first step would be to make all expressions, conditions, etc use
Groovy instead of JUEL and the bits of BeanShell that are still
used. Groovy has a lot of convenient stuff that JUEL and BeanShell
do not, and when coding I find it takes so much more work to
understand and work with the differences and the more cumbersome
syntax that I (and I've noticed many others) hacking around this
limitation with the ${groovy: ...} expressions, which are fine but
then have type conversion issues as this is really a string
expansion syntax. The whole FlexibleStringExpander could just call
into Groovy for evaluation instead of the various things plus
calling into JUEL that it currently does.

A bigger step would be to change the simple-method processing to be
just a FTL template that creates a Groovy script from the XML, and
then compile/cache/run the Groovy script. This has the added
benefits of dramatically simplifying the framework code (no need for
a Java class for each XML element), and makes it easy to do inline
Groovy scripts in simple-methods.

With either approach it would be nice to make the simple-method and
screen/form/etc actions blocks use the same XSD and be processed the
same way for better consistency (fewer surprises during dev and
testing, more general flexibility too).

As I do development with both Moqui and OFBiz I find this to be one
of the biggest differences that makes working with Moqui Framework
faster and less frustrating than with OFBiz. There are many
differences between the two frameworks, but this one stands out to
me as perhaps the most significant when working day-to-day, and
should be one of the easier ones to incorporate. Most existing
expressions written for JUEL should evaluate fine in Groovy, but
some would have to change... that would be the biggest impact of
this change on existing code.

-David

On Dec 31, 2013, at 4:55 AM, Adrian Crum
wrote:

Maybe we can use the start of the new year as an opportunity to
consider the future of OFBiz and update our road map:

https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

--
Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: OFBiz In 2014


On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:

> There are two problems with using DOM trees in OFBiz:
> 
> 1. They consume a lot of memory. Keep in mind the entire XML file is kept in 
> memory, not just the bits you are interested in.

The parsed version is kept in memory, that is true, but for each 
screen/form/etc you just keep the node object for the top-level element. Under 
that element the only stuff it would keep around by default that you don't 
need/want (but could be eliminated with a little code) is comment elements.

> 2. They are not thread-safe.

They should be used read-only, so unless someone does something funny thread 
safety isn't an issue. On that note, the same is true for the shared objects in 
the current OFBiz widget implementations.

-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" :
> 
>> 
>> 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">
>>> rows="${.node["@rows"]!"3"}"<#if .node["@read-only"]!"false" == "true"> 
>> readonly="readonly"<#if .node["@maxlength"]?has_content> 
>> maxlength="${.node["@maxlength"]}" id="<@fieldId .node/>"<#if 
>> .node?parent["@tooltip"]?has_content> 
>> title="${.node?parent["@tooltip"]}">${sri.getFieldValueString(.node?parent?parent,
>>  .node["@default-value"]!"", null)?html}
>> 
>> 
>> 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  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

Re: OFBiz In 2014

One of my top annoyances with OFBiz coding is the inconsistency of tools, 
especially the scripts and expressions within widgets and simple-methods.

A first step would be to make all expressions, conditions, etc use Groovy 
instead of JUEL and the bits of BeanShell that are still used. Groovy has a lot 
of convenient stuff that JUEL and BeanShell do not, and when coding I find it 
takes so much more work to understand and work with the differences and the 
more cumbersome syntax that I (and I've noticed many others) hacking around 
this limitation with the ${groovy: ...} expressions, which are fine but then 
have type conversion issues as this is really a string expansion syntax. The 
whole FlexibleStringExpander could just call into Groovy for evaluation instead 
of the various things plus calling into JUEL that it currently does.

A bigger step would be to change the simple-method processing to be just a FTL 
template that creates a Groovy script from the XML, and then compile/cache/run 
the Groovy script. This has the added benefits of dramatically simplifying the 
framework code (no need for a Java class for each XML element), and makes it 
easy to do inline Groovy scripts in simple-methods.

With either approach it would be nice to make the simple-method and 
screen/form/etc actions blocks use the same XSD and be processed the same way 
for better consistency (fewer surprises during dev and testing, more general 
flexibility too).

As I do development with both Moqui and OFBiz I find this to be one of the 
biggest differences that makes working with Moqui Framework faster and less 
frustrating than with OFBiz. There are many differences between the two 
frameworks, but this one stands out to me as perhaps the most significant when 
working day-to-day, and should be one of the easier ones to incorporate. Most 
existing expressions written for JUEL should evaluate fine in Groovy, but some 
would have to change... that would be the biggest impact of this change on 
existing code.

-David

On Dec 31, 2013, at 4:55 AM, Adrian Crum  
wrote:

> Maybe we can use the start of the new year as an opportunity to consider the 
> future of OFBiz and update our road map:
> 
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
> 
> 
> -- 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com

Re: OFBiz In 2014

2014-01-06 Thread adrian . crum

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" :

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">
cols="${.node["@cols"]!"60"}" rows="${.node["@rows"]!"3"}"<#if
.node["@read-only"]!"false" == "true"> readonly="readonly"<#if
.node["@maxlength"]?has_content>
maxlength="${.node["@maxlength"]}" id="<@fieldId .node/>"<#if
.node?parent["@tooltip"]?has_content>
title="${.node?parent["@tooltip"]}">${sri.getFieldValueString(.node?parent?parent, .node["@default-value"]!"",
null)?html}

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).

-David

On Jan 6, 2014, at 10:09 AM, Ean Schuessler 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" 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
framework

Re: OFBiz In 2014

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">

readonly="readonly"<#if .node["@maxlength"]?has_content> 
maxlength="${.node["@maxlength"]}" id="<@fieldId .node/>"<#if 
.node?parent["@tooltip"]?has_content> 
title="${.node?parent["@tooltip"]}">${sri.getFieldValueString(.node?parent?parent,
 .node["@default-value"]!"", null)?html}

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  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"  wrote:
> 
>> It appears that the citing of Drupal/WordPress/Magento solicited quite
>> a
>> lot of comment.  It's a side issue really and whether some houses
>> prefer to
>> integrate existing solutions is besides the point.  More importantly,
>> most
>> commentators would agree that theme developement in Ofbiz does require
>> more
>> attention.  The vast majority of threads on this ML focuss on backend
>> business rules and processes.  That in itself is not a problem - if
>> you
>> regard Ofbiz as a Framework only.  It only means that, as far as
>> frameworks
>> go, we need a better framework for theming as well.  This will
>> encourage
>> more participation from developers who have more of a front-end
>> orientation.  I would support a drive towards better "themeability"
>> in
>> 2014.  In this regard I would like to suggest that we take a look at
>> the
>> VisualThemeResource entity which currently is currently poorly
>> defined.
>> 
>> Gavin
> 
> -- 
> Ean Schuessler, CTO
> e...@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.br

Re: OFBiz In 2014

On Jan 6, 2014, at 5:09 AM, Jacques Le Roux  
wrote:

> On Monday, January 06, 2014 10:03 AM, jacopo.cappell...@hotwaxmedia.com wrote
>> Then, here is my personal wish list:
>> 
>> * integrate Atomikos Transaction Manager (to replace the existing old and 
>> incomplete Geronimo Transaction Manager); I did most
>> of the work some time ago and also Scott helped me; but the effort is not 
>> completed (but we are close); this is on hold at the
>> moment and it would be great to give it a final push
> 
> Just as a note: it seems David experienced some issue with Atomikos in Moqui 
> OOTB http://tinyurl.com/pwefeoo
> And you have sometimes to use workaround config (Postgres needs it for 
> instance, reported David)

Related to this I've been testing more with Bitronix BTM recently and it seems 
to be doing much better than Atomikos in various scenarios. Part of my 
frustration with Atomikos is the lack of bug fixes going into open source 
releases. They put them in the subscriber-only releases for a few months to 
over a year before putting them in the open source releases, meaning the lag 
time for bug fixes and support for open source users (including open source 
projects that may be used commercially) is significant.

-David

Re: OFBiz In 2014

2014-01-06 Thread Ean Schuessler

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"  wrote:

> It appears that the citing of Drupal/WordPress/Magento solicited quite
> a
> lot of comment.  It's a side issue really and whether some houses
> prefer to
> integrate existing solutions is besides the point.  More importantly,
> most
> commentators would agree that theme developement in Ofbiz does require
> more
> attention.  The vast majority of threads on this ML focuss on backend
> business rules and processes.  That in itself is not a problem - if
> you
> regard Ofbiz as a Framework only.  It only means that, as far as
> frameworks
> go, we need a better framework for theming as well.  This will
> encourage
> more participation from developers who have more of a front-end
> orientation.  I would support a drive towards better "themeability"
> in
> 2014.  In this regard I would like to suggest that we take a look at
> the
> VisualThemeResource entity which currently is currently poorly
> defined.
> 
> Gavin

-- 
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: OFBiz In 2014

2014-01-06 Thread Adrian Crum


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.r...@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.pa...@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" 
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

2014-01-06 Thread Gavin Mabie

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.r...@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.pa...@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" 
> > 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

2014-01-06 Thread Jacques Le Roux

On Monday, January 06, 2014 10:03 AM, jacopo.cappell...@hotwaxmedia.com wrote
> Then, here is my personal wish list:
> 
> * integrate Atomikos Transaction Manager (to replace the existing old and 
> incomplete Geronimo Transaction Manager); I did most
> of the work some time ago and also Scott helped me; but the effort is not 
> completed (but we are close); this is on hold at the
> moment and it would be great to give it a final push

Just as a note: it seems David experienced some issue with Atomikos in Moqui 
OOTB http://tinyurl.com/pwefeoo
And you have sometimes to use workaround config (Postgres needs it for 
instance, reported David)

> * continue and improve the maintenance effort of the OFBiz codebase: upgrade 
> of external jars to latest releases, removal of
> old/unused stuff, better documentation of jar interdependencies, code 
> review/enhancements, bug fixes, further modularization
> and slim down etc...  

Reminder: I wonder if nobody is concerned like me about how we handle security 
at large and notably regarding embedded libs.
I believe we should discuss this, and determine a policy.
1st thing to do would be to verify all libs are currently secure, then to take 
care of it. I now follow CERT for that, but I'm not sure about current status...

Also a last wish for 2014 (no I don't like to repeat myself): I'd love to see 
active committers giving more attention to contributions. Not excluding other 
devs and users of course (test, review, etc.)

Jacques

Re: OFBiz In 2014

2014-01-06 Thread Jacques Le Roux

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.pa...@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" 
> 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.c...@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

2014-01-06 Thread Jacopo Cappellato


On Jan 5, 2014, at 1:52 PM, Pierre Smits  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

2014-01-06 Thread Jacopo Cappellato

On Jan 5, 2014, at 1:52 PM, Pierre Smits  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

2014-01-06 Thread Jacopo Cappellato

First of all, I would like to mention our tentative roadmap for the releases:

• February 2014 - Apache OFBiz 13.07.01
• March 2014 - Apache OFBiz 12.04.03
• April 2014 - Apache OFBiz 11.04.04 (last release of the 11.04 series?)
• August 2014 - Apache OFBiz 13.07.02
• September 2014 - Apache OFBiz 12.04.04

Summarizing, the new year 2014 will see the last release in the 11.04 series 
and the new releases in the 13.07 series; we will also issue 2 maintenance 
releases in the 12.04 series. We will also probably create a new release branch 
(14.?). This is going to be a lot of work and if we will be able to implement 
this release roadmap it will be a good achievement for the community.

Then, here is my personal wish list:

* integrate Atomikos Transaction Manager (to replace the existing old and 
incomplete Geronimo Transaction Manager); I did most of the work some time ago 
and also Scott helped me; but the effort is not completed (but we are close); 
this is on hold at the moment and it would be great to give it a final push
* refactor the Product Search engine (and related data model) and replace it 
with a Lucene/Solr driven search; the same pattern could then be applied to 
other areas of the system; this would make the searches fast and scalable and 
also reduce greatly the codebase and remove load from the relational database
* redesign security/authorization; there are different paths here (Adrian did 
some refactoring work already) but I would love to consider the integration 
with something like Apache Shiro: this would help to enhance the features we 
offer and also remove a big chunk of framework code
* complete the support for the Groovy DSL: I have a working patch to extend its 
support to all screen/widget code: with it you can write the same groovy code 
for services, events and widgets (data prep scripts): in order to complete the 
support for data prep scripts my patch needs more work
* continue and improve the maintenance effort of the OFBiz codebase: upgrade of 
external jars to latest releases, removal of old/unused stuff, better 
documentation of jar interdependencies, code review/enhancements, bug fixes, 
further modularization and slim down etc...
* about releases: start (again) the discussion and define a plan for issuing 
separately the framework from the applications

Jacopo

On Dec 31, 2013, at 1:55 PM, Adrian Crum  
wrote:

> Maybe we can use the start of the new year as an opportunity to consider the 
> future of OFBiz and update our road map:
> 
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
> 
> 
> -- 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com

Re: OFBiz In 2014

2014-01-05 Thread Ean Schuessler

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"  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
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: OFBiz In 2014

2014-01-05 Thread Adrian Crum


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)
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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-05 Thread Pierre Smits

As for the topics in the roadmap document referenced
(this)
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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: OFBiz In 2014

2014-01-05 Thread Pierre Smits

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
 and 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 w

Re: OFBiz In 2014

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.c...@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.r...@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

2014-01-04 Thread Gavin Mabie

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.c...@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.r...@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

2014-01-04 Thread Jacques Le Roux

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.c...@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.r...@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

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" 
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.c...@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

2014-01-04 Thread Jacques Le Roux

Yes, maybe indeed

Jacques

On Saturday, January 04, 2014 7:03 PM adrian.c...@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.c...@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

2014-01-04 Thread Young Gu

Freemarker? For template, thymeleaf maybe a better alternative, it's UI
designer friendly.



Cheers
Young Gu | Senior Software Engineer | www.infor.com 


On Sun, Jan 5, 2014 at 2:09 AM, Adrian Crum <
adrian.c...@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.r...@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

2014-01-04 Thread Anil K Patel

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" 
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.c...@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

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.r...@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.

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

2014-01-04 Thread Anil K Patel

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" 
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.c...@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