I am working on this
On Dec 1, 2016 12:48 PM, "Jacques Le Roux" <jacques.le.r...@les7arts.com>
wrote:

Advertising

> Totally agreed!
>
> BTW Gareth Cater told me he did a work related to "custom-widget" (he used
> the same term but not sure it's the same thing). I'll try to contact him
> about that. Has anybody else begun to work on that?
>
> Jacques
>
>
> Le 01/12/2016 à 10:38, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> That was already discussed. My opinion is still not to allow it BUT, you
>> can create a DSL for something, let's call it custom-widget. Then, all
>> that
>> you need to do to drop down to FTL is to create macros in the theme to
>> implement your special widget.
>>
>> This way, you can maintain purity of the widgets while at the same time
>> allowing you to muck with HTML. In a sense, we tell our developers, do
>> whatever you want, OUTSIDE. So this custom-widget becomes the gateway to
>> that.
>>
>> On Thu, Dec 1, 2016 at 12:28 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>> That would be good, I know we can do a lot with form widgets backed by js
>>> scripts and I'm always been a form widgets enthusiast (if not fanatic
>>> :D).
>>>
>>> But there should be also a way to allow to call FTL from screens because,
>>> in an ecommerce alike situation, it's not realistic to do it all with
>>> form
>>> widgets (at least as is now). Could be allowed on certain component for
>>> instance or using properties.
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 01/12/2016 à 09:56, Taher Alkhateeb a écrit :
>>>
>>> I think by introducing a new DSL we can enforce no leakage of HTML / FTL
>>>> into any widgets (I'm assuming this is what you guys are talking about)
>>>>
>>>> On Thu, Dec 1, 2016 at 11:49 AM, Jacques Le Roux <
>>>> jacques.le.r...@les7arts.com> wrote:
>>>>
>>>> Nicely said, thanks Julien :)
>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 01/12/2016 à 09:46, Julien NICOLAS a écrit :
>>>>>
>>>>> Hi Pierre,
>>>>>
>>>>>> I hope that, like code source convention, people will respect the work
>>>>>> done and respect people behind them.
>>>>>>
>>>>>> I think that I'll do my best to explain the reason of the work I'll
>>>>>> begin, hope that it will be accepted by the community, hope that it
>>>>>> will be
>>>>>> implemented in all OFBiz screens. I know that the OFBiz community are
>>>>>> good
>>>>>> people and respect that.
>>>>>>
>>>>>> But you true, it could happens that somebody fail to follow rules, I
>>>>>> hope
>>>>>> I see it in code review and ask for an update ;)
>>>>>>
>>>>>> I'm quite sure that when you'll be charmed by this UI standard, you'll
>>>>>> be
>>>>>> also a rules keeper <3
>>>>>>
>>>>>> Have a nice day,
>>>>>>
>>>>>> Julien.
>>>>>>
>>>>>>
>>>>>> On 30/11/2016 21:16, Pierre Smits wrote:
>>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>