Addons for OFBiz

[Jacques Le Roux]

Thanks both for clarifying, exactly my thoughts, happy we are on the same page :)

More (different) opinions?

Jacques

Le 14/05/2015 13:53, Pierre Smits a écrit :

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

[Christian Carlow-OFBizzer]

I agree with the "gem" ranking level at which widgets are placed and
find it a worthy effort to convert as much FTL to widgets as possible
because widgets extremely faster to interpret than FTL files.  However,
sometimes the framework has to be extended to support all of the FTL
features which adds some inconveniency (less polished).  Moqui supports
widgets similar to OFBiz also which suggests its value.

On Thu, 2015-05-14 at 12:20 +0200, Jacques Le Roux 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
> >>>>
> >>>
> >>>
> >>>

[Adrian Crum-3]

There has been interest lately in using a REST interface to the OFBiz
service engine - so the UI can be pure client-side JavaScript, and the
UI is updated dynamically using XML or JSON calls to the REST API. That
design would be a huge task, but it could create a truly impressive UI.
I will refer to that approach as "REST+JSON."

Replacing widgets with something else has been discussed for years, yet
they are still here. Many man-years have been invested in the screen
widgets, so there is a lot of inertia behind them. Replacing them will
be a huge task.

The complaints about screen widgets are usually:

1. They are OFBiz-specific and are poorly documented, so new developers
find them difficult to use.
2. I can't do xyz with a screen widget.

We can fix #1 easily by adding documentation to the widget schemas, and
by improving the Hot-Tos on the wiki.

We can fix #2 by adding support for xyz. This is one of the advantages
of screen widgets - since it is ours (and not an external library) we
can change it whenever and however we please.

The advantages of using screen widgets are:

1. Rapid application development. You can do a lot with a few lines of XML.
2. Screen widgets define a general layout, so they can be reused for
non-UI purposes - like reports and data export.

A recurring comment is "You can use widgets for back office
applications, but not for eCommerce sites." I don't agree with that. I
built a very slick and information-rich CRM application using widgets
only, and I believe anyone can build a competitive eCommerce site using
them. You just have to be willing to learn how to exploit their
capabilities (re: complaint #1).

In a REST+JSON design, we could port/adapt the advantages of screen
widgets - like building forms based on entity models or service models.
The challenge will be finding a way to reuse things for reports and data
export like we currently do with widgets. That effort would be similar
to the previous Groovy integration - where we took the cool advantages
of Mini-language and ported them to a Groovy DSL.

Personally, I don't have a preference. If someone comes up with an
alternate approach and implements it, then I will use it. Meanwhile, I
will continue to improve the screen widgets.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 5/14/2015 12:14 AM, Jacques Le Roux 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
>>
>>
>>

[Ean Schuessler]

> From: "Jacques Le Roux" <[hidden email]>
> Subject: Widget or not Widget? [Was Re: Addons for OFBiz]

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

I did not propose that we "replace the widgets". I proposed that we
re-implement the widget rendering in Javascript on the client. There is
a big difference.

[Jacques Le Roux]

Le 16/05/2015 04:09, Ean Schuessler a écrit :

>> From: "Jacques Le Roux" <[hidden email]>
>> Subject: Widget or not Widget? [Was Re: Addons for OFBiz]
>> 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?
> I did not propose that we "replace the widgets". I proposed that we
> re-implement the widget rendering in Javascript on the client. There is
> a big difference.
>

Thanks for clarifying Ean,

So it seems we are all (I guess Anil wants the same) on the same page and want to improve the widget rendering, not replace it.

Jacques

[taher]

Hi everyone,

There is, in my opinion, one main existing flaw in the widget system which is ease of customization / extension.

Adding a new HTML element or modifying the behavior of forms should not be as difficult as it is right now. I remember having to track the Java code on building the models from XML and altering the xsd files and whatnot. I like the idea of widgets being platform independent but realistic implementations seem to be hard, especially for form widgets.

So, to avoid replacing widgets with HTML code, I need an easy way to replace "<platform-specific><html>" and an easy way to add custom components to form widgets. Perhaps something like a <custom-widget> element that I can easily link to an FTL template without going through Java or XSD files.

my 2 cents.

Taher Alkhateeb

----- Original Message -----

From: "Jacques Le Roux" <[hidden email]>
To: [hidden email]
Sent: Saturday, 16 May, 2015 10:38:50 AM
Subject: Re: Widget or not Widget? [Was Re: Addons for OFBiz]

Le 16/05/2015 04:09, Ean Schuessler a écrit :

>> From: "Jacques Le Roux" <[hidden email]>
>> Subject: Widget or not Widget? [Was Re: Addons for OFBiz]
>> 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?
> I did not propose that we "replace the widgets". I proposed that we
> re-implement the widget rendering in Javascript on the client. There is
> a big difference.
>

Thanks for clarifying Ean,

So it seems we are all (I guess Anil wants the same) on the same page and want to improve the widget rendering, not replace it.

Jacques

[Jacopo Cappellato-5]

The widgets will always have some limitations; in fact they are intended to be a simplified "language" for defining screen elements with some common patterns; these "limitations" have been acceptable (and sometimes still are) in the context of ERP applications.
But there is one aspect I really don't like about them; our best practices are (and have been):
1) use the widgets for backend screens when possible
2) otherwise implement the screenlet with ftl template

