At least by review in new committed code. It would not be impossible technically but very difficult to enforce else, I mean in not OOTB code (just a thought)

Also we have still to discuss if we will apply to all existing code or if it will be only applied alongside in the "other" way (which still need to be clarified/defined)


I think the best is to review the POC Nicolas provided in his GitHub account. I did not get a chance yet, so I was mostly asking to better understand the proposition

Jacques


Le 30/11/2016 à 21:16, Pierre Smits a écrit :
So when you speak of

a super-structure that will be used in place of currently conventions which
are not always respected

how do you envision that with that new 'super-structure' conventions will
be respected?

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, Nov 30, 2016 at 9:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Julien

Inline ...

Le 30/11/2016 à 10:02, Julien NICOLAS a écrit :

Hi Jacques,


On 30/11/2016 08:51, Jacques Le Roux wrote:

  - Each screen must be linked to a screen structure.

What would be this screen structure? You don't need to develop much at
this stage, just that I can't vision what it would be.

This structure is to follow the a UI standard that can be managed by the
theme. For example, the find screen can be define as :
  - A research field area
  - A result area

Ah, I see, we have already this concept in screen widget.


If all the find screen could be linked to this structure, it will be
easier for theme to manage it's own template of search screen.

You mean that it would be a super-structure that will be used in place of
currently conventions which are not always respected, I see.

It will be included in the main decorator that will also linked to a
structure, so theme can manage to change the template. And when you change
the theme, it could be a completely different look and feel :)
I hope I explain well my thought.

Got it, thanks :)


Why we need a new component to test new theme ?

When I start working with OFBiz, I was so surprised that the UI is too
heavy. Then I was thinking that I have to improve the UI to provide a best
one. After several try I understand that the actual UI is not a final user
interface. It is a developer one. It's a developer UI because it contain
all the features developed. But definitively, we can't provide this kind of
UI to final users, we have to simplify it. In the same times, we can't
delete the current UI because developers need to improve it with new
features that will help us to deploy new features to our final users.

For this new component, we can implement an existing component but
simplified and ready for the new theme(s).

You mean we could take and existing component, say example for instance,
and would simply it at the UI level. I picked example because it's already
rather simple and contains demonstration of features.

No, I mean to define a component (party, product, facility, etc.) that we
start to re-implement (using the existing services) but in a more simple
way (without all the features, selecting only the main ones).

I see


In conclusion, if the new component dedicated for test a new theme
match to the community needs, Taher think to a super simplified developer
user interface that facilitate developers to improve the software. A new
interface without any constraint that allow developers to develop easily
new features.


Another thing I can't vision at this stage, no hurry, I guess I'll later
:)

Yes, too many thing to explain, I have to add details about this point,
I'll do it soon ^^

I did not get a chance to look yet at the POC Nicolas, Gil and you are
working on. I guess I'd get the ideas from there then?

Thanks

Jacques


Reply via email to