Addons for OFBiz

[Jacques Le Roux]

Hi Sharan,

I like the idea but I wonder if we would have enough interest without speaking about the resources...

Jacques

Le 07/05/2015 15:01, Sharan-F a écrit :

> Hi
>
> I also think it's great that this topic has been raised (so thanks Julien).
>
> I would be really keen to participate in any effort that could simplify and
> improve the user experience for OFBiz. Our demo is there to show people what
> OFBiz can do but if it doesn't look very nice or easy to use then we have
> lost them already.  I suppose it's a balance between showing something
> functionally complete against trying to show that it can do everything but
> needs to be customised.
>
> There was an effort a while ago that David started looking at version of
> OFBiz for small businesses called Ezbiz (I think it's still on the
> Requirements and Designs workspace)
> https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz
> <https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz >    but
> it didnt get too far, I think due to lack of support so perhaps this could
> help as a base otherwise we could start again from scratch (or use Julien's
> model so far     ).
>
> Thanks
> Sharan
>
>
>
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Addons-for-OFBiz-tp4668063p4668065.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Sharan-F]

Hi

I was going to raise this topic on the user list under a 'marketing
discussion' because I think there we might find people that are focussed
on the business functionality. I think we first we need to find people
interested in doing something and then once we have that interest, then
we can look at options to implement it. If we can't find the interest
then that tells us something too....

Thanks
Sharan


On 13/05/15 11:51, Jacques Le Roux wrote:

> Hi Sharan,
>
> I like the idea but I wonder if we would have enough interest without
> speaking about the resources...
>
> Jacques
>
> Le 07/05/2015 15:01, Sharan-F a écrit :
>> Hi
>>
>> I also think it's great that this topic has been raised (so thanks
>> Julien).
>>
>> I would be really keen to participate in any effort that could
>> simplify and
>> improve the user experience for OFBiz. Our demo is there to show
>> people what
>> OFBiz can do but if it doesn't look very nice or easy to use then we
>> have
>> lost them already.  I suppose it's a balance between showing something
>> functionally complete against trying to show that it can do
>> everything but
>> needs to be customised.
>>
>> There was an effort a while ago that David started looking at version of
>> OFBiz for small businesses called Ezbiz (I think it's still on the
>> Requirements and Designs workspace)
>> https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz
>> <https://cwiki.apache.org/confluence/display/OFBREQDES/OFBiz+EZBiz 
>> >    but
>> it didnt get too far, I think due to lack of support so perhaps this
>> could
>> help as a base otherwise we could start again from scratch (or use
>> Julien's
>> model so far     ).
>>
>> Thanks
>> Sharan
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Addons-for-OFBiz-tp4668063p4668065.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>

[Sharan-F]

Hi

I think I put together some diagrams about this topic to move the
application components and there was some discussion but I dont think
anything was agreed.

https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress

We can look at using the diagrams as a base for discussions and once
updated they could form the objectives for a workplan.

We do have another Community Day coming up again next month (21st June)
so it could be used as a co-ordinated effort to try and achieve this
move of application components into one place. (Feedback from the last
community day survey said that people wanted a much more co-ordinated
effort). It seems like it could be a good thing to do especially if it
is fairly easy to implement and would provide a lot of benefit.

What do people think?

Thanks
Sharan

On 13/05/15 10:27, Jacopo Cappellato wrote:

> On May 13, 2015, at 10:15 AM, Julien NICOLAS <[hidden email]> wrote:
>
>> Problem is, I want to enhance OFBiz functional part (GUI, Theme, user experience, etc.) but It's really difficult to share it with the community because it must be included in the whole project and it's hard to share your work.
> Hi Julien,
>
> this is an interesting topic, thanks for sharing your thoughts.
> Some time ago I proposed to move all entity definitions from the applications components into a separate one; this component could also contain crud/generic services: in this way it will be easier to deploy the framework+data-model without the user interfaces that are not as generic and universal as the data model is.
> In my opinion this would be a good step in the right direction and it would be very easy to implement.
>
> Regards,
>
> Jacopo
>

[Jacopo Cappellato-5]

On May 13, 2015, at 12:16 PM, Sharan Foga <[hidden email]> wrote:

> We do have another Community Day coming up again next month (21st June) so it could be used as a co-ordinated effort to try and achieve this move of application components into one place. (Feedback from the last community day survey said that people wanted a much more co-ordinated effort). It seems like it could be a good thing to do especially if it is fairly easy to implement and would provide a lot of benefit.
>
> What do people think?

This is a wonderful idea.

Jacopo

[Pierre Smits]

For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
enhance the user experience. Unfortunately the work is not done yet. The
same goes for enhancing the various xsd files (and associated java
functions and ftl scripts) to bring OFBiz widgets up to par with HTML5,
CSS3 etc.

OFBiz contains a ton of business functionalities. Gems hidden in
components. The are, however, not that visible to the - potential - users
due to a number of factors:

   - no descriptive placeholders in the wiki
   - no howto guides
   - overwhelmed by the sheer multitude of clickables when accessing a
   component as the admin user
   - etc


Creating the visibility will be the fuel for more adopters and
contributors. I have started on that path with
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features

Having contributors being able to enhance documentation is not enough.
Funnelling patches on JIRA issues through the few with privileges and
having an interest in helping the non-privileged to enhance business
functionality (even if it is only a small bug fix or improvement) is
detriment to growth. Because when patches aren't reviewed and committed
(when good) in a reasonable time frame, the patches might get stale.

We have lots of people committed to OFBiz. When do we start recognising
that, and enable those contributors to do more?

Best regards,

Pierre Smits

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

>
>

[JulienNicolas]

Hello Pierre,

Le 13/05/2015 12:35, Pierre Smits a écrit :
> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
> enhance the user experience. Unfortunately the work is not done yet.
The problem is that the GUI is a demo GUI. Then all the time you spend
to solve all GUI problems, will potentially lost because nobody use it
(and when I say that I think in particular to the order screen that is a
nightmare...).
It's better that OFBiz embedded GUI web framework (like bootstrap but
not only, it can be bootstrap based tool for dashboard, etc.) and a
documentation on how to use it.

>   The
> same goes for enhancing the various xsd files (and associated java
> functions and ftl scripts) to bring OFBiz widgets up to par with HTML5,
> CSS3 etc.
>
> OFBiz contains a ton of business functionalities. Gems hidden in
> components. The are, however, not that visible to the - potential - users
> due to a number of factors:
>
>     - no descriptive placeholders in the wiki
>     - no howto guides
>     - overwhelmed by the sheer multitude of clickables when accessing a
>     component as the admin user
>     - etc
>
>
> Creating the visibility will be the fuel for more adopters and
> contributors. I have started on that path with
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features

Yes, it's very important as well. Documentation, visibility, marketing.
It's just a matter of priority. Very important VS very very important...

Julien.

>
> Having contributors being able to enhance documentation is not enough.
> Funnelling patches on JIRA issues through the few with privileges and
> having an interest in helping the non-privileged to enhance business
> functionality (even if it is only a small bug fix or improvement) is
> detriment to growth. Because when patches aren't reviewed and committed
> (when good) in a reasonable time frame, the patches might get stale.
>
> We have lots of people committed to OFBiz. When do we start recognising
> that, and enable those contributors to do more?
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>>

