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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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" <[email protected]> >>> 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 > >
