+1  It'd be way easier to create a template.

On 07/31/2017 01:25 PM, Jacques Le Roux wrote:
I totally agree Deepak!

Our problem is not that we are not using an UI framework or another.

Our problem is that we are not consistently generating HTML because we use too much Freemarker templates in the backend. IMO we should always (OK as much as possible, but trying really hard) generate HTML with form widgets.

Using Freemarker templates in frontend (eg ecommerce) is another case and we have different types of themes for this reason.

If we consistently generate HTML using form widgets (I don't say that that could not be improved too) then it's easier to use CSS on it and choose an UI framework to apply on it.

To summarise: consistent generated HTML is the key here

Jacques


Le 06/07/2017 à 07:49, Deepak Dixit a écrit :
IMO instead of thinking to support different UI framework we can define our
standard html and then write css based on it.

If anyone want to plug different UI framework then user can create new
template file and and set it in widget.properties.



Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Thu, Jul 6, 2017 at 1:48 AM, Michael Brohl<michael.br...@ecomify.de>
wrote:

I'm currently twisting my had around the question of theme compatibility.

The current theme set and the html code (freemarker templates and the code
produced by forms and widgets) correspond with each other (naturally).

So if we want to introduce a new CSS framework like Bootstrap, we will
have to follow it's CSS reference and introduce it's CSS classes to the
html and forms/widgets code. This will surely break the other themes.

So we have to (1) either find a way to remain compatible with the old
themes or (2) decide to break the old themes (and remove them).

(1) would mean that we (I cite myself)

will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents in an abstracted way (possibly an enhanced Freemarker macro library) and make it possible to generate HTML code with the right css attributes for the target
library.

(2) would mean that we will have only one first theme for a time (I'm sure
that others will follow more quickly because of using a standard CSS
framework)


If I look at the Odoo approach [1], it seems that they are not compatible
with different frameworks but have their base template build mainly on
Bootstrap and jQuery. I still think that maintaining an abstract layer for
different frameworks or "theme languages" is too much a burden for us.

But will the community agree upon (2)?

I might be wrong with my assumptions as I am not an expert (just
interested in a much better UI) so I appreciate the community's feedback on
this.

Thanks and best regards,

Michael


[1]https://www.odoo.com/documentation/10.0/howtos/themes.html


Am 04.07.17 um 20:53 schrieb Taher Alkhateeb:

I agree with Michael, baby steps for the win. I propose we perhaps

just postpone "big ideas" for now and focus on things that can get
results quickly to put life back into this initiative. Maybe next
actions could be the following:

- Create a base theme
- Move all artifacts from framework/images to the base theme (jquery,
bootstrap or whatever already exists) and do the rewiring. Also look
for any web artifacts anywhere and move them to the base theme.
Essentially, remove any thing that is web-based and centralize it in
the theme.
- Create an implementation theme on top of the base theme

Once the above is done, then we can have a discussion of what to do
next. There are _many_ ideas, but I will restrain myself this time
until we get some action first :)

On Tue, Jul 4, 2017 at 6:31 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com>  wrote:

Le 04/07/2017 à 16:57, Michael Brohl a écrit :

Hi James,

thanks for your suggestions.

As far as I know, JSF would introduce some new technologies because it relies on beans and JSP's (correct me if I'm wrong). I'm not sure if we
want
to go so far.

Facelet is now the recommended technology for JSF
https://stackoverflow.com/questions/2095397/what-is-the-diff
erence-between-jsf-servlet-and-jsp
and both are parts of JavaEE.

I agree with Michael and would not like to change OFBiz widgets for JSF.
Not
that I don't like nor trust JSF (and Oracle, but then a bit less), but
the
work is overwhelming and obviously we don't have the resources for that.

I digged a little deeper into the UI stuff, templates and theming and
have
to correct my summary a bit: I mentioned AngularJS and Bootstrap on the
same
level which is like comparing apples and oranges. AngularJS is a
client-side
JavaScript framework to build single page applications, icluding his own model-view-controller mechanism while Bootsrap is a CSS framework which
provides comprehensive UI elements in a structured way.

I guess that the use of Angular would need a whole lot more changes in
OFBiz than the use of Bootstrap.

So I tend to think that we have to agree on a CSS framework like
Bootstrap
and rewrite the UI to use the proper CSS classes for this framework.
That
would possibly reduce the complexity and makes this statement of mine
obsolete:

- we will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents
in an
abstracted way (possbly an enhanced Freemarker macro library) and make
it
possible to generate HTML code with the right css attributes for the
target
library.

It's maybe too ambitious wanting OFBiz to be able to be used with
different frameworks. The Bootstrap CSS world is well documented [1] and there are a lot of really good looking and functional free templates out
there. So if we provide the UI code for it, together with one basic
theme,
users can put their own themes on top of it.

Maybe this is a way to come to a competitive UI in a relative short
amount
of time. I don't think that we can afford to make this a year-long
project.

What do others think?

I agree that using Bootstrap would be a good thing. An alternative is
Foundationhttps://www.keycdn.com/blog/bootstrap-vs-foundation, this
could
be possibly discussed.
That's what ilscipio has used, with some success at the UI level I'd say
(they now tend to lean to Foundation). Now they derived from OFBiz at
other
technology levels (no or less form widgets but more FTL macros, even an
API
of FTL macros). So I'd try to compare the rest...

I'd also let Angular out of the picture. Some prefer React (initially
from
FB) and I wonder what those who have used Angular 1 think about Angular
2! I
also remember another Google "attempt": GWT. Are there still people
using it
with OFBiz? I guess you get my point, trends pass and tools with them...

Jacques


Best regards,
Michael Brohl
ecomify GmbH
www.ecomify.de

[1]https://www.w3schools.com/bootstrap/bootstrap_ref_all_classes.asp


Am 03.07.17 um 15:00 schrieb James Yong:

Hi Michael and all,

We can look into JSF 2.2 as a possible candidate. It is similar to
OFBiz
Widget and seems to fit the new requirements described so far in this
thread.

Regards,
James Yong

On 2017-07-03 17:42 (+0800), Michael Brohl<michael.br...@ecomify.de>
wrote:

Hi Sharan,

thanks for the reminder.

It's fine to have another theme to choose for the "old" UI, I just
want
to point out that (in my mind) the new theme/UI initiative goes far beyond having just another theme on base of the current technological
stack:

- new themes should be responsive

- we should be able to use different UI frameworks like Bootstrap and AngularJS who take care of responsiveness and browser compatibility

- it must be easy for developers to write the screen structure and
also
easy for webdesigners to build a good design on base of this

- developers should not care about CSS styles and classes, and
webdesigners should not cara about how the screen snippets are put
together or how the screens get their data.

- we will need a new approach to be able to "plug in" different UI
frameworks. We'll need a UI layer who represents the screen contents
in
an abstracted way (possbly an enhanced Freemarker macro library) and make it possible to generate HTML code with the right css attributes
for
the target library.

- a rewrite of the screens will be necessary to make the UI less
cluttered and overloaded. This will require some concepts/design work
beforehand

- there are surely many other possible requirements (I am not a UX or
web design expert)


I appreciate the contribution of the new theme. I am also sure that
this
will not solve the challenge to drive OFBiz to another level, UI wise.

Thanks and regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 03.07.17 um 10:52 schrieb Sharan Foga:

Hi All

Don't forget that we also had the offer of a theme from Provolve and
Stannah.

https://issues.apache.org/jira/browse/OFBIZ-6985

This is a theme that they are using at the moment (so it working) and have said it could be contributed back to the project. If it's only a case of having someone volunteer to implement it into the trunk then this could be a way to get a nice theme up and running quickly for
us.

Thanks
Sharan

On 03/07/17 10:29, Michael Brohl wrote:

Thanks Nicolas,

is there anything, even work in progress, you are able to share at
the moment?

This way other could chime in and help moving further.

Thanks,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 03.07.17 um 09:26 schrieb Nicolas Malin:

Hi Michael

Le 02/07/2017 à 20:42, Michael Brohl a écrit :

Hi Julien, all,

I'd like to resurrect this discussion and the activities to
improve
the OFBiz user interface. I think we really should put some
focused
effort on it if we want OFBiz to be recognized as a modern ERP. Also, if we imporve the UI, more users and also developers will be
attracted which will be a win for the community and further
development of OFBiz.

Nicolas and others who have started work on this: can you give us
an update about the efforts undertaken and where we stand?

Currently I block on the comon-theme with a good information
propagation. My next step will be create a dedicate object as
referent on widget context, but my works has been disturb with the
framework separation and the git-svn link break.
Instead of continue, I help some people to work on the groovy
mini-lang conversion. I plan to improve a few the groovy DSL and
after I continue the work on commont-theme.

Nicolas




Reply via email to