Re: [DISCUSSION] Improving the OFBiz User Interface

[Deepak Dixit]

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

Re: [DISCUSSION] Improving the OFBiz User Interface

[Michael Brohl]

These are good news, Nicolas :-)

I started to review your efforts on common-theme but might not have 
digged deep enough to notice the separation layer (there are many 
changes already). I thought that it just moved the base theme and images 
stuff out of the framework.


I really appreciate your priority change and look forward to the new 
base for theming.


In the meantime I will start to do some prototyping for a new theme as a 
base for further discussion (a picture is worth a thousand words ;-) )


Kind regards,

Michael


Am 05.07.17 um 23:21 schrieb Nicolas Malin:
Michael the separation layer between html/css/js lib and the model 
screen is already done on the common-theme present on my github repo 
(1) without break older theme.


This it's the easier face on the problem, because the hidden face is 
present with elements who use macro without ui rendering linked to a 
theme like some content or pdf. I will follow your effort and raise 
this task on the upper priority :)


Cheers

Nicolas


(1) https://github.com/nmalin/ApacheOFBiz/tree/common-theme
Le 05/07/2017 à 22:18, Michael Brohl a écrit :
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
 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-difference-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 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Nicolas Malin]

Michael the separation layer between html/css/js lib and the model 
screen is already done on the common-theme present on my github repo (1) 
without break older theme.


This it's the easier face on the problem, because the hidden face is 
present with elements who use macro without ui rendering linked to a 
theme like some content or pdf. I will follow your effort and raise this 
task on the upper priority :)


Cheers

Nicolas


(1) https://github.com/nmalin/ApacheOFBiz/tree/common-theme
Le 05/07/2017 à 22:18, Michael Brohl a écrit :

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

Re: [DISCUSSION] Improving the OFBiz User Interface

[Michael Brohl]

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
 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-difference-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
Foundation https://www.keycdn.com/blog/bootstrap-vs-foundation, this could
be possibly discussed.
That's what ilscipio 

Re: [PROPOSAL] Environment variable configuration

[Taher Alkhateeb]

I faced something similar in the past (Not related to OFBiz). Many
systems require different paths of configuration depending on
different deployment scenarios.

There are multiple types of configurations I can think of including:
- platform dependent configurations (it depends on your server and the
environment)
- Sensitive information like passwords
- platform independent (test vs deployment environments for example)

I think the first two do not belong to the code base. And so the best
option for such problems that I used in the past is templates
(whatever technology you choose). Templates + Build system +
environment variables substantially simplify deployment when compared
with patches that are highly dependent on the current state of the
code base.

Now for the third kind (platform independent like multiple targets)
maybe we can get some good ideas from ruby-on-rails [1]. Essentially
we can tweak the build system and add a few environment files to allow
for multiple target environments.

[1] http://guides.rubyonrails.org/configuring.html

On Wed, Jul 5, 2017 at 6:56 PM, Michael Brohl  wrote:
> Hi Gil,
>
> we have similar challenges and modified OFBiz to deal with it easily. We
> offered to contribute this long time ago (2008) but it was decided against
> [1]. It was suggested to use patches instead but I think it's too
> complicated to manage several patch sets for different environments.
>
> We now use a staged configure mechanism which uses a base build file, auto
> detected machine name and provided parameters to decide which configurations
> should be pulled for the environment. It's currently Ant based and therefore
> does not fit into the current build mechanism (on the todo list).
>
> I like your approach also and I think it should be evaluated and discussed.
>
> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
> [1]
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
>
>
>
> Am 05.07.17 um 17:36 schrieb gil portenseigne:
>
>> Hello all,
>>
>> Working with different hosting companies, we used to have issues when
>> deploying OFBiz concerning technical configuration of the different
>> environments.
>> We are writing this mail to get feedback from the community and eventually
>> propose to improve OFBiz on this matter.
>>
>> For a customer, we are working with 4 instances of a release 13.07 OFBiz,
>> and are currently using a set of patches (with addonmanager...) to manage
>> environment specific configurations.
>> During each production deployment, the hosting company receive from our
>> jenkins a precompiled archive containing OFBiz codebase, and then apply the
>> set of patches to configure it to the environment needs, recompile and
>> relaunch...
>>
>> This way of doing can cause issue when patch could not apply, after a
>> codebase modification (pretty rare but it happens).
>>
>> We are not satisfied with this way of doing, we are currently thinking
>> about using environment variables to configure technical environment
>> properties (those are on the hosting company responsibility), and to keep
>> functional specifics into the code base.
>> If you have some experience or advice in this matter, you are welcome.
>>
>> For our case, we currently have enhanced OFBiz to be able to get
>> environment variable from the operating system within property file and some
>> other configuration files (with default value if not set).
>>
>> Examples :
>> *In Property file :
>> password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz
>> if unset
>> other_config=${env:OTHER_CONF:${partyId}} -> environment variable
>> OTHER_CONF or ${partyId} if unset
>> *In entityengine.xml :
>>
>> jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
>> jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
>> jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>
>>
>> That allow us to keep functional parameters stored within git branches.
>> Our jenkins now is able to build our 4 configured and compiled instances and
>> deliver it to the hosting company, that just have to set/check environment
>> variable (database access, activeMQ, log location, instance id, etc.) before
>> starting OFBiz app. Now we cannot have configuration failure during
>> deployment.
>>
>> We will be glad to contribute it, if it's the good way to go !
>>
>> Best Regards !
>>
>> Gil Portenseigne
>>
>
>

