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