The problem I see with the above approach is that widget definition language is completely different from Freemarker and the OFBiz developer has to master two languages when building user interfaces.

A similar issue (but I know it is off topic) is related to business logic; our best practices say:
1) implement Minilang code if possible
2) otherwise use Java

Again, Minilang and Java are completely different beasts and this require that the developer master a broader set of skills.
The issue with business logic can be now addressed with the adoption of the OFBiz DSL for Groovy: use the DSL when possible and mix it with Groovy code using the OFBiz api already used in Java services; the DSL and plan Groovy code cohexist nicely in the same script/file making the definition of business logic more consistent.

In my opinion our widget 2.0 should be something like this: a library of elements used in an ftl file where you could embed also plan Freemarker or html code.

Jacopo


What I don't like about the widgets is the fact that the "language" to define them is completely di


On May 16, 2015, at 10:21 AM, Taher Alkhateeb <[hidden email]> wrote:

> Hi everyone,
>
> There is, in my opinion, one main existing flaw in the widget system which is ease of customization / extension.
>
> Adding a new HTML element or modifying the behavior of forms should not be as difficult as it is right now. I remember having to track the Java code on building the models from XML and altering the xsd files and whatnot. I like the idea of widgets being platform independent but realistic implementations seem to be hard, especially for form widgets.
>
> So, to avoid replacing widgets with HTML code, I need an easy way to replace "<platform-specific><html>" and an easy way to add custom components to form widgets. Perhaps something like a <custom-widget> element that I can easily link to an FTL template without going through Java or XSD files.
>
> my 2 cents.
>
> Taher Alkhateeb
>
> ----- Original Message -----
>
> From: "Jacques Le Roux" <[hidden email]>
> To: [hidden email]
> Sent: Saturday, 16 May, 2015 10:38:50 AM
> Subject: Re: Widget or not Widget? [Was Re: Addons for OFBiz]
>
> Le 16/05/2015 04:09, Ean Schuessler a écrit :
>>> From: "Jacques Le Roux" <[hidden email]>
>>> Subject: Widget or not Widget? [Was Re: Addons for OFBiz]
>>> 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?
>> I did not propose that we "replace the widgets". I proposed that we
>> re-implement the widget rendering in Javascript on the client. There is
>> a big difference.
>>
> Thanks for clarifying Ean,
>
> So it seems we are all (I guess Anil wants the same) on the same page and want to improve the widget rendering, not replace it.
>
> Jacques
>
>