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