Re: [PROPOSAL] Environment variable configuration

[Michael Brohl]

Hi Gil,

we have similar challenges and modified OFBiz to deal with it easily. We 
offered to contribute this long time ago (2008) but it was decided 
against [1]. It was suggested to use patches instead but I think it's 
too complicated to manage several patch sets for different environments.


We now use a staged configure mechanism which uses a base build file, 
auto detected machine name and provided parameters to decide which 
configurations should be pulled for the environment. It's currently Ant 
based and therefore does not fit into the current build mechanism (on 
the todo list).


I like your approach also and I think it should be evaluated and discussed.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] 
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E




Am 05.07.17 um 17:36 schrieb gil portenseigne:

Hello all,

Working with different hosting companies, we used to have issues when 
deploying OFBiz concerning technical configuration of the different 
environments.
We are writing this mail to get feedback from the community and 
eventually propose to improve OFBiz on this matter.


For a customer, we are working with 4 instances of a release 13.07 
OFBiz, and are currently using a set of patches (with addonmanager...) 
to manage environment specific configurations.
During each production deployment, the hosting company receive from 
our jenkins a precompiled archive containing OFBiz codebase, and then 
apply the set of patches to configure it to the environment needs, 
recompile and relaunch...


This way of doing can cause issue when patch could not apply, after a 
codebase modification (pretty rare but it happens).


We are not satisfied with this way of doing, we are currently thinking 
about using environment variables to configure technical environment 
properties (those are on the hosting company responsibility), and to 
keep functional specifics into the code base.

If you have some experience or advice in this matter, you are welcome.

For our case, we currently have enhanced OFBiz to be able to get 
environment variable from the operating system within property file 
and some other configuration files (with default value if not set).


Examples :
*In Property file :
password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or 
ofbiz if unset
other_config=${env:OTHER_CONF:${partyId}} -> environment variable 
OTHER_CONF or ${partyId} if unset

*In entityengine.xml :
jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}" 


jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>

That allow us to keep functional parameters stored within git 
branches. Our jenkins now is able to build our 4 configured and 
compiled instances and deliver it to the hosting company, that just 
have to set/check environment variable (database access, activeMQ, log 
location, instance id, etc.) before starting OFBiz app. Now we cannot 
have configuration failure during deployment.


We will be glad to contribute it, if it's the good way to go !

Best Regards !

Gil Portenseigne






smime.p7s
Description: S/MIME Cryptographic Signature

[PROPOSAL] Environment variable configuration

[gil portenseigne]

Hello all,

Working with different hosting companies, we used to have issues when 
deploying OFBiz concerning technical configuration of the different 
environments.
We are writing this mail to get feedback from the community and 
eventually propose to improve OFBiz on this matter.


For a customer, we are working with 4 instances of a release 13.07 
OFBiz, and are currently using a set of patches (with addonmanager...) 
to manage environment specific configurations.
During each production deployment, the hosting company receive from our 
jenkins a precompiled archive containing OFBiz codebase, and then apply 
the set of patches to configure it to the environment needs, recompile 
and relaunch...


This way of doing can cause issue when patch could not apply, after a 
codebase modification (pretty rare but it happens).


We are not satisfied with this way of doing, we are currently thinking 
about using environment variables to configure technical environment 
properties (those are on the hosting company responsibility), and to 
keep functional specifics into the code base.

If you have some experience or advice in this matter, you are welcome.

For our case, we currently have enhanced OFBiz to be able to get 
environment variable from the operating system within property file and 
some other configuration files (with default value if not set).


Examples :
*In Property file :
password=${env:ONE_CONF:ofbiz} -> environment variable ONE_CONF or ofbiz 
if unset
other_config=${env:OTHER_CONF:${partyId}} -> environment variable 
OTHER_CONF or ${partyId} if unset

*In entityengine.xml :
jdbc-uri="${env:DB_POSTGRES_URI:jdbc:mysql://127.0.0.1/ofbiz?autoReconnect=true}"
jdbc-username="${env:DB_POSTGRES_USER:ofbiz}"
jdbc-password="${env:DB_POSTGRES_PWD:ofbiz}"/>

That allow us to keep functional parameters stored within git branches. 
Our jenkins now is able to build our 4 configured and compiled instances 
and deliver it to the hosting company, that just have to set/check 
environment variable (database access, activeMQ, log location, instance 
id, etc.) before starting OFBiz app. Now we cannot have configuration 
failure during deployment.


We will be glad to contribute it, if it's the good way to go !

Best Regards !

Gil Portenseigne

Re: [DISCUSSION] Improving the OFBiz User Interface

[James Yong]

Hi Michael,

I agreed it will be going too far if we adopt JSF.
Maybe better value to spend on improving what OFBiz already have.

Regards,
James Yong

On 2017/07/04 14:57:33, Michael Brohl  wrote: 
> 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.
> 
> 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?
> 
> 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  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 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Michael Brohl]

Ah, thanks for the pointer, Jacques.

I forgot about this and will have a look at the work Nicolas did there 
so far.


Regards,

Michael


Am 05.07.17 um 14:09 schrieb Jacques Le Roux:

That makes sense Taher and was already discussed and mostly agreed IIRW.

There is even a Jira for that 
https://issues.apache.org/jira/browse/OFBIZ-5776


Jacques


Le 05/07/2017 à 13:40, Taher Alkhateeb a écrit :

Hi Michael,

My suggestion (other opinions might enrich the discussion) is to limit
current work to moving actual web items (html, css, javascript, 
images and

so on).

Moving ftl might be too much work and perhaps widgets should stay where
they are. What I suggest moving is things that live in the browser to 
the

base/common theme.

On Jul 5, 2017 11:50 AM, "Michael Brohl"  
wrote:


Hi Taher,

do I understand you correctly that you want to move all screen 
definitions

and the ftl template files (containing the html) to a central component
outside the framework/applications?

Regards,
Michael

Am 04.07.17 um 23:50 schrieb Taher Alkhateeb:

Hi Michael,

I think we agree, just a difference in semantics. What I mean by web
is anything CSS, JavaScript, or HTML, not FreeMarker (for now). The
smaller the effort the bigger the chances to move this initiative
forward, so yeah I think we're on the same page.

On Wed, Jul 5, 2017 at 12:35 AM, Michael Brohl 


wrote:


Hi Taher,

I agree that all ressources like images, css etc. should be moved 
away in

a
foundation component. I am not sure if I can follow your suggestion to
move
everything web-related from the framework to another component. In my
mind,
the foundation for the UI development (Renderer, macro libraries,
transformers etc.) should reside in the framework.

I think it would be also a too big move to rewrite/move all this at 
once

and
has not enough visible impact for users to be highly prioritized.

For me, a new and modern UI would be the highest priority at the 
moment. I
hope that this will attract more contributors and more users to 
grow the

community.

After this, more restructuring and separation can be done.

At ecomify, we are currently evaluating if we can set a team on it to
implement a new UI. It will be a lot of work and a big effort for 
us but I

think it's worth it. We'll see how this will work out and how we can
contribute this back to the project.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


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

buildbot success in on ofbiz-branch16

[buildbot]

The Buildbot has detected a restored build on builder ofbiz-branch16 while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-branch16/builds/78

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz16-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release16.11] 1800854
Blamelist: mbrohl

Build succeeded!

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

[Jacques Le Roux]

That makes sense Taher and was already discussed and mostly agreed IIRW.

There is even a Jira for that https://issues.apache.org/jira/browse/OFBIZ-5776

Jacques


Le 05/07/2017 à 13:40, Taher Alkhateeb a écrit :

Hi Michael,

My suggestion (other opinions might enrich the discussion) is to limit
current work to moving actual web items (html, css, javascript, images and
so on).

Moving ftl might be too much work and perhaps widgets should stay where
they are. What I suggest moving is things that live in the browser to the
base/common theme.

On Jul 5, 2017 11:50 AM, "Michael Brohl"  wrote:

Hi Taher,

do I understand you correctly that you want to move all screen definitions
and the ftl template files (containing the html) to a central component
outside the framework/applications?

Regards,
Michael

Am 04.07.17 um 23:50 schrieb Taher Alkhateeb:

Hi Michael,

I think we agree, just a difference in semantics. What I mean by web
is anything CSS, JavaScript, or HTML, not FreeMarker (for now). The
smaller the effort the bigger the chances to move this initiative
forward, so yeah I think we're on the same page.

On Wed, Jul 5, 2017 at 12:35 AM, Michael Brohl 
wrote:


Hi Taher,

I agree that all ressources like images, css etc. should be moved away in
a
foundation component. I am not sure if I can follow your suggestion to
move
everything web-related from the framework to another component. In my
mind,
the foundation for the UI development (Renderer, macro libraries,
transformers etc.) should reside in the framework.

I think it would be also a too big move to rewrite/move all this at once
and
has not enough visible impact for users to be highly prioritized.

For me, a new and modern UI would be the highest priority at the moment. I
hope that this will attract more contributors and more users to grow the
community.

After this, more restructuring and separation can be done.

At ecomify, we are currently evaluating if we can set a team on it to
implement a new UI. It will be a lot of work and a big effort for us but I
think it's worth it. We'll see how this will work out and how we can
contribute this back to the project.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


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

buildbot exception in on ofbiz-trunk-framework

[buildbot]

The Buildbot has detected a build exception on builder ofbiz-trunk-framework 
while building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/250

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 
'on-ofbiz-framework-commit' triggered this build
Build Source Stamp: [branch ofbiz/ofbiz-framework/trunk] 1800853
Blamelist: mbrohl

BUILD FAILED: exception svn upload interrupted

Sincerely,
 -The Buildbot

Re: [DISCUSSION] Improving the OFBiz User Interface

[Taher Alkhateeb]

Hi Michael,

My suggestion (other opinions might enrich the discussion) is to limit
current work to moving actual web items (html, css, javascript, images and
so on).

Moving ftl might be too much work and perhaps widgets should stay where
they are. What I suggest moving is things that live in the browser to the
base/common theme.

On Jul 5, 2017 11:50 AM, "Michael Brohl"  wrote:

Hi Taher,

do I understand you correctly that you want to move all screen definitions
and the ftl template files (containing the html) to a central component
outside the framework/applications?

Regards,
Michael

Am 04.07.17 um 23:50 schrieb Taher Alkhateeb:

Hi Michael,
>
> I think we agree, just a difference in semantics. What I mean by web
> is anything CSS, JavaScript, or HTML, not FreeMarker (for now). The
> smaller the effort the bigger the chances to move this initiative
> forward, so yeah I think we're on the same page.
>
> On Wed, Jul 5, 2017 at 12:35 AM, Michael Brohl 
> wrote:
>
>> Hi Taher,
>>
>> I agree that all ressources like images, css etc. should be moved away in
>> a
>> foundation component. I am not sure if I can follow your suggestion to
>> move
>> everything web-related from the framework to another component. In my
>> mind,
>> the foundation for the UI development (Renderer, macro libraries,
>> transformers etc.) should reside in the framework.
>>
>> I think it would be also a too big move to rewrite/move all this at once
>> and
>> has not enough visible impact for users to be highly prioritized.
>>
>> For me, a new and modern UI would be the highest priority at the moment. I
>> hope that this will attract more contributors and more users to grow the
>> community.
>>
>> After this, more restructuring and separation can be done.
>>
>> At ecomify, we are currently evaluating if we can set a team on it to
>> implement a new UI. It will be a lot of work and a big effort for us but I
>> think it's worth it. We'll see how this will work out and how we can
>> contribute this back to the project.
>>
>> Best regards,
>>
>> Michael Brohl
>> ecomify GmbH
>> www.ecomify.de
>>
>>
>> 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
>>>  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 

Re: [DISCUSSION] Improving the OFBiz User Interface

[Michael Brohl]

Hi Taher,

do I understand you correctly that you want to move all screen 
definitions and the ftl template files (containing the html) to a 
central component outside the framework/applications?


Regards,
Michael

Am 04.07.17 um 23:50 schrieb Taher Alkhateeb:

Hi Michael,

I think we agree, just a difference in semantics. What I mean by web
is anything CSS, JavaScript, or HTML, not FreeMarker (for now). The
smaller the effort the bigger the chances to move this initiative
forward, so yeah I think we're on the same page.

On Wed, Jul 5, 2017 at 12:35 AM, Michael Brohl  wrote:

Hi Taher,

I agree that all ressources like images, css etc. should be moved away in a
foundation component. I am not sure if I can follow your suggestion to move
everything web-related from the framework to another component. In my mind,
the foundation for the UI development (Renderer, macro libraries,
transformers etc.) should reside in the framework.

I think it would be also a too big move to rewrite/move all this at once and
has not enough visible impact for users to be highly prioritized.

For me, a new and modern UI would be the highest priority at the moment. I
hope that this will attract more contributors and more users to grow the
community.

After this, more restructuring and separation can be done.

At ecomify, we are currently evaluating if we can set a team on it to
implement a new UI. It will be a lot of work and a big effort for us but I
think it's worth it. We'll see how this will work out and how we can
contribute this back to the project.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


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
 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-difference-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
Foundation https://www.keycdn.com/blog/bootstrap-vs-foundation, this
could
be possibly discussed.
That's what ilscipio has used, with some success