[Jacques Le Roux]

Le 13/05/2015 15:04, Julien NICOLAS a écrit :
> Hello Pierre,
>
> Le 13/05/2015 12:35, Pierre Smits a écrit :
>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>> enhance the user experience. Unfortunately the work is not done yet.
> The problem is that the GUI is a demo GUI. Then all the time you spend to solve all GUI problems, will potentially lost because nobody use it (and
> when I say that I think in particular to the order screen that is a nightmare...).
> It's better that OFBiz embedded GUI web framework (like bootstrap but not only, it can be bootstrap based tool for dashboard, etc.) and a
> documentation on how to use it.

I don't know if nobody is using it (I guess some are ;)), but I believe a lot are reusing parts of it. The idea is not only to provide a demo but also
to provide ideas, bricks to be reused. Did you wrote your own totally from scratch :-o (I guess not even considering ideas) ?

Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and JavaScript framework"  and use its artefacts inside widgets?
What are actually the parts you found so bad? How the widgets are generated, the CSS class used, how js is used inside of that, etc. ?

If we go this way (embed a HTML framework in OFBiz) I remember some proposed to use rather foundation, we would need to pick one and only one. Like
wed did with jQuery as the main js lib that BTW we need to keep!

Also some have proposed to get further and use something like Angular https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287 or
Backbone https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989 you name it...

https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering see
https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2

We need to make delicate choices and quickly, time is flying...

Jacques

[Jacques Le Roux]

Le 13/05/2015 16:35, Jacques Le Roux a écrit :

> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>> Hello Pierre,
>>
>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>> enhance the user experience. Unfortunately the work is not done yet.
>> The problem is that the GUI is a demo GUI. Then all the time you spend to solve all GUI problems, will potentially lost because nobody use it (and
>> when I say that I think in particular to the order screen that is a nightmare...).
>> It's better that OFBiz embedded GUI web framework (like bootstrap but not only, it can be bootstrap based tool for dashboard, etc.) and a
>> documentation on how to use it.
>
> I don't know if nobody is using it (I guess some are ;)), but I believe a lot are reusing parts of it. The idea is not only to provide a demo but
> also to provide ideas, bricks to be reused. Did you wrote your own totally from scratch :-o (I guess not even considering ideas) ?

I meant "I MEAN not even considering ideas"

>
> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and JavaScript framework"  and use its artefacts inside widgets?
> What are actually the parts you found so bad? How the widgets are generated, the CSS class used, how js is used inside of that, etc. ?
>
> If we go this way (embed a HTML framework in OFBiz) I remember some proposed to use rather foundation, we would need to pick one and only one. Like
> wed did with jQuery as the main js lib that BTW we need to keep!
>
> Also some have proposed to get further and use something like Angular https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287 or
> Backbone https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989 you name it...
>
> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering see
> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>
> We need to make delicate choices and quickly, time is flying...
>
> Jacques
>

[Adrian Crum-3]

Here is a summary of the current Visual Theme implementation (so we are
all on the same page):

I introduced a feature in the bootstrap branch (then ported to trunk)
that allows a visual theme to specify its own templates for rendering.
This allows a theme to generate any HTML flavor it requires.

In the trunk I introduced a visitor pattern to the screen widgets -
which opens things up even more. (In my local copy, I have a rendering
engine based on visitors that is incomplete - I hope to commit it someday.)

There is a flaw in the current implementation that needs to be fixed:
the hard-coded JS libraries and other files in the Global Decorator.
That block of code should be converted to visual theme resources - so no
specific libraries are referenced in the Global Decorator.

The visual theme feature allows a graphics designer to specify JS
libraries, CSS libraries, and rendering templates - in effect decoupling
visual themes from the framework's rendering engine. As far as I can
tell, there is nothing preventing a graphics designer from creating any
UI they want using any tool they want.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 5/13/2015 7:35 AM, Jacques Le Roux wrote:

> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>> Hello Pierre,
>>
>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>> enhance the user experience. Unfortunately the work is not done yet.
>> The problem is that the GUI is a demo GUI. Then all the time you spend
>> to solve all GUI problems, will potentially lost because nobody use it
>> (and when I say that I think in particular to the order screen that is
>> a nightmare...).
>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>> documentation on how to use it.
>
> I don't know if nobody is using it (I guess some are ;)), but I believe
> a lot are reusing parts of it. The idea is not only to provide a demo
> but also to provide ideas, bricks to be reused. Did you wrote your own
> totally from scratch :-o (I guess not even considering ideas) ?
>
> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and
> JavaScript framework"  and use its artefacts inside widgets?
> What are actually the parts you found so bad? How the widgets are
> generated, the CSS class used, how js is used inside of that, etc. ?
>
> If we go this way (embed a HTML framework in OFBiz) I remember some
> proposed to use rather foundation, we would need to pick one and only
> one. Like wed did with jQuery as the main js lib that BTW we need to keep!
>
> Also some have proposed to get further and use something like Angular
> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
> or Backbone
> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
> you name it...
>
> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
> see
> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>
>
> We need to make delicate choices and quickly, time is flying...
>
> Jacques

[Pierre Smits]

Thanks Adrian for bringing the progress back to our attention. It is
appreciated.

Best regards,

Pierre Smits

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

On Wed, May 13, 2015 at 5:02 PM, Adrian Crum <
[hidden email]> wrote:

> Here is a summary of the current Visual Theme implementation (so we are
> all on the same page):
>
> I introduced a feature in the bootstrap branch (then ported to trunk) that
> allows a visual theme to specify its own templates for rendering. This
> allows a theme to generate any HTML flavor it requires.
>
> In the trunk I introduced a visitor pattern to the screen widgets - which
> opens things up even more. (In my local copy, I have a rendering engine
> based on visitors that is incomplete - I hope to commit it someday.)
>
> There is a flaw in the current implementation that needs to be fixed: the
> hard-coded JS libraries and other files in the Global Decorator. That block
> of code should be converted to visual theme resources - so no specific
> libraries are referenced in the Global Decorator.
>
> The visual theme feature allows a graphics designer to specify JS
> libraries, CSS libraries, and rendering templates - in effect decoupling
> visual themes from the framework's rendering engine. As far as I can tell,
> there is nothing preventing a graphics designer from creating any UI they
> want using any tool they want.
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 5/13/2015 7:35 AM, Jacques Le Roux wrote:
>
>> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>
>>> Hello Pierre,
>>>
>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>
>>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>>> enhance the user experience. Unfortunately the work is not done yet.
>>>>
>>> The problem is that the GUI is a demo GUI. Then all the time you spend
>>> to solve all GUI problems, will potentially lost because nobody use it
>>> (and when I say that I think in particular to the order screen that is
>>> a nightmare...).
>>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>>> documentation on how to use it.
>>>
>>
>> I don't know if nobody is using it (I guess some are ;)), but I believe
>> a lot are reusing parts of it. The idea is not only to provide a demo
>> but also to provide ideas, bricks to be reused. Did you wrote your own
>> totally from scratch :-o (I guess not even considering ideas) ?
>>
>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and
>> JavaScript framework"  and use its artefacts inside widgets?
>> What are actually the parts you found so bad? How the widgets are
>> generated, the CSS class used, how js is used inside of that, etc. ?
>>
>> If we go this way (embed a HTML framework in OFBiz) I remember some
>> proposed to use rather foundation, we would need to pick one and only
>> one. Like wed did with jQuery as the main js lib that BTW we need to keep!
>>
>> Also some have proposed to get further and use something like Angular
>> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
>> or Backbone
>> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
>> you name it...
>>
>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
>> see
>>
>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>>
>>
>> We need to make delicate choices and quickly, time is flying...
>>
>> Jacques
>>
>

[JulienNicolas]

Le 13/05/2015 16:35, Jacques Le Roux a écrit :

> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>> Hello Pierre,
>>
>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>> enhance the user experience. Unfortunately the work is not done yet.
>> The problem is that the GUI is a demo GUI. Then all the time you
>> spend to solve all GUI problems, will potentially lost because nobody
>> use it (and when I say that I think in particular to the order screen
>> that is a nightmare...).
>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>> documentation on how to use it.
>
> I don't know if nobody is using it (I guess some are ;)), but I
> believe a lot are reusing parts of it. The idea is not only to provide
> a demo but also to provide ideas, bricks to be reused. Did you wrote
> your own totally from scratch :-o (I guess not even considering ideas) ?
>
> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS,
> and JavaScript framework"  and use its artefacts inside widgets?
> What are actually the parts you found so bad?

I mean if you need to adapt the actual visual theme to bootstrap, it may
take a lot of time but the gain is very low.
It will be more interesting to add tool (like bootstrap or some js tool
or widget) and use it for the future demo screen. To have a good screen
render by using a new HTML/CSS/JS framework (like bootstrap), you must
to define your global solution rendering and create GUI specifications
that contain all visual cases.
If we speak about create a bootstrap theme not for demo but for a good
user experience, we'll have to create the GUI specifications first. Then
we need a GUI developer group that define the guidance and validate new
screen. In my opinion, changing colour of the actual demo GUI is a waste
of time. But use new feature for new demo screen, that change the demo
version into a patchwork but it's not a problem :)

> How the widgets are generated, the CSS class used, how js is used
> inside of that, etc. ?
>
> If we go this way (embed a HTML framework in OFBiz) I remember some
> proposed to use rather foundation, we would need to pick one and only
> one. Like wed did with jQuery as the main js lib that BTW we need to
> keep!
I agree. We have to make the choice of a framework and use it. But we
can keep in mind that maybe somebody want use another one so we can have
detail documentation to explain how to change it.
Another point, prefer to use heritage for the default css class.
And with the next add-on management, it may be possible to have a
specific add-on by css framework ;)

>
> Also some have proposed to get further and use something like Angular
> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287 
> or Backbone
> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989 
> you name it...
>
> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
> see
> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2

PhoneGap is a very interesting project but I'm not sure that a phone app
is a priority but it's only my opinion :D
>
> We need to make delicate choices and quickly, time is flying...
So true...

Julien.
>
> Jacques

[Hans Bakker]

Pierre,

There are several solutions not modifying the core system when modifying
a service:
1. we create a new service calling the standard service and do the
modifications before or after it.
2. if there are many changes, copy the whole service to the new
component rename it and modify it.
3. if it is a useful change contribute it to the core system.

Regards,
Hans


On 13/05/15 15:12, pierre wrote:

> Hi Hans,
>
> At Néréide we use the same way as you explain except that some time we
> have to do modifications in OFBiz core to slightly change one service
> because there is an error or the process is not exactly what we need.
> In this case we have to isolate these modifications so that they can
> be applied when OFBiz core is upgraded. This is done thru addon.
>
> How do you manage modifications in OFBiz core?
>
> Pierre
>
> On 13/05/2015 09:48, Hans Bakker wrote:
>> Julien, It can be that i do not understand your point.
>>
>> When we implement OFBiz for a customer we create a new component in
>> hot-deploy and we re-use as much from the OFBiz system as we can. We
>> also create new components like GrowERP which is just a component in
>> Hot-deploy. When we do that we almost not change the core ofbiz
>> system so we can easily upgrade.
>>
>> So i think that add-ons can be easily created just by adding new
>> components in hot-deploy, or do i miss something?
>>
>> Regards,
>> Hans
>>
>>
>> On 13/05/15 13:56, Julien NICOLAS wrote:
>>> Hi all,
>>>
>>> I was hopping more people will explain on this subject. It's exactly
>>> what I was thinking, that the functional part is less than the last
>>> priority of the project.
>>> I don't know exactly how I can do it but I really want to start
>>> something that will use OFBiz as a framework. If it can be done with
>>> the OFBiz community, it will be really good.
>>>
>>> Efforts exist but need people of the strong OFBiz community to be
>>> really better (GrowERP, BigFish, TERCompta, etc.).
>>>
>>> It's a pity that every new company that want to work with OFBiz must
>>> work on it's own version to be able to integrate it. I don't think
>>> it's a good thing for the project growing.
>>> And OFBiz community don't allow company to find easily other effort
>>> to enhance the software. And finally it seems that there is less
>>> than 5 peoples interested to work on this way.
>>>
>>> Maybe I'm wrong, functional is not as important as I thought...
>>>
>>> Sorry for the noise,
>>>
>>> Julien.
>>>
>>>
>>> Le 07/05/2015 16:00, Ron Wheeler a écrit :
>>>> I agree with Julien's analysis.
>>>> If I say "sub-projects" again, Jacques will whack me upside the
>>>> head but I really think that a restructuring of the way the
>>>> architecture is presented and developed would provide a number of
>>>> benefits:
>>>> - increase community involvement with less work for the current key
>>>> committers
>>>> - reduce or eliminate sub-optimal inter-component dependencies
>>>> through clearer definitions and independent releases of components
>>>> - reduce mixing of core seed data with demo and customizable seed
>>>> data and inter-component data confusion.
>>>> - facilitate the construction of components and add-ons that do not
>>>> have undesirable or unknown side-affects
>>>> - facilitate the injection of a smart installer that would allow
>>>> the selection of  components and templates as suggested at install
>>>> time.
>>>> - facilitate the development of an OFBiz marketplace for add-ons
>>>> and industry-specific configurations.
>>>> - make the role of the framework as a base for other products much
>>>> clearer.
>>>> - possibly make it easier to "Moquify" the framework if the
>>>> framework API can be made less implementation dependent - lots of
>>>> issues here that already have been fully ventilated last week.
>>>>
>>>> Ron
>>>>
>>>> On 07/05/2015 7:28 AM, Michael Brohl wrote:
>>>>> Hi Julien,
>>>>>
>>>>> thank you for bringing this up!
>>>>>
>>>>> I don't think that this is of no interest in the community, it's
>>>>> just overlaid by the many other topics we are discussing
>>>>> currently. I personally think that all topics are worth to be
>>>>> discussed and elaborated, maybe they have to be prioritised a
>>>>> little bit more. Right now it's a little bit confusing and not
>>>>> easy to follow (and contribute to) the discussions besides daily
>>>>> business.
>>>>>
>>>>> I think it is an important topic to simplify the backend
>>>>> component's UI and have more sophisticated usability there. On the
>>>>> other hand, it is important to somehow show customers the powers
>>>>> of OFBiz and the many already set-up functionalities. It would be
>>>>> a big step forward if we find a way to make this customizeable.
>>>>> For an ERP, it would also be a big plus to have some kind of
>>>>> "business templates" (!= UI templates) on top of such a mechanism,
>>>>> like
>>>>>
>>>>> - Your customer sells products over the internet? - pull the
>>>>> ecommerce template
>>>>> - Your customer brews beer? - pull the manufacturing +x template
>>>>> - Your customer has a small business? - pull the corresponding
>>>>> template
>>>>> etc.
>>>>>
>>>>> I belive that would require different configuration mechanisms,
>>>>> more on a database level with a clever UI instead of many
>>>>> different property files. And maybe a tool to chain services
>>>>> together on base of  such a template.
>>>>>
>>>>> I won't reduce the functionality in OFBiz per se, as long as they
>>>>> are stable and/or have a maintainer.
>>>>>
>>>>> I know of at least one contributor who is also working on a more
>>>>> sophisticated UI, maybe he shows up here also ;-)
>>>>>
>>>>> So, without having a concrete plan or more thought-out ideas how
>>>>> to implement this, I would support such an effort.
>>>>>
>>>>> As a community, I think we have to find a way to channel the
>>>>> different interests from core technology work up to the business
>>>>> layer. Some kind of overall project management would help but
>>>>> would be difficult to install in an open community. Too many open
>>>>> building sites in parallel are not that efficient.
>>>>>
>>>>> Curious what others think...
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brohl
>>>>> ecomify GmbH
>>>>> www.ecomify.de
>>>>>
>>>>>
>>>>> Am 07.05.15 um 12:48 schrieb Julien NICOLAS:
>>>>>> Hello All,
>>>>>>
>>>>>> Since I work on the bootstrap theme in OFBiz, I have many
>>>>>> thoughtful, carefully read the ofbiz community exchanges and
>>>>>> spoke with some members of the OFBiz community.
>>>>>> Today I am convinced that the OFBiz project is a framework that
>>>>>> is not intended to be an ERP. Its OOTB user interface is a
>>>>>> nightmare and is not really user oriented.
>>>>>> Several topics that seem to have no link together, seems to be
>>>>>> linked around the same idea.
>>>>>>
>>>>>> The first topic is about functionality of OFBiz.
>>>>>> On one hand, there is the OFBiz framework. It contains a user
>>>>>> interface to show the possibility of OFBiz, but must be changed
>>>>>> during integration. It also includes functional oriented
>>>>>> features. These features split the community between those who
>>>>>> want to keep them in the project and those who wish to exclude them.
>>>>>> On the other hand, there are new initiatives,abandoned projects,
>>>>>> old or having no longer contributors (project manager, POS, etc.)
>>>>>> who need support, visibility, even if they are not added to the
>>>>>> OFBiz project.
>>>>>> A first approach was discussed with GIT. It can allow everyone to
>>>>>> share their work more easily with branch feature. Which is good
>>>>>> but not the best in my opinion.
>>>>>>
>>>>>> Another topic that is important to me is the functional part of
>>>>>> OFBiz.
>>>>>> Sharan explained me about its willingness to invest energy to
>>>>>> make the software more functional, and if it's possible to have a
>>>>>> version with ERP oriented for small businesses with minimal
>>>>>> features but easy to use. Like growERP or TerCompta offer. Using
>>>>>> OFBiz framework but simplify the UI to allow the software to be
>>>>>> used intuitively without modifications.
>>>>>>
>>>>>> These initiatives come up against the model of OFBiz project. Who
>>>>>> has still not decided whether it is an ERP, in which case it
>>>>>> needs to adjust its UI or an automation of enterprise processes
>>>>>> framework, which involves getting rid of unnecessary features
>>>>>> dedicated to ERP.
>>>>>>
>>>>>> There are several solutions that could help to make better the
>>>>>> model of OFBiz and satisfy the entire community.
>>>>>> The first solution would be to limit the “OFBiz framewok” project
>>>>>> framework for automation enterprise processes and to have another
>>>>>> “OFBiz ERP” project which would use the framework as a basis, and
>>>>>> which would provide a user-friendly UI and dedicated tools to ERP.
>>>>>>
>>>>>> The second option is to find a way to cut the project in
>>>>>> extensions. This solution would have the opportunity to clean the
>>>>>> framework and have features as micro projects and therefore no
>>>>>> longer a monolithic software.
>>>>>>
>>>>>> I see a lot of debate about adding new functionality that allow
>>>>>> to improve development, compile, manage sources, merge with
>>>>>> another framework, but the debate on the division of project
>>>>>> extensions seems not to interest. It seems to me extremely
>>>>>> important to facilitate development and therefore, ultimately,
>>>>>> the visibility of the project in the developers community.
>>>>>>
>>>>>> At Nomaka, we initiated an effort starting from the first
>>>>>> solution. We took OFBiz framework, deleted all the themes and
>>>>>> created a new one. Then we redesigned the interface to match a
>>>>>> basic ERP.
>>>>>> We started with actor UI. Disabled existing screens and created
>>>>>> new ones more functional and user-friendly.
>>>>>>
>>>>>> I find it a pity to work alone in my corner without being able to
>>>>>> easily share my work, without taking advantage of the OFBiz
>>>>>> community knowledge to guide me onthe right way.
>>>>>> I wonder if we could work on this axis and balance the rigidity
>>>>>> necessary to have a stable project and flexibility that allow to
>>>>>> include non-committer contributions ...
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> Julien.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
> --
> logoNrd <http://nereide.fr/>
> Pierre GAUDIN
> Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre
> [hidden email]
> 3bis rue des Isles 37270 VERETZ
> Std: 02 47 50 30 54 - mob: [phone]
>
> ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE
> <http://www.libre-entreprise.org/>
>

[Hans Bakker]

I do not really see the advantage of this, can you please elaborate on this?

Regards,
Hans

On 13/05/15 17:21, Jacopo Cappellato wrote:
> On May 13, 2015, at 12:16 PM, Sharan Foga <[hidden email]> wrote:
>
>> We do have another Community Day coming up again next month (21st June) so it could be used as a co-ordinated effort to try and achieve this move of application components into one place. (Feedback from the last community day survey said that people wanted a much more co-ordinated effort). It seems like it could be a good thing to do especially if it is fairly easy to implement and would provide a lot of benefit.
>>
>> What do people think?
> This is a wonderful idea.
>
> Jacopo

[Hans Bakker]

Looks like i missing something here again... :-)

if you do not like a theme and you do not want to contribute,

copy the theme, rename and modify it.....

Regards,
Hans

On 13/05/15 20:04, Julien NICOLAS wrote:

> Hello Pierre,
>
> Le 13/05/2015 12:35, Pierre Smits a écrit :
>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>> enhance the user experience. Unfortunately the work is not done yet.
> The problem is that the GUI is a demo GUI. Then all the time you spend
> to solve all GUI problems, will potentially lost because nobody use it
> (and when I say that I think in particular to the order screen that is
> a nightmare...).
> It's better that OFBiz embedded GUI web framework (like bootstrap but
> not only, it can be bootstrap based tool for dashboard, etc.) and a
> documentation on how to use it.
>
>>   The
>> same goes for enhancing the various xsd files (and associated java
>> functions and ftl scripts) to bring OFBiz widgets up to par with HTML5,
>> CSS3 etc.
>>
>> OFBiz contains a ton of business functionalities. Gems hidden in
>> components. The are, however, not that visible to the - potential -
>> users
>> due to a number of factors:
>>
>>     - no descriptive placeholders in the wiki
>>     - no howto guides
>>     - overwhelmed by the sheer multitude of clickables when accessing a
>>     component as the admin user
>>     - etc
>>
>>
>> Creating the visibility will be the fuel for more adopters and
>> contributors. I have started on that path with
>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features
> Yes, it's very important as well. Documentation, visibility,
> marketing. It's just a matter of priority. Very important VS very very
> important...
>
> Julien.
>>
>> Having contributors being able to enhance documentation is not enough.
>> Funnelling patches on JIRA issues through the few with privileges and
>> having an interest in helping the non-privileged to enhance business
>> functionality (even if it is only a small bug fix or improvement) is
>> detriment to growth. Because when patches aren't reviewed and committed
>> (when good) in a reasonable time frame, the patches might get stale.
>>
>> We have lots of people committed to OFBiz. When do we start recognising
>> that, and enable those contributors to do more?
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>>
>

[Jacques Le Roux]

Actually maybe I'm misunderstanding you and I also want to clarify with everybody. I will try to be brief and right to the point!

Do you (we) want to replace the widgets by something like Ean and Anil proposed many times, or do we want to improve them using these new tools?

Jacques

Le 13/05/2015 22:15, Julien NICOLAS a écrit :

>
> Le 13/05/2015 16:35, Jacques Le Roux a écrit :
>> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>> Hello Pierre,
>>>
>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>>> enhance the user experience. Unfortunately the work is not done yet.
>>> The problem is that the GUI is a demo GUI. Then all the time you spend to solve all GUI problems, will potentially lost because nobody use it (and
>>> when I say that I think in particular to the order screen that is a nightmare...).
>>> It's better that OFBiz embedded GUI web framework (like bootstrap but not only, it can be bootstrap based tool for dashboard, etc.) and a
>>> documentation on how to use it.
>>
>> I don't know if nobody is using it (I guess some are ;)), but I believe a lot are reusing parts of it. The idea is not only to provide a demo but
>> also to provide ideas, bricks to be reused. Did you wrote your own totally from scratch :-o (I guess not even considering ideas) ?
>>
>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and JavaScript framework"  and use its artefacts inside widgets?
>> What are actually the parts you found so bad?
> I mean if you need to adapt the actual visual theme to bootstrap, it may take a lot of time but the gain is very low.
> It will be more interesting to add tool (like bootstrap or some js tool or widget) and use it for the future demo screen. To have a good screen
> render by using a new HTML/CSS/JS framework (like bootstrap), you must to define your global solution rendering and create GUI specifications that
> contain all visual cases.
> If we speak about create a bootstrap theme not for demo but for a good user experience, we'll have to create the GUI specifications first. Then we
> need a GUI developer group that define the guidance and validate new screen. In my opinion, changing colour of the actual demo GUI is a waste of
> time. But use new feature for new demo screen, that change the demo version into a patchwork but it's not a problem :)
>
>> How the widgets are generated, the CSS class used, how js is used inside of that, etc. ?
>>
>> If we go this way (embed a HTML framework in OFBiz) I remember some proposed to use rather foundation, we would need to pick one and only one. Like
>> wed did with jQuery as the main js lib that BTW we need to keep!
> I agree. We have to make the choice of a framework and use it. But we can keep in mind that maybe somebody want use another one so we can have
> detail documentation to explain how to change it.
> Another point, prefer to use heritage for the default css class.
> And with the next add-on management, it may be possible to have a specific add-on by css framework ;)
>>
>> Also some have proposed to get further and use something like Angular https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287 or
>> Backbone https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989 you name it...
>>
>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering see
>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
> PhoneGap is a very interesting project but I'm not sure that a phone app is a priority but it's only my opinion :D
>>
>> We need to make delicate choices and quickly, time is flying...
> So true...
>
> Julien.
>>
>> Jacques
>
>
>

[Jacques Le Roux]

Yes, thanks Adrian for clarification, much appreciated!

Jacques

Le 13/05/2015 17:07, Pierre Smits a écrit :

> Thanks Adrian for bringing the progress back to our attention. It is
> appreciated.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, May 13, 2015 at 5:02 PM, Adrian Crum <
> [hidden email]> wrote:
>
>> Here is a summary of the current Visual Theme implementation (so we are
>> all on the same page):
>>
>> I introduced a feature in the bootstrap branch (then ported to trunk) that
>> allows a visual theme to specify its own templates for rendering. This
>> allows a theme to generate any HTML flavor it requires.
>>
>> In the trunk I introduced a visitor pattern to the screen widgets - which
>> opens things up even more. (In my local copy, I have a rendering engine
>> based on visitors that is incomplete - I hope to commit it someday.)
>>
>> There is a flaw in the current implementation that needs to be fixed: the
>> hard-coded JS libraries and other files in the Global Decorator. That block
>> of code should be converted to visual theme resources - so no specific
>> libraries are referenced in the Global Decorator.
>>
>> The visual theme feature allows a graphics designer to specify JS
>> libraries, CSS libraries, and rendering templates - in effect decoupling
>> visual themes from the framework's rendering engine. As far as I can tell,
>> there is nothing preventing a graphics designer from creating any UI they
>> want using any tool they want.
>>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 5/13/2015 7:35 AM, Jacques Le Roux wrote:
>>
>>> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>>
>>>> Hello Pierre,
>>>>
>>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>>
>>>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>>>> enhance the user experience. Unfortunately the work is not done yet.
>>>>>
>>>> The problem is that the GUI is a demo GUI. Then all the time you spend
>>>> to solve all GUI problems, will potentially lost because nobody use it
>>>> (and when I say that I think in particular to the order screen that is
>>>> a nightmare...).
>>>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>>>> documentation on how to use it.
>>>>
>>> I don't know if nobody is using it (I guess some are ;)), but I believe
>>> a lot are reusing parts of it. The idea is not only to provide a demo
>>> but also to provide ideas, bricks to be reused. Did you wrote your own
>>> totally from scratch :-o (I guess not even considering ideas) ?
>>>
>>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and
>>> JavaScript framework"  and use its artefacts inside widgets?
>>> What are actually the parts you found so bad? How the widgets are
>>> generated, the CSS class used, how js is used inside of that, etc. ?
>>>
>>> If we go this way (embed a HTML framework in OFBiz) I remember some
>>> proposed to use rather foundation, we would need to pick one and only
>>> one. Like wed did with jQuery as the main js lib that BTW we need to keep!
>>>
>>> Also some have proposed to get further and use something like Angular
>>> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
>>> or Backbone
>>> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
>>> you name it...
>>>
>>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
>>> see
>>>
>>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>>>
>>>
>>> We need to make delicate choices and quickly, time is flying...
>>>
>>> Jacques
>>>

[Pierre Smits]

But what are the proposals? Where can these be found?

Best regards,

Pierre Smits

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

On Thu, May 14, 2015 at 9:14 AM, Jacques Le Roux <
[hidden email]> wrote:

> Actually maybe I'm misunderstanding you and I also want to clarify with
> everybody. I will try to be brief and right to the point!
>
> Do you (we) want to replace the widgets by something like Ean and Anil
> proposed many times, or do we want to improve them using these new tools?
>
> Jacques
>
> Le 13/05/2015 22:15, Julien NICOLAS a écrit :
>
>>
>> Le 13/05/2015 16:35, Jacques Le Roux a écrit :
>>
>>> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>>
>>>> Hello Pierre,
>>>>
>>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>>
>>>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>>>> enhance the user experience. Unfortunately the work is not done yet.
>>>>>
>>>> The problem is that the GUI is a demo GUI. Then all the time you spend
>>>> to solve all GUI problems, will potentially lost because nobody use it (and
>>>> when I say that I think in particular to the order screen that is a
>>>> nightmare...).
>>>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>>>> documentation on how to use it.
>>>>
>>>
>>> I don't know if nobody is using it (I guess some are ;)), but I believe
>>> a lot are reusing parts of it. The idea is not only to provide a demo but
>>> also to provide ideas, bricks to be reused. Did you wrote your own totally
>>> from scratch :-o (I guess not even considering ideas) ?
>>>
>>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and
>>> JavaScript framework"  and use its artefacts inside widgets?
>>> What are actually the parts you found so bad?
>>>
>> I mean if you need to adapt the actual visual theme to bootstrap, it may
>> take a lot of time but the gain is very low.
>> It will be more interesting to add tool (like bootstrap or some js tool
>> or widget) and use it for the future demo screen. To have a good screen
>> render by using a new HTML/CSS/JS framework (like bootstrap), you must to
>> define your global solution rendering and create GUI specifications that
>> contain all visual cases.
>> If we speak about create a bootstrap theme not for demo but for a good
>> user experience, we'll have to create the GUI specifications first. Then we
>> need a GUI developer group that define the guidance and validate new
>> screen. In my opinion, changing colour of the actual demo GUI is a waste of
>> time. But use new feature for new demo screen, that change the demo version
>> into a patchwork but it's not a problem :)
>>
>>  How the widgets are generated, the CSS class used, how js is used inside
>>> of that, etc. ?
>>>
>>> If we go this way (embed a HTML framework in OFBiz) I remember some
>>> proposed to use rather foundation, we would need to pick one and only one.
>>> Like wed did with jQuery as the main js lib that BTW we need to keep!
>>>
>> I agree. We have to make the choice of a framework and use it. But we can
>> keep in mind that maybe somebody want use another one so we can have detail
>> documentation to explain how to change it.
>> Another point, prefer to use heritage for the default css class.
>> And with the next add-on management, it may be possible to have a
>> specific add-on by css framework ;)
>>
>>>
>>> Also some have proposed to get further and use something like Angular
>>> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
>>> or Backbone
>>> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
>>> you name it...
>>>
>>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
>>> see
>>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>>>
>> PhoneGap is a very interesting project but I'm not sure that a phone app
>> is a priority but it's only my opinion :D
>>
>>>
>>> We need to make delicate choices and quickly, time is flying...
>>>
>> So true...
>>
>> Julien.
>>
>>>
>>> Jacques
>>>
>>
>>
>>
>>

[Jacques Le Roux]

Below are some, but this question is more to shake things a bit and know what people think

I think everybody will agree that the Entity Engine is the gem of this project, follows the Service Engine. I believe, though less polished, the
widgets are 3rnd, but that's only my opinion and I'd really like to know others

Jacques


Le 14/05/2015 10:45, Pierre Smits a écrit :

> But what are the proposals? Where can these be found?
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Thu, May 14, 2015 at 9:14 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Actually maybe I'm misunderstanding you and I also want to clarify with
>> everybody. I will try to be brief and right to the point!
>>
>> Do you (we) want to replace the widgets by something like Ean and Anil
>> proposed many times, or do we want to improve them using these new tools?
>>
>> Jacques
>>
>> Le 13/05/2015 22:15, Julien NICOLAS a écrit :
>>
>>> Le 13/05/2015 16:35, Jacques Le Roux a écrit :
>>>
>>>> Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>>>
>>>>> Hello Pierre,
>>>>>
>>>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>>>
>>>>>> For what it is worth, the BOOTSTRAP_theme dev branch is a other way to
>>>>>> enhance the user experience. Unfortunately the work is not done yet.
>>>>>>
>>>>> The problem is that the GUI is a demo GUI. Then all the time you spend
>>>>> to solve all GUI problems, will potentially lost because nobody use it (and
>>>>> when I say that I think in particular to the order screen that is a
>>>>> nightmare...).
>>>>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>>>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>>>>> documentation on how to use it.
>>>>>
>>>> I don't know if nobody is using it (I guess some are ;)), but I believe
>>>> a lot are reusing parts of it. The idea is not only to provide a demo but
>>>> also to provide ideas, bricks to be reused. Did you wrote your own totally
>>>> from scratch :-o (I guess not even considering ideas) ?
>>>>
>>>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS, and
>>>> JavaScript framework"  and use its artefacts inside widgets?
>>>> What are actually the parts you found so bad?
>>>>
>>> I mean if you need to adapt the actual visual theme to bootstrap, it may
>>> take a lot of time but the gain is very low.
>>> It will be more interesting to add tool (like bootstrap or some js tool
>>> or widget) and use it for the future demo screen. To have a good screen
>>> render by using a new HTML/CSS/JS framework (like bootstrap), you must to
>>> define your global solution rendering and create GUI specifications that
>>> contain all visual cases.
>>> If we speak about create a bootstrap theme not for demo but for a good
>>> user experience, we'll have to create the GUI specifications first. Then we
>>> need a GUI developer group that define the guidance and validate new
>>> screen. In my opinion, changing colour of the actual demo GUI is a waste of
>>> time. But use new feature for new demo screen, that change the demo version
>>> into a patchwork but it's not a problem :)
>>>
>>>   How the widgets are generated, the CSS class used, how js is used inside
>>>> of that, etc. ?
>>>>
>>>> If we go this way (embed a HTML framework in OFBiz) I remember some
>>>> proposed to use rather foundation, we would need to pick one and only one.
>>>> Like wed did with jQuery as the main js lib that BTW we need to keep!
>>>>
>>> I agree. We have to make the choice of a framework and use it. But we can
>>> keep in mind that maybe somebody want use another one so we can have detail
>>> documentation to explain how to change it.
>>> Another point, prefer to use heritage for the default css class.
>>> And with the next add-on management, it may be possible to have a
>>> specific add-on by css framework ;)
>>>
>>>> Also some have proposed to get further and use something like Angular
>>>> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
>>>> or Backbone
>>>> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
>>>> you name it...
>>>>
>>>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
>>>> see
>>>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>>>>
>>> PhoneGap is a very interesting project but I'm not sure that a phone app
>>> is a priority but it's only my opinion :D
>>>
>>>> We need to make delicate choices and quickly, time is flying...
>>>>
>>> So true...
>>>
>>> Julien.
>>>
>>>> Jacques
>>>>
>>>
>>>
>>>

[Gavin Mabie-2]

Hi Community

I have not been able to continue the work on the bootstrap theme for the
past few months now and therefore resisted the urge to comment on various
threads in the mailing list about matters related. So maybe apologies are
in order. Having said that, these are my thoughts:

1. The UI,  specifically HTML is as important as any other part of the
framework and should consequently be treated as such by the community.
2. Many projects with lesser architectural soundness but with sexy UIs'
have proven successful purely based on the UI. The Ofbiz architectural
framework rocks, but it not enough has been done to project this
graphically. The look and feel of the ecommerce app has not been upgraded
for more than half a decade now. This may be the reason why some are
looking towards integrating with other ecommerce projects.  The Ofbiz
ecommerce app isn't bad - the demo just looks bad.
3. Graphical designers can easily write their own UI, as alluded to by
Adrian. This regardless of the Javascript framework you would like to use.
You can write your own widget templates and incorporate that in your theme.
It's possible.
4. The elephant in the room is the significant amount of "raw" ftl widgets
present in the current demos.  This is where I got stuck with the bootstrap
development.  We cannot move the theme forward without dealing with "raw"
ftl.  I suspect that the same might be true for any other J'S framework.
Any volunteers?
5. Following on the previous point, developing a UI based on vogue JS
frameworks will be  extremely difficult if  we are concerned about breaking
older themes. Maybe it is time for a clean break.

So, this is my proposal:
1. Let's bodly adopt bootstrap. If there are any proponents of any other
framework, let them bring it forward so we can all discuss and work on it.
2. Put aside a sprint event to deal with "raw" ftls scattered all over and
get these converted into properly defined widgets.
3. Produce a more sexy ecommerce UI (this is critical to the Ofbiz brand).

There are other issues - but this I feel should be prioritised.

Regards
Gavin
On 14 May 2015 12:20 PM, "Jacques Le Roux" <[hidden email]>
wrote:

> Below are some, but this question is more to shake things a bit and know
> what people think
>
> I think everybody will agree that the Entity Engine is the gem of this
> project, follows the Service Engine. I believe, though less polished, the
> widgets are 3rnd, but that's only my opinion and I'd really like to know
> others
>
> Jacques
>
>
> Le 14/05/2015 10:45, Pierre Smits a écrit :
>
>> But what are the proposals? Where can these be found?
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Thu, May 14, 2015 at 9:14 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>  Actually maybe I'm misunderstanding you and I also want to clarify with
>>> everybody. I will try to be brief and right to the point!
>>>
>>> Do you (we) want to replace the widgets by something like Ean and Anil
>>> proposed many times, or do we want to improve them using these new tools?
>>>
>>> Jacques
>>>
>>> Le 13/05/2015 22:15, Julien NICOLAS a écrit :
>>>
>>>  Le 13/05/2015 16:35, Jacques Le Roux a écrit :
>>>>
>>>>  Le 13/05/2015 15:04, Julien NICOLAS a écrit :
>>>>>
>>>>>  Hello Pierre,
>>>>>>
>>>>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
>>>>>>
>>>>>>  For what it is worth, the BOOTSTRAP_theme dev branch is a other way
>>>>>>> to
>>>>>>> enhance the user experience. Unfortunately the work is not done yet.
>>>>>>>
>>>>>>>  The problem is that the GUI is a demo GUI. Then all the time you
>>>>>> spend
>>>>>> to solve all GUI problems, will potentially lost because nobody use
>>>>>> it (and
>>>>>> when I say that I think in particular to the order screen that is a
>>>>>> nightmare...).
>>>>>> It's better that OFBiz embedded GUI web framework (like bootstrap but
>>>>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
>>>>>> documentation on how to use it.
>>>>>>
>>>>>>  I don't know if nobody is using it (I guess some are ;)), but I
>>>>> believe
>>>>> a lot are reusing parts of it. The idea is not only to provide a demo
>>>>> but
>>>>> also to provide ideas, bricks to be reused. Did you wrote your own
>>>>> totally
>>>>> from scratch :-o (I guess not even considering ideas) ?
>>>>>
>>>>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS,
>>>>> and
>>>>> JavaScript framework"  and use its artefacts inside widgets?
>>>>> What are actually the parts you found so bad?
>>>>>
>>>>>  I mean if you need to adapt the actual visual theme to bootstrap, it
>>>> may
>>>> take a lot of time but the gain is very low.
>>>> It will be more interesting to add tool (like bootstrap or some js tool
>>>> or widget) and use it for the future demo screen. To have a good screen
>>>> render by using a new HTML/CSS/JS framework (like bootstrap), you must
>>>> to
>>>> define your global solution rendering and create GUI specifications that
>>>> contain all visual cases.
>>>> If we speak about create a bootstrap theme not for demo but for a good
>>>> user experience, we'll have to create the GUI specifications first.
>>>> Then we
>>>> need a GUI developer group that define the guidance and validate new
>>>> screen. In my opinion, changing colour of the actual demo GUI is a
>>>> waste of
>>>> time. But use new feature for new demo screen, that change the demo
>>>> version
>>>> into a patchwork but it's not a problem :)
>>>>
>>>>   How the widgets are generated, the CSS class used, how js is used
>>>> inside
>>>>
>>>>> of that, etc. ?
>>>>>
>>>>> If we go this way (embed a HTML framework in OFBiz) I remember some
>>>>> proposed to use rather foundation, we would need to pick one and only
>>>>> one.
>>>>> Like wed did with jQuery as the main js lib that BTW we need to keep!
>>>>>
>>>>>  I agree. We have to make the choice of a framework and use it. But we
>>>> can
>>>> keep in mind that maybe somebody want use another one so we can have
>>>> detail
>>>> documentation to explain how to change it.
>>>> Another point, prefer to use heritage for the default css class.
>>>> And with the next add-on management, it may be possible to have a
>>>> specific add-on by css framework ;)
>>>>
>>>>  Also some have proposed to get further and use something like Angular
>>>>>
>>>>> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
>>>>> or Backbone
>>>>>
>>>>> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
>>>>> you name it...
>>>>>
>>>>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth considering
>>>>> see
>>>>>
>>>>> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
>>>>>
>>>>>  PhoneGap is a very interesting project but I'm not sure that a phone
>>>> app
>>>> is a priority but it's only my opinion :D
>>>>
>>>>  We need to make delicate choices and quickly, time is flying...
>>>>>
>>>>>  So true...
>>>>
>>>> Julien.
>>>>
>>>>  Jacques
>>>>>
>>>>>
>>>>
>>>>
>>>>

[Pierre Smits]

Several issues have been registered recently to migrate specific ftl
functions to widgets. And patches have been attached. These just need a
review and get committed.

Yes, the use of ftl functionality is overwhelming. Even when it is not
needed at all. E.g. defining standard screenlet functionality.

And, for sure, it was the best (easiest?) choice for the contributor at the
moment of creation to get to the desired solution (think functionality
and/or time constraints).
Like widgets, the ftl functions serve a purpose. It is not either widgets
or ftl, but and widgets and ftl. But both techs should be applied wisely
and not mere for convenience sake.

When talking about moving from ftl to widgets (where possible), it all
starts with registering the improvement issue in JIRA.

Best regards,

Pierre Smits

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

On Thu, May 14, 2015 at 1:22 PM, Gavin Mabie <[hidden email]> wrote:

> Hi Community
>
> I have not been able to continue the work on the bootstrap theme for the
> past few months now and therefore resisted the urge to comment on various
> threads in the mailing list about matters related. So maybe apologies are
> in order. Having said that, these are my thoughts:
>
> 1. The UI,  specifically HTML is as important as any other part of the
> framework and should consequently be treated as such by the community.
> 2. Many projects with lesser architectural soundness but with sexy UIs'
> have proven successful purely based on the UI. The Ofbiz architectural
> framework rocks, but it not enough has been done to project this
> graphically. The look and feel of the ecommerce app has not been upgraded
> for more than half a decade now. This may be the reason why some are
> looking towards integrating with other ecommerce projects.  The Ofbiz
> ecommerce app isn't bad - the demo just looks bad.
> 3. Graphical designers can easily write their own UI, as alluded to by
> Adrian. This regardless of the Javascript framework you would like to use.
> You can write your own widget templates and incorporate that in your theme.
> It's possible.
> 4. The elephant in the room is the significant amount of "raw" ftl widgets
> present in the current demos.  This is where I got stuck with the bootstrap
> development.  We cannot move the theme forward without dealing with "raw"
> ftl.  I suspect that the same might be true for any other J'S framework.
> Any volunteers?
> 5. Following on the previous point, developing a UI based on vogue JS
> frameworks will be  extremely difficult if  we are concerned about breaking
> older themes. Maybe it is time for a clean break.
>
> So, this is my proposal:
> 1. Let's bodly adopt bootstrap. If there are any proponents of any other
> framework, let them bring it forward so we can all discuss and work on it.
> 2. Put aside a sprint event to deal with "raw" ftls scattered all over and
> get these converted into properly defined widgets.
> 3. Produce a more sexy ecommerce UI (this is critical to the Ofbiz brand).
>
> There are other issues - but this I feel should be prioritised.
>
> Regards
> Gavin
> On 14 May 2015 12:20 PM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
> > Below are some, but this question is more to shake things a bit and know
> > what people think
> >
> > I think everybody will agree that the Entity Engine is the gem of this
> > project, follows the Service Engine. I believe, though less polished, the
> > widgets are 3rnd, but that's only my opinion and I'd really like to know
> > others
> >
> > Jacques
> >
> >
> > Le 14/05/2015 10:45, Pierre Smits a écrit :
> >
> >> But what are the proposals? Where can these be found?
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *ORRTIZ.COM <http://www.orrtiz.com>*
> >> Services & Solutions for Cloud-
> >> Based Manufacturing, Professional
> >> Services and Retail & Trade
> >> http://www.orrtiz.com
> >>
> >> On Thu, May 14, 2015 at 9:14 AM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >>  Actually maybe I'm misunderstanding you and I also want to clarify with
> >>> everybody. I will try to be brief and right to the point!
> >>>
> >>> Do you (we) want to replace the widgets by something like Ean and Anil
> >>> proposed many times, or do we want to improve them using these new
> tools?
> >>>
> >>> Jacques
> >>>
> >>> Le 13/05/2015 22:15, Julien NICOLAS a écrit :
> >>>
> >>>  Le 13/05/2015 16:35, Jacques Le Roux a écrit :
> >>>>
> >>>>  Le 13/05/2015 15:04, Julien NICOLAS a écrit :
> >>>>>
> >>>>>  Hello Pierre,
> >>>>>>
> >>>>>> Le 13/05/2015 12:35, Pierre Smits a écrit :
> >>>>>>
> >>>>>>  For what it is worth, the BOOTSTRAP_theme dev branch is a other way
> >>>>>>> to
> >>>>>>> enhance the user experience. Unfortunately the work is not done
> yet.
> >>>>>>>
> >>>>>>>  The problem is that the GUI is a demo GUI. Then all the time you
> >>>>>> spend
> >>>>>> to solve all GUI problems, will potentially lost because nobody use
> >>>>>> it (and
> >>>>>> when I say that I think in particular to the order screen that is a
> >>>>>> nightmare...).
> >>>>>> It's better that OFBiz embedded GUI web framework (like bootstrap
> but
> >>>>>> not only, it can be bootstrap based tool for dashboard, etc.) and a
> >>>>>> documentation on how to use it.
> >>>>>>
> >>>>>>  I don't know if nobody is using it (I guess some are ;)), but I
> >>>>> believe
> >>>>> a lot are reusing parts of it. The idea is not only to provide a demo
> >>>>> but
> >>>>> also to provide ideas, bricks to be reused. Did you wrote your own
> >>>>> totally
> >>>>> from scratch :-o (I guess not even considering ideas) ?
> >>>>>
> >>>>> Is the BOOTSTRAP_theme dev branch not a way to embed one "HTML, CSS,
> >>>>> and
> >>>>> JavaScript framework"  and use its artefacts inside widgets?
> >>>>> What are actually the parts you found so bad?
> >>>>>
> >>>>>  I mean if you need to adapt the actual visual theme to bootstrap, it
> >>>> may
> >>>> take a lot of time but the gain is very low.
> >>>> It will be more interesting to add tool (like bootstrap or some js
> tool
> >>>> or widget) and use it for the future demo screen. To have a good
> screen
> >>>> render by using a new HTML/CSS/JS framework (like bootstrap), you must
> >>>> to
> >>>> define your global solution rendering and create GUI specifications
> that
> >>>> contain all visual cases.
> >>>> If we speak about create a bootstrap theme not for demo but for a good
> >>>> user experience, we'll have to create the GUI specifications first.
> >>>> Then we
> >>>> need a GUI developer group that define the guidance and validate new
> >>>> screen. In my opinion, changing colour of the actual demo GUI is a
> >>>> waste of
> >>>> time. But use new feature for new demo screen, that change the demo
> >>>> version
> >>>> into a patchwork but it's not a problem :)
> >>>>
> >>>>   How the widgets are generated, the CSS class used, how js is used
> >>>> inside
> >>>>
> >>>>> of that, etc. ?
> >>>>>
> >>>>> If we go this way (embed a HTML framework in OFBiz) I remember some
> >>>>> proposed to use rather foundation, we would need to pick one and only
> >>>>> one.
> >>>>> Like wed did with jQuery as the main js lib that BTW we need to keep!
> >>>>>
> >>>>>  I agree. We have to make the choice of a framework and use it. But
> we
> >>>> can
> >>>> keep in mind that maybe somebody want use another one so we can have
> >>>> detail
> >>>> documentation to explain how to change it.
> >>>> Another point, prefer to use heritage for the default css class.
> >>>> And with the next add-on management, it may be possible to have a
> >>>> specific add-on by css framework ;)
> >>>>
> >>>>  Also some have proposed to get further and use something like Angular
> >>>>>
> >>>>>
> https://issues.apache.org/jira/browse/OFBIZ-5040?focusedCommentId=13887287
> >>>>> or Backbone
> >>>>>
> >>>>>
> https://issues.apache.org/jira/browse/OFBIZ-5522?focusedCommentId=13885989
> >>>>> you name it...
> >>>>>
> >>>>> https://cordova.apache.org/ ("aka" PhoneGap) is also worth
> considering
> >>>>> see
> >>>>>
> >>>>>
> https://cwiki.apache.org/confluence/download/attachments/48792051/mobile_web.pdf?version=1&modificationDate=1429534402000&api=v2
> >>>>>
> >>>>>  PhoneGap is a very interesting project but I'm not sure that a phone
> >>>> app
> >>>> is a priority but it's only my opinion :D
> >>>>
> >>>>  We need to make delicate choices and quickly, time is flying...
> >>>>>
> >>>>>  So true...
> >>>>
> >>>> Julien.
> >>>>
> >>>>  Jacques
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
>