Thanks Taher,
Your explanations are sharper than mine, I was on the consistency
benefit, you explain about technical benefits.
Anyway, I'll provide also the explanation drawing and screenshot of the
UI consistency benefits. That is as important as the technical part :)
Have a nice day,
Julien.
On 07/12/2016 17:08, Taher Alkhateeb wrote:
I'm sure Julien has good ideas on how to move things about and I'll let gim
express those, I just want to add a conceptual frame for why probably both
Julien and myself sort of agree on the seperation of FTL templates from
screen widgets, so here goes ...
Aside from the great data model and service engine, OFBiz has something
which people like, which is the DSL. The DSL abstracts the database and
entities details. The DSL abstracts the services and their details. The DSL
also abstracts configuration. The same is exactly true for the user
interface.
Why do we have a DSL for entities? because we want a simple unified
language that talks to all the different databases. Why do we have DSL for
services? Because we want a unified way of accessing them regardless of the
implementation programming language.
By the same logic, you want a unified simple DSL for creating the user
interface without worrying about the details of the output format whether
be it HTML, PDF, Swing, Text or something else.
When you define an entity do you go and mix The Entity definition in XML
with SQL statements? When you create a service definition do you put the
implementation inside that definition? I think the answer to both questions
is no correct?
So by the same philosophy and spirit of using the DSL everywhere in a pure
form and putting the implementation details "somewhere else", the same
should hold with the user interface.
So what are the benefits of this separation?
- Naturally you provide a simple DSL for people to quickly create a nice
user interface without having to know about all the intricacies of web
programming.
- you separate the definition from the implementation which allows you to
output to multiple formats without touching the widgets.
- you achieve modularity and avoid code repetition. You write every macro
once and only once. Then you use it everywhere indirectly through the
widgets.
- you achieve separation of concerns. You keep all the Technologies related
to web like CSS HTML and JavaScript in a separate location, while keeping
other logic like processing the DSL and parsing it and building the model
from it in another place.
- Changes to web frameworks become much easier (HTML 5? Angular, etc ...).
You can change that stuff without touching any of your widgets.
So the issue remaining is whether you folks believe it is worth the effort
and hard work to get this done. We leave that for the community to decide.
I certainly agree with Michael though that we should do this work in a
careful manner to minimize the transition pain for adopters of earlier
versions.
Cheers,
Taher Alkhateeb
On Dec 7, 2016 6:30 PM, "Michael Brohl" <michael.br...@ecomify.de> wrote:
Hi Julien,
thanks for your explanations.
It is indeed difficult to explain and understand, I suggest to provide
some kind of diagram or maybe some very simple examples, if you can.
Please also have in mind that we need to have a migration plan from old to
new and we should be able to run old and new in parallel for a while, at
least during one full release. We have some responsibility towards existing
users.
Thanks for your appreciated efforts,
Michael
Am 07.12.16 um 16:16 schrieb Julien NICOLAS:
It's a proposal for best practices, because of my own experience on
making new theme and the impact for a consistency UI.
For example, party details screen is a patchwork of xml screens and ftl
screens. If you manage to change the HTML structure of a form, it'll affect
only xml screen thanks to macro ftl. The pure ftl screen keep the old html
structure and you have to adapt your theme rendering to the html structure
of the ftl. It's a pity that we have to manage UI screen by screen.
There is no guidelines on how to make a good screen, and you can find for
the same usage ftl screen and xml screen with different UI... So, we lost
consistency. If we engage a new start for UI using guidelines, allow to
make ftl screen with new UI by new developer could be dangerous for
maintenance.
What I mean is not to forbid ftl screen, but to forbid it for common
screens that can be managed by xml structured screen in OOTB. In that way,
we keep the UI consistency in the OOTB.
It's difficult to explain well my tough, I hope to not made a
misunderstanding :)
Julien.
On 07/12/2016 14:45, Pierre Smits wrote:
I am wondering how to understand this:
better to not use ftl elsewhere than in macro
Is not every ftl template providing macro functionalities? Do you desire
that this project moves away from using ftl templates in any other place
than in a theme?
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Dec 7, 2016 at 2:28 PM, Julien NICOLAS <
julien.nico...@nereide.fr>
wrote:
If I understand well, yes.
All html structure must be managed by the theme. In OOTB, it could be
really better to not use ftl elsewhere than in macro. This is a way that
could be good to follow to have consistency for all screens in OFBiz.
Julien.
On 06/12/2016 11:59, Pierre Smits wrote:
So you are considering the following:
‘A more flexible and extensible approach is to use the FTL XML
processing
features directly instead of going through Java classes. With this
approach
adding an attribute or support for a whole new element in the widget
XML
files is just a matter of adding it to the FTL macros that process XML
elements’
?
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS <
julien.nico...@nereide.fr
wrote:
Pierre,
I don't know if we'll need it or not for now. There is so many thing
to
define but it seems interesting. We will have to start this
discussion on
the new theme topic.
Julien.
On 02/12/2016 11:55, pierre wrote:
Hi Julien
Is there any interest into the integration of a java UI framework
such
as vaadin?
regards,
Pierre
On 01/12/2016 23:26, Julien NICOLAS wrote:
Hi all,
I start a page about the POC for the UI improvement.
I'm not sure if the content is enough but I was wanted to create it.
We can now start some... Jira ? I was wondering one main Jira linked
to 4 other sub-jira.
thanks to those Jira, we can have 4 teams or workgroup to go ahead
in
both ways.
https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement
Let me know if I'm doing well,
Kind regards,
Julien.
PS : I'm currently checkout the common-theme provided by Nicolas's
github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme)
On 28/11/2016 11:28, Sharan Foga wrote:
Hi Everyone
Another one of the topics that came up during the brainstorming in
Seville was around the UI. In fact we had at least 2 presentations
from the OFBiz track at Apachecon that were about how we could
improve our UI.
If the UI was the main focus - what could the strategy look like
- User Interface - have 2 versions of the UI, one very clean and
simple, the other more advanced. (Our current UI could be the
advanced one....?
- Separate the web part from the widgets
- We have too many fields on one screen (many of them are not
mandatory and are just included as optional). What if we slimmed
down
all the screens to have a sensible default UI for users. The UI
could
also be modifiable by service providers. Simplify the screens with
defaults
- Use Bootstrap / CSS / Angular
- Isolate web related
- Define a graphics charter to be used for the screens
- Have a CSS convention
- Remove web from the framework - it shouldn't be there
What do people think?
-Do people think it would be a good idea to have 2 versions of the
UI? (a simple one and a more advanced one?)
- Are these the things we would need to focus on or have in place
if
we wanted to focus on the UI?
(Also I know Nicolas has mentioned that he has already started work
on a Proof of Concept for a common theme - so do we need to make
sure we agree conventions etc before much more work is done?)
Thanks
Sharan
