Which demo page are you referring to, Gaurav?
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 8:46 PM, Gaurav Saini <[hidden email]> wrote: > Right, looks like it doesn't have entire features covered from the demo > page I saw. > But yes on similar tracks we can build something really good to go. > > Thanks > Gaurav > > On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits <[hidden email]> > wrote: > > > You talking about something like > > > > - [1], which is bootstrap based and intended for customer facing apps > > (e.g. cmssite and ecommerce variants), > > - [2], which is current default ecommerce theme elements disentangled > > from the framework stack > > > > ? > > > > [1] https://github.com/ORRTIZ/ecbootstrap > > [2] https://github.com/ORRTIZ/ecdefault > > > > 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 8:06 PM, Gaurav Saini <[hidden email]> > > wrote: > > > > > Hello Everyone, > > > > > > Looks like I am jumping a bit late here. But as Julien said I am really > > > interested on working on the UI side of the project. I am still looking > > > deep into the ofbiz structure and understand how Julien is proposing to > > do > > > UI customisation so I can help and make OFBiz look good :) > > > > > > For starting what I am able to understand and quickly start is prepare > a > > > theme for the e-commerce component that is responsive in nature and > with > > > good UI/UX components. So, anyone starting with ofbiz can directly use > > the > > > theme with minor changes according to need. > > > > > > Just to mention, I have updated my angular code to github which i > > presented > > > in presentation at ApacheCON. I have already posting link on hipchat, > if > > > somebody interested can look into it. I was interested in using angular > > as > > > all together different single page app outside ofbiz because it helped > me > > > do good amount of UI customisation and on the other hand for small > > modules > > > or some specific requirement it was really light-weight to use at > > client's > > > end. > > > https://github.com/gauravsaini03/ofbiz-angular > > > > > > Thanks > > > Gaurav > > > > > > > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS < > > [hidden email] > > > > > > > wrote: > > > > > > > Yes, I agree, let's make it simple for the POC. > > > > > > > > > > > > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > > > > > > > >> Amazing discussion and initiative. > > > >> My only recommendation at the moment is to try to plan very short > (in > > > >> scope and in time) development cycles (requirements gathering and > > > >> discussion, design, implementation, review) so that each cycle could > > > focus > > > >> on a specific experiment/proposal (e.g. a given ui technology) and > > could > > > >> deliver a proof of concept to the community (e.g. as a new > component) > > > for > > > >> further discussion and work. > > > >> > > > >> In this way we will be able to quickly implement and compare > different > > > >> solutions/technologies and will have a chance to take a more > informed > > > >> decision. > > > >> > > > >> Jacopo > > > >> > > > >> > > > > > > > > > > > > > -- > > > Regards, > > > *Gaurav Saini* > > > > > > > > > -- > Regards, > *Gaurav Saini* > |
https://oem.ofbizci.net/oci-2/products/oem-promotions/p_orrtiz-oshop
On Thu, Dec 1, 2016 at 1:20 AM, Pierre Smits <[hidden email]> wrote: > Which demo page are you referring to, Gaurav? > > 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 8:46 PM, Gaurav Saini <[hidden email]> > wrote: > > > Right, looks like it doesn't have entire features covered from the demo > > page I saw. > > But yes on similar tracks we can build something really good to go. > > > > Thanks > > Gaurav > > > > On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits <[hidden email]> > > wrote: > > > > > You talking about something like > > > > > > - [1], which is bootstrap based and intended for customer facing > apps > > > (e.g. cmssite and ecommerce variants), > > > - [2], which is current default ecommerce theme elements > disentangled > > > from the framework stack > > > > > > ? > > > > > > [1] https://github.com/ORRTIZ/ecbootstrap > > > [2] https://github.com/ORRTIZ/ecdefault > > > > > > 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 8:06 PM, Gaurav Saini <[hidden email] > > > > > wrote: > > > > > > > Hello Everyone, > > > > > > > > Looks like I am jumping a bit late here. But as Julien said I am > really > > > > interested on working on the UI side of the project. I am still > looking > > > > deep into the ofbiz structure and understand how Julien is proposing > to > > > do > > > > UI customisation so I can help and make OFBiz look good :) > > > > > > > > For starting what I am able to understand and quickly start is > prepare > > a > > > > theme for the e-commerce component that is responsive in nature and > > with > > > > good UI/UX components. So, anyone starting with ofbiz can directly > use > > > the > > > > theme with minor changes according to need. > > > > > > > > Just to mention, I have updated my angular code to github which i > > > presented > > > > in presentation at ApacheCON. I have already posting link on hipchat, > > if > > > > somebody interested can look into it. I was interested in using > angular > > > as > > > > all together different single page app outside ofbiz because it > helped > > me > > > > do good amount of UI customisation and on the other hand for small > > > modules > > > > or some specific requirement it was really light-weight to use at > > > client's > > > > end. > > > > https://github.com/gauravsaini03/ofbiz-angular > > > > > > > > Thanks > > > > Gaurav > > > > > > > > > > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS < > > > [hidden email] > > > > > > > > > wrote: > > > > > > > > > Yes, I agree, let's make it simple for the POC. > > > > > > > > > > > > > > > > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > > > > > > > > > >> Amazing discussion and initiative. > > > > >> My only recommendation at the moment is to try to plan very short > > (in > > > > >> scope and in time) development cycles (requirements gathering and > > > > >> discussion, design, implementation, review) so that each cycle > could > > > > focus > > > > >> on a specific experiment/proposal (e.g. a given ui technology) and > > > could > > > > >> deliver a proof of concept to the community (e.g. as a new > > component) > > > > for > > > > >> further discussion and work. > > > > >> > > > > >> In this way we will be able to quickly implement and compare > > different > > > > >> solutions/technologies and will have a chance to take a more > > informed > > > > >> decision. > > > > >> > > > > >> Jacopo > > > > >> > > > > >> > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > *Gaurav Saini* > > > > > > > > > > > > > > > -- > > Regards, > > *Gaurav Saini* > > > -- Regards, *Gaurav Saini* |
Ahh. Thanks.
That (https://oem.ofbizci.net/oci-2) uses a different theme and customer facing component. The theme is based on the ZURB Foundation front-end framework. 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 8:51 PM, Gaurav Saini <[hidden email]> wrote: > https://oem.ofbizci.net/oci-2/products/oem-promotions/p_orrtiz-oshop > > On Thu, Dec 1, 2016 at 1:20 AM, Pierre Smits <[hidden email]> > wrote: > > > Which demo page are you referring to, Gaurav? > > > > 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 8:46 PM, Gaurav Saini <[hidden email]> > > wrote: > > > > > Right, looks like it doesn't have entire features covered from the demo > > > page I saw. > > > But yes on similar tracks we can build something really good to go. > > > > > > Thanks > > > Gaurav > > > > > > On Thu, Dec 1, 2016 at 1:08 AM, Pierre Smits <[hidden email]> > > > wrote: > > > > > > > You talking about something like > > > > > > > > - [1], which is bootstrap based and intended for customer facing > > apps > > > > (e.g. cmssite and ecommerce variants), > > > > - [2], which is current default ecommerce theme elements > > disentangled > > > > from the framework stack > > > > > > > > ? > > > > > > > > [1] https://github.com/ORRTIZ/ecbootstrap > > > > [2] https://github.com/ORRTIZ/ecdefault > > > > > > > > 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 8:06 PM, Gaurav Saini < > [hidden email] > > > > > > > wrote: > > > > > > > > > Hello Everyone, > > > > > > > > > > Looks like I am jumping a bit late here. But as Julien said I am > > really > > > > > interested on working on the UI side of the project. I am still > > looking > > > > > deep into the ofbiz structure and understand how Julien is > proposing > > to > > > > do > > > > > UI customisation so I can help and make OFBiz look good :) > > > > > > > > > > For starting what I am able to understand and quickly start is > > prepare > > > a > > > > > theme for the e-commerce component that is responsive in nature and > > > with > > > > > good UI/UX components. So, anyone starting with ofbiz can directly > > use > > > > the > > > > > theme with minor changes according to need. > > > > > > > > > > Just to mention, I have updated my angular code to github which i > > > > presented > > > > > in presentation at ApacheCON. I have already posting link on > hipchat, > > > if > > > > > somebody interested can look into it. I was interested in using > > angular > > > > as > > > > > all together different single page app outside ofbiz because it > > helped > > > me > > > > > do good amount of UI customisation and on the other hand for small > > > > modules > > > > > or some specific requirement it was really light-weight to use at > > > > client's > > > > > end. > > > > > https://github.com/gauravsaini03/ofbiz-angular > > > > > > > > > > Thanks > > > > > Gaurav > > > > > > > > > > > > > > > On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS < > > > > [hidden email] > > > > > > > > > > > wrote: > > > > > > > > > > > Yes, I agree, let's make it simple for the POC. > > > > > > > > > > > > > > > > > > > > > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > > > > > > > > > > > >> Amazing discussion and initiative. > > > > > >> My only recommendation at the moment is to try to plan very > short > > > (in > > > > > >> scope and in time) development cycles (requirements gathering > and > > > > > >> discussion, design, implementation, review) so that each cycle > > could > > > > > focus > > > > > >> on a specific experiment/proposal (e.g. a given ui technology) > and > > > > could > > > > > >> deliver a proof of concept to the community (e.g. as a new > > > component) > > > > > for > > > > > >> further discussion and work. > > > > > >> > > > > > >> In this way we will be able to quickly implement and compare > > > different > > > > > >> solutions/technologies and will have a chance to take a more > > > informed > > > > > >> decision. > > > > > >> > > > > > >> Jacopo > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > *Gaurav Saini* > > > > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > *Gaurav Saini* > > > > > > > > > -- > Regards, > *Gaurav Saini* > |
Administrator
|
In reply to this post by Julien NICOLAS
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 |
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 < [hidden email]> 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 > |
In reply to this post by Sharan Foga
Well done Gaurav!
-----邮件原件----- 发件人: Gaurav Saini [mailto:[hidden email]] 发送时间: 2016年12月1日 3:07 收件人: [hidden email] 主题: Re: [DISCUSSION] Improving the OFBiz User Interface Hello Everyone, Looks like I am jumping a bit late here. But as Julien said I am really interested on working on the UI side of the project. I am still looking deep into the ofbiz structure and understand how Julien is proposing to do UI customisation so I can help and make OFBiz look good :) For starting what I am able to understand and quickly start is prepare a theme for the e-commerce component that is responsive in nature and with good UI/UX components. So, anyone starting with ofbiz can directly use the theme with minor changes according to need. Just to mention, I have updated my angular code to github which i presented in presentation at ApacheCON. I have already posting link on hipchat, if somebody interested can look into it. I was interested in using angular as all together different single page app outside ofbiz because it helped me do good amount of UI customisation and on the other hand for small modules or some specific requirement it was really light-weight to use at client's end. https://github.com/gauravsaini03/ofbiz-angular Thanks Gaurav On Wed, Nov 30, 2016 at 6:54 PM, Julien NICOLAS <[hidden email]> wrote: > Yes, I agree, let's make it simple for the POC. > > > > On 30/11/2016 11:07, Jacopo Cappellato wrote: > >> Amazing discussion and initiative. >> My only recommendation at the moment is to try to plan very short >> (in scope and in time) development cycles (requirements gathering and >> discussion, design, implementation, review) so that each cycle could >> focus on a specific experiment/proposal (e.g. a given ui technology) >> and could deliver a proof of concept to the community (e.g. as a new >> component) for further discussion and work. >> >> In this way we will be able to quickly implement and compare >> different solutions/technologies and will have a chance to take a >> more informed decision. >> >> Jacopo >> >> > -- Regards, *Gaurav Saini* |
Administrator
|
In reply to this post by Pierre Smits
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 < > [hidden email]> 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 >> |
In reply to this post by Pierre Smits
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 < > [hidden email]> 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 >> |
In reply to this post by Jacques Le Roux
This proposal is a package, this work is link to another big (huge) task
to rebuild the entire UI \o/ It always start with a first step, this is it ;) Julien. On 01/12/2016 09:36, Jacques Le Roux wrote: > 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 < >> [hidden email]> 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 >>> > > |
Administrator
|
In reply to this post by Julien NICOLAS
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 < >> [hidden email]> 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 >>> > > |
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 < [hidden email]> 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 < >>> [hidden email]> 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 >>>> >>>> >> >> > |
Administrator
|
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 < > [hidden email]> 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 < >>>> [hidden email]> 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 >>>>> >>>>> >>> |
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 < [hidden email]> 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 < >> [hidden email]> 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 < >>>>> [hidden email]> 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 >>>>>> >>>>>> >>>>>> >>>> > |
Administrator
|
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 < > [hidden email]> 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 < >>> [hidden email]> 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 < >>>>>> [hidden email]> 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 >>>>>>> >>>>>>> >>>>>>> |
I am working on this
On Dec 1, 2016 12:48 PM, "Jacques Le Roux" <[hidden email]> 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 < >> [hidden email]> 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 < >>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > |
Administrator
|
Taher,
Maybe you could share your ideas, and even work, in a Jira? Jacques Le 01/12/2016 à 10:53, Taher Alkhateeb a écrit : > I am working on this > > On Dec 1, 2016 12:48 PM, "Jacques Le Roux" <[hidden email]> > 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 < >>> [hidden email]> 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 < >>>>> [hidden email]> 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 < >>>>>>>> [hidden email]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> |
I will once I have something materialized. All code snippets and thoughts
right now, besides I'm still refactoring the code base. On Thu, Dec 1, 2016 at 1:09 PM, Jacques Le Roux < [hidden email]> wrote: > Taher, > > Maybe you could share your ideas, and even work, in a Jira? > > Jacques > > > > Le 01/12/2016 à 10:53, Taher Alkhateeb a écrit : > >> I am working on this >> >> On Dec 1, 2016 12:48 PM, "Jacques Le Roux" <[hidden email]> >> 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 < >>>> [hidden email]> 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 < >>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > |
In reply to this post by Sharan Foga
Hi all,
I start a page about the POC for the UI improvement. I'm not sure if the content is enough but I was wanted to create it. We can now start some... Jira ? I was wondering one main Jira linked to 4 other sub-jira. thanks to those Jira, we can have 4 teams or workgroup to go ahead in both ways. https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement Let me know if I'm doing well, Kind regards, Julien. PS : I'm currently checkout the common-theme provided by Nicolas's github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme) On 28/11/2016 11:28, Sharan Foga wrote: > Hi Everyone > > Another one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the OFBiz track at Apachecon that were about how we could improve our UI. > > If the UI was the main focus - what could the strategy look like > - User Interface - have 2 versions of the UI, one very clean and simple, the other more advanced. (Our current UI could be the advanced one....? > - Separate the web part from the widgets > - We have too many fields on one screen (many of them are not mandatory and are just included as optional). What if we slimmed down all the screens to have a sensible default UI for users. The UI could also be modifiable by service providers. Simplify the screens with defaults > - Use Bootstrap / CSS / Angular > - Isolate web related > - Define a graphics charter to be used for the screens > - Have a CSS convention > - Remove web from the framework - it shouldn't be there > > What do people think? > > -Do people think it would be a good idea to have 2 versions of the UI? (a simple one and a more advanced one?) > > - Are these the things we would need to focus on or have in place if we wanted to focus on the UI? > > (Also I know Nicolas has mentioned that he has already started work on a Proof of Concept for a common theme - so do we need to make sure we agree conventions etc before much more work is done?) > > Thanks > Sharan > |
In reply to this post by Julien NICOLAS
Hi everyone,
Sorry for the delay in reply. @Julien thanks for pulling me in. I would suggest if we can have API in place and meanwhile work on UX part along with the choice of Front end framework to start with. Lets Plan in detail. Thank you Thanks and Regards, Darshan Kumar +919900568729 On Wed, Nov 30, 2016 at 4:05 AM, Julien NICOLAS <[hidden email]> wrote: > Hi Sharan, everyone, > > It was idea like seed that start to grow up in my mind since I start with > OFBiz. Today, after several try on the project I think the community is > very closed to find the best way to improve the UI. > > The first sharing was with Gil and Nicolas, then we decide to submit a > talk about that. The big surprise was that Taher have the quite same ideas > than us !!! > > There are many things that must be done to have a good UI. > > - All the UI could be managed by the theme without modifying the > framework. > > - Each screen must be linked to a screen structure. > > - We need a UI standard that the developer need to follow for screen > creation. > > - We must have a common theme (remove all theming stuff from the > framework) > > - It could be interesting to have a new component to improve / test a new > theme > > - We have to create at least a new theme without limits ! Be crazy ! > > It's a long term project, but it must be our concern, all the people that > want a beautiful and UX UI must be involved \o/ I remember when I start > bootstrap topics, that we were many ;) > > This project is more ambitious, a long term one that will improve the > theming automatism to provide to the webdesigner an unlimited tool and, in > the same time, an easy to maintain framework for us ;) > > > 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). > > 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. > > > What about the new theme ? > > A new theme, maybe more than one theme. It could be crazy but if we need > to be sure that we can do anything we want and that the screen structure > allow webdesigner to do whatever we want, we can imagine 2 new themes > exactly different in structure :) > > I have at least an idea, just for the look and feel. I can share it and we > can improve it all together (or just scrap it and start with a new idea > ^^). In the same times, at the Apache Con we meet Victoria Bondarchuk > <http://events.linuxfoundation.org/events/apachecon-europe/program/schedule> > (work in UX project management) that want to help us in this task, and > Darshan Kumar (work also in UX) who want to join the OFBiz project starting > on that task. > > > How to start ? > > I propose to start by creating a main Jira about Improve the UI (maybe > this one already exist since a long long time ago ^^) and then link all the > subtasks to this main one. Maybe we can start a topic by subtask to share > with the community. > > > Before creating anything it could be interesting to have opinion of all > people who want UI changes. All the community I think, so I hope server > will not be down because of the OFBiz community involving ^^ > > I hope Paul, Gaurav and all the people that try or already improve the UI > will help on this task \o/ > > I want to be an actor of this changes and I hope you want it too ! > > Thanks for all your help in advance. > > Julien. > > On 28/11/2016 11:28, Sharan Foga wrote: > > Hi Everyone > > Another one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the OFBiz track at Apachecon that were about how we could improve our UI. > > If the UI was the main focus - what could the strategy look like > - User Interface - have 2 versions of the UI, one very clean and simple, the other more advanced. (Our current UI could be the advanced one....? > - Separate the web part from the widgets > - We have too many fields on one screen (many of them are not mandatory and are just included as optional). What if we slimmed down all the screens to have a sensible default UI for users. The UI could also be modifiable by service providers. Simplify the screens with defaults > - Use Bootstrap / CSS / Angular > - Isolate web related > - Define a graphics charter to be used for the screens > - Have a CSS convention > - Remove web from the framework - it shouldn't be there > > What do people think? > > -Do people think it would be a good idea to have 2 versions of the UI? (a simple one and a more advanced one?) > > - Are these the things we would need to focus on or have in place if we wanted to focus on the UI? > > (Also I know Nicolas has mentioned that he has already started work on a Proof of Concept for a common theme - so do we need to make sure we agree conventions etc before much more work is done?) > > Thanks > Sharan > > > > |
In reply to this post by Julien NICOLAS
Hi Julien
Is there any interest into the integration of a java UI framework such as vaadin? regards, Pierre On 01/12/2016 23:26, Julien NICOLAS wrote: > Hi all, > > I start a page about the POC for the UI improvement. > > I'm not sure if the content is enough but I was wanted to create it. > We can now start some... Jira ? I was wondering one main Jira linked > to 4 other sub-jira. > > thanks to those Jira, we can have 4 teams or workgroup to go ahead in > both ways. > > https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement > > Let me know if I'm doing well, > > Kind regards, > > Julien. > > PS : I'm currently checkout the common-theme provided by Nicolas's > github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme) > > > On 28/11/2016 11:28, Sharan Foga wrote: >> Hi Everyone >> >> Another one of the topics that came up during the brainstorming in >> Seville was around the UI. In fact we had at least 2 presentations >> from the OFBiz track at Apachecon that were about how we could >> improve our UI. >> >> If the UI was the main focus - what could the strategy look like >> - User Interface - have 2 versions of the UI, one very clean and >> simple, the other more advanced. (Our current UI could be the >> advanced one....? >> - Separate the web part from the widgets >> - We have too many fields on one screen (many of them are not >> mandatory and are just included as optional). What if we slimmed down >> all the screens to have a sensible default UI for users. The UI could >> also be modifiable by service providers. Simplify the screens with >> defaults >> - Use Bootstrap / CSS / Angular >> - Isolate web related >> - Define a graphics charter to be used for the screens >> - Have a CSS convention >> - Remove web from the framework - it shouldn't be there >> >> What do people think? >> >> -Do people think it would be a good idea to have 2 versions of the >> UI? (a simple one and a more advanced one?) >> >> - Are these the things we would need to focus on or have in place if >> we wanted to focus on the UI? >> >> (Also I know Nicolas has mentioned that he has already started work >> on a Proof of Concept for a common theme - so do we need to make >> sure we agree conventions etc before much more work is done?) >> >> Thanks >> Sharan >> > > -- logoNrd <http://nereide.fr/> Pierre GAUDIN Consultant Fonctionnel Apache-OFBiz, ERP en logiciel Libre [hidden email] 8 rue des Déportés 37000 TOURS Std: 02 47 50 30 54 - mob: 06 08 40 25 70 ofbiz-fr <http://www.ofbiz-fr.org/> | réseau LE <http://www.libre-entreprise.org/> |
Free forum by Nabble | Edit this page |