Wicket in OFBiz
Locked
 
Administrator
|
Hi devs,
James yong submitted a patch (simple enough to be quickly read) proposing to introduce Wicket as an OFBiz framework component. I's be interested to read your comments about pros and cons Note the urlrewrite stuff... One cons I see is maintenance... (We will see if James is still around, he created the Jira issue in August) Thanks Jacques |
|
Hi Jacques,
Ok, I agree one con about it, is maintenance. The reason is because the screen renderer in OFBiz is tightly coupled with the screen definition. Since this implementation is a quick hack, I go with the easier way of coding the screen content in java instead of using the screen definition way. It will be good if OFbiz add a layer of POJOs between screen widgets and the renderer. Hope I am clear. Regards, james
|
|
Administrator
|
James,
It's quite clear, and IMO you did an excellent and interesting work. Unfortunately, I don't know if we will find enough interest in the community to commit your patch. Mostly because it's a bit redundant and not exactly in the spirit of OFBiz (less compilations and reboots). BTW why was the reason you created this component (apart that maybe you are a huge fan of wicket ;o), did you miss something in OFBiz? Thanks Jacques From: "james_sg" <[hidden email]> > Hi Jacques, > > Ok, I agree one con about it, is maintenance. > > The reason is because the screen renderer in OFBiz is tightly coupled with > the screen definition. > Since this implementation is a quick hack, I go with the easier way of > coding the screen content in java instead of using the screen definition > way. > > It will be good if OFbiz add a layer of POJOs between screen widgets and the > renderer. > > Hope I am clear. > > Regards, > james > > > Jacques Le Roux wrote: >> >> Hi devs, >> >> James yong submitted a patch (simple enough to be quickly read) proposing >> to introduce Wicket as an OFBiz framework component. I's >> be interested to read your comments about pros and cons >> Note the urlrewrite stuff... >> >> One cons I see is maintenance... (We will see if James is still around, he >> created the Jira issue in August) >> >> Thanks >> >> Jacques >> >> >> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
|
|
Hi Jacques,
Let me put it another way. I don't think this patch is good as it doesn't reuse the screen definition. Before any improvement can be made to use the screen definition, OFBiz should understand why a layer of POJOs should exist between the screen definition and renderers. Why this component? My client handles numerous orders each day. Each order have hundreds of items. Their existing desktop based ERP system supports the order clerks with that requirement efficiently. Now they want to move to web-based. Many OFBiz's forms are based on the tables instead of business objects. This mean the user have to click here and there in order to edit the forms. More clicking means less efficiency. This component was quickly put up so that I can rework the code to support forms based on business object. That means having the request header, request items etc on the same screen. Regards, James
|
|
|
In reply to this post by Jacques Le Roux
On Mon, Jan 24, 2011 at 12:57 PM, Jacques Le Roux <
[hidden email]> wrote: > Hi devs, > > James yong submitted a patch (simple enough to be quickly read) proposing > to introduce Wicket as an OFBiz framework component. I's be interested to > read your comments about pros and cons > Note the urlrewrite stuff... > > One cons I see is maintenance... (We will see if James is still around, he > created the Jira issue in August) > I tried that patch, it is working and demonstrates an interesting way to use wicket as ofbiz frontend, but it is kind of a hack. I don't think it would be useful at its current stage to the community. For now we use jira for this kind of POC code, but I think there the code dies after some time. May be it is a good idea to have a branch in svn for stuff like this: code that is not complete enough to go in example component or special purpose folder but still valuable as POC or starting point. GWT patch is another similar candidate for it, but it is currently part of googlecode. Regards, Bilgin Ibryam |
|
Administrator
|
In reply to this post by james_sg
James,
Inline ... From: "james_sg" <[hidden email]> > Hi Jacques, > > Let me put it another way. I don't think this patch is good as it doesn't > reuse the screen definition. > Before any improvement can be made to use the screen definition, OFBiz > should understand why a layer of POJOs should exist between the screen > definition and renderers. So why a layer of POJOs should exist? It seems we don't need them internally. You mean to be able to reuse the screen definitions using Wicket? > Why this component? > > My client handles numerous orders each day. Each order have hundreds of > items. Their existing desktop based ERP system supports the order clerks > with that requirement efficiently. Now they want to move to web-based. > > Many OFBiz's forms are based on the tables instead of business objects. This > mean the user have to click here and there in order to edit the forms. More > clicking means less efficiency. I don't get it. What is the difference between "the tables" (what are the tables?) and the "business objects" (what are the business objects?) > This component was quickly put up so that I can rework the code to support > forms based on business object. That means having the request header, > request items etc on the same screen. If I get it right you need to have the order/request header and items on the same screen (makes sense in your case). Why not create your own screen(s) with OFBiz widgets? Did you need to interface with existing code+data? Jacques > Regards, > James > > > Jacques Le Roux wrote: >> >> James, >> >> It's quite clear, and IMO you did an excellent and interesting work. >> Unfortunately, I don't know if we will find enough interest in >> the community to commit your patch. Mostly because it's a bit redundant >> and not exactly in the spirit of OFBiz (less compilations >> and reboots). >> >> BTW why was the reason you created this component (apart that maybe you >> are a huge fan of wicket ;o), did you miss something in >> OFBiz? >> >> Thanks >> >> Jacques >> >> From: "james_sg" <[hidden email]> >>> Hi Jacques, >>> >>> Ok, I agree one con about it, is maintenance. >>> >>> The reason is because the screen renderer in OFBiz is tightly coupled >>> with >>> the screen definition. >>> Since this implementation is a quick hack, I go with the easier way of >>> coding the screen content in java instead of using the screen definition >>> way. >>> >>> It will be good if OFbiz add a layer of POJOs between screen widgets and >>> the >>> renderer. >>> >>> Hope I am clear. >>> >>> Regards, >>> james >>> >>> >>> Jacques Le Roux wrote: >>>> >>>> Hi devs, >>>> >>>> James yong submitted a patch (simple enough to be quickly read) >>>> proposing >>>> to introduce Wicket as an OFBiz framework component. I's >>>> be interested to read your comments about pros and cons >>>> Note the urlrewrite stuff... >>>> >>>> One cons I see is maintenance... (We will see if James is still around, >>>> he >>>> created the Jira issue in August) >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> >> >> >> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
|
Administrator
|
In reply to this post by Bilgin Ibryam-2
From: "Bilgin Ibryam" <[hidden email]>
> On Mon, Jan 24, 2011 at 12:57 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Hi devs, >> >> James yong submitted a patch (simple enough to be quickly read) proposing >> to introduce Wicket as an OFBiz framework component. I's be interested to >> read your comments about pros and cons >> Note the urlrewrite stuff... >> >> One cons I see is maintenance... (We will see if James is still around, he >> created the Jira issue in August) >> > > I tried that patch, it is working and demonstrates an interesting way to use > wicket as ofbiz frontend, but it is kind of a hack. > I don't think it would be useful at its current stage to the community. > > For now we use jira for this kind of POC code, but I think there the code > dies after some time. > May be it is a good idea to have a branch in svn for stuff like this: code > that is not complete enough to go in example component or special purpose > folder but still valuable as POC or starting point. GWT patch is another > similar candidate for it, but it is currently part of googlecode. I'd agree, but then we need (at least) someone to take care of that branch... Maybe it's easier to have them in GitHub, GoogleCode, etc. as they can be handled from outside. And create a mechanism to relate them from there, until we finally decide to integrate them. It could be as simple as an information that it exists there, at least to begin. But from my experience, therey really need to raise some interest else they will never be integrated in OFBiz. So that 1st phase is more important, to qualify OFBiz devs interest. Some are using other ways (Opentaps, Neogia, Langhua, etc.) Jacques > Regards, > Bilgin Ibryam > |
|
|
In reply to this post by james_sg
James, There is a difference between the design of a screen and the tools used to implement it. The generic screens in OFBiz in the business applications layer are meant to be just that: generic. They are not designed around any particular business process because there are SO many different possible business processes, and the more unique yours is, the greater the chance that custom screens will be required to meet the needs of your intended users. This is not rare for OFBiz, or for business applications in general. In fact, this is EXACTLY the situation that the OFBiz framework, and many of the generic business application artifacts, are meant for. These sorts of generic screens are far easier to reuse than very custom screens would be, and depending on your needs some may be far easier than building screens from scratch (ie from just data model and services). What you are proposing is a layer of Java objects to represent the data model, and a tool (Wicket) to use Java objects to represent the UI. That is a preference for Java objects, it is just a different technology. It has nothing to do with what the resulting UI will be like... that is simply a result of designing what you want, and then implementing it. In other words, technology bias has little to do with user interface design. If you give the OFBiz framework a chance as-is I'm sure you'll find that what you develop will be better organized, easier to maintain, and the artifacts will be easier to reuse. This is even more true with a certain next generation framework (www.moqui.org) that is based on many ideas in the OFBiz framework, but with a number of key differences and in general totally rethought and rewritten. Either way, the approach is not object-oriented for the business-level artifacts. That is intentional. Objects are great for implementing certain things, but for business development it tends to result in massive amounts of poorly organized and highly redundant code. This seems to be more true the larger the team gets, and is true even when writing things that extend OFBiz when the recommended tools and practices are not used. One extreme example of this I've seen is a case where over 500,000 lines of Java were written, just for an ecommerce application with around 20 screens. The bulk of the problem was that there were 100 developers who were given license to develop in their preferred way and few of them learned about the tools and practices and reusable artifacts that could save them time and money. So yes, you'll find bias against object-mapping here. What's the point in mapping everything to objects, especially things that do not naturally have an object-like structure? Why do object-relational mapping, object-service mapping, object-html mapping, object-everything mapping when you could just use the relational, service, html, etc concepts more directly? And yes, that concept applies no matter what kind of fancy clothing you try to put on that pig. By fancy clothing I mean things like annotations, inversion of control, and so on. A pig is a pig, and using objects for everything is inefficient, redundant, self-obfuscating, bloated, messy, and inflexible. -David On Jan 24, 2011, at 9:24 AM, james_sg wrote: > > Hi Jacques, > > Let me put it another way. I don't think this patch is good as it doesn't > reuse the screen definition. > Before any improvement can be made to use the screen definition, OFBiz > should understand why a layer of POJOs should exist between the screen > definition and renderers. > > Why this component? > > My client handles numerous orders each day. Each order have hundreds of > items. Their existing desktop based ERP system supports the order clerks > with that requirement efficiently. Now they want to move to web-based. > > Many OFBiz's forms are based on the tables instead of business objects. This > mean the user have to click here and there in order to edit the forms. More > clicking means less efficiency. > > This component was quickly put up so that I can rework the code to support > forms based on business object. That means having the request header, > request items etc on the same screen. > > Regards, > James > > > Jacques Le Roux wrote: >> >> James, >> >> It's quite clear, and IMO you did an excellent and interesting work. >> Unfortunately, I don't know if we will find enough interest in >> the community to commit your patch. Mostly because it's a bit redundant >> and not exactly in the spirit of OFBiz (less compilations >> and reboots). >> >> BTW why was the reason you created this component (apart that maybe you >> are a huge fan of wicket ;o), did you miss something in >> OFBiz? >> >> Thanks >> >> Jacques >> >> From: "james_sg" <[hidden email]> >>> Hi Jacques, >>> >>> Ok, I agree one con about it, is maintenance. >>> >>> The reason is because the screen renderer in OFBiz is tightly coupled >>> with >>> the screen definition. >>> Since this implementation is a quick hack, I go with the easier way of >>> coding the screen content in java instead of using the screen definition >>> way. >>> >>> It will be good if OFbiz add a layer of POJOs between screen widgets and >>> the >>> renderer. >>> >>> Hope I am clear. >>> >>> Regards, >>> james >>> >>> >>> Jacques Le Roux wrote: >>>> >>>> Hi devs, >>>> >>>> James yong submitted a patch (simple enough to be quickly read) >>>> proposing >>>> to introduce Wicket as an OFBiz framework component. I's >>>> be interested to read your comments about pros and cons >>>> Note the urlrewrite stuff... >>>> >>>> One cons I see is maintenance... (We will see if James is still around, >>>> he >>>> created the Jira issue in August) >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> >> >> >> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
Administrator
|
Thanks David,
It's a long way to convince people Jacques From: "David E Jones" <[hidden email]> > James, > > There is a difference between the design of a screen and the tools used to implement it. The generic screens in OFBiz in the > business applications layer are meant to be just that: generic. They are not designed around any particular business process > because there are SO many different possible business processes, and the more unique yours is, the greater the chance that custom > screens will be required to meet the needs of your intended users. > > This is not rare for OFBiz, or for business applications in general. In fact, this is EXACTLY the situation that the OFBiz > framework, and many of the generic business application artifacts, are meant for. These sorts of generic screens are far easier to > reuse than very custom screens would be, and depending on your needs some may be far easier than building screens from scratch (ie > from just data model and services). > > What you are proposing is a layer of Java objects to represent the data model, and a tool (Wicket) to use Java objects to > represent the UI. That is a preference for Java objects, it is just a different technology. It has nothing to do with what the > resulting UI will be like... that is simply a result of designing what you want, and then implementing it. In other words, > technology bias has little to do with user interface design. > > If you give the OFBiz framework a chance as-is I'm sure you'll find that what you develop will be better organized, easier to > maintain, and the artifacts will be easier to reuse. This is even more true with a certain next generation framework > (www.moqui.org) that is based on many ideas in the OFBiz framework, but with a number of key differences and in general totally > rethought and rewritten. > > Either way, the approach is not object-oriented for the business-level artifacts. That is intentional. Objects are great for > implementing certain things, but for business development it tends to result in massive amounts of poorly organized and highly > redundant code. This seems to be more true the larger the team gets, and is true even when writing things that extend OFBiz when > the recommended tools and practices are not used. One extreme example of this I've seen is a case where over 500,000 lines of Java > were written, just for an ecommerce application with around 20 screens. The bulk of the problem was that there were 100 developers > who were given license to develop in their preferred way and few of them learned about the tools and practices and reusable > artifacts that could save them time and money. > > So yes, you'll find bias against object-mapping here. What's the point in mapping everything to objects, especially things that do > not naturally have an object-like structure? Why do object-relational mapping, object-service mapping, object-html mapping, > object-everything mapping when you could just use the relational, service, html, etc concepts more directly? > > And yes, that concept applies no matter what kind of fancy clothing you try to put on that pig. By fancy clothing I mean things > like annotations, inversion of control, and so on. A pig is a pig, and using objects for everything is inefficient, redundant, > self-obfuscating, bloated, messy, and inflexible. > > -David > > > On Jan 24, 2011, at 9:24 AM, james_sg wrote: > >> >> Hi Jacques, >> >> Let me put it another way. I don't think this patch is good as it doesn't >> reuse the screen definition. >> Before any improvement can be made to use the screen definition, OFBiz >> should understand why a layer of POJOs should exist between the screen >> definition and renderers. >> >> Why this component? >> >> My client handles numerous orders each day. Each order have hundreds of >> items. Their existing desktop based ERP system supports the order clerks >> with that requirement efficiently. Now they want to move to web-based. >> >> Many OFBiz's forms are based on the tables instead of business objects. This >> mean the user have to click here and there in order to edit the forms. More >> clicking means less efficiency. >> >> This component was quickly put up so that I can rework the code to support >> forms based on business object. That means having the request header, >> request items etc on the same screen. >> >> Regards, >> James >> >> >> Jacques Le Roux wrote: >>> >>> James, >>> >>> It's quite clear, and IMO you did an excellent and interesting work. >>> Unfortunately, I don't know if we will find enough interest in >>> the community to commit your patch. Mostly because it's a bit redundant >>> and not exactly in the spirit of OFBiz (less compilations >>> and reboots). >>> >>> BTW why was the reason you created this component (apart that maybe you >>> are a huge fan of wicket ;o), did you miss something in >>> OFBiz? >>> >>> Thanks >>> >>> Jacques >>> >>> From: "james_sg" <[hidden email]> >>>> Hi Jacques, >>>> >>>> Ok, I agree one con about it, is maintenance. >>>> >>>> The reason is because the screen renderer in OFBiz is tightly coupled >>>> with >>>> the screen definition. >>>> Since this implementation is a quick hack, I go with the easier way of >>>> coding the screen content in java instead of using the screen definition >>>> way. >>>> >>>> It will be good if OFbiz add a layer of POJOs between screen widgets and >>>> the >>>> renderer. >>>> >>>> Hope I am clear. >>>> >>>> Regards, >>>> james >>>> >>>> >>>> Jacques Le Roux wrote: >>>>> >>>>> Hi devs, >>>>> >>>>> James yong submitted a patch (simple enough to be quickly read) >>>>> proposing >>>>> to introduce Wicket as an OFBiz framework component. I's >>>>> be interested to read your comments about pros and cons >>>>> Note the urlrewrite stuff... >>>>> >>>>> One cons I see is maintenance... (We will see if James is still around, >>>>> he >>>>> created the Jira issue in August) >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>> >>> >>> >>> >>> >> >> -- >> View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
|
|
That brings up a good question, how could we convince people? -David On Jan 24, 2011, at 2:19 PM, Jacques Le Roux wrote: > Thanks David, > > It's a long way to convince people > > Jacques > > From: "David E Jones" <[hidden email]> >> James, >> >> There is a difference between the design of a screen and the tools used to implement it. The generic screens in OFBiz in the business applications layer are meant to be just that: generic. They are not designed around any particular business process because there are SO many different possible business processes, and the more unique yours is, the greater the chance that custom screens will be required to meet the needs of your intended users. >> >> This is not rare for OFBiz, or for business applications in general. In fact, this is EXACTLY the situation that the OFBiz framework, and many of the generic business application artifacts, are meant for. These sorts of generic screens are far easier to reuse than very custom screens would be, and depending on your needs some may be far easier than building screens from scratch (ie from just data model and services). >> >> What you are proposing is a layer of Java objects to represent the data model, and a tool (Wicket) to use Java objects to represent the UI. That is a preference for Java objects, it is just a different technology. It has nothing to do with what the resulting UI will be like... that is simply a result of designing what you want, and then implementing it. In other words, technology bias has little to do with user interface design. >> >> If you give the OFBiz framework a chance as-is I'm sure you'll find that what you develop will be better organized, easier to maintain, and the artifacts will be easier to reuse. This is even more true with a certain next generation framework (www.moqui.org) that is based on many ideas in the OFBiz framework, but with a number of key differences and in general totally rethought and rewritten. >> >> Either way, the approach is not object-oriented for the business-level artifacts. That is intentional. Objects are great for implementing certain things, but for business development it tends to result in massive amounts of poorly organized and highly redundant code. This seems to be more true the larger the team gets, and is true even when writing things that extend OFBiz when the recommended tools and practices are not used. One extreme example of this I've seen is a case where over 500,000 lines of Java were written, just for an ecommerce application with around 20 screens. The bulk of the problem was that there were 100 developers who were given license to develop in their preferred way and few of them learned about the tools and practices and reusable artifacts that could save them time and money. >> >> So yes, you'll find bias against object-mapping here. What's the point in mapping everything to objects, especially things that do not naturally have an object-like structure? Why do object-relational mapping, object-service mapping, object-html mapping, object-everything mapping when you could just use the relational, service, html, etc concepts more directly? >> >> And yes, that concept applies no matter what kind of fancy clothing you try to put on that pig. By fancy clothing I mean things like annotations, inversion of control, and so on. A pig is a pig, and using objects for everything is inefficient, redundant, self-obfuscating, bloated, messy, and inflexible. >> >> -David >> >> >> On Jan 24, 2011, at 9:24 AM, james_sg wrote: >> >>> >>> Hi Jacques, >>> >>> Let me put it another way. I don't think this patch is good as it doesn't >>> reuse the screen definition. >>> Before any improvement can be made to use the screen definition, OFBiz >>> should understand why a layer of POJOs should exist between the screen >>> definition and renderers. >>> >>> Why this component? >>> >>> My client handles numerous orders each day. Each order have hundreds of >>> items. Their existing desktop based ERP system supports the order clerks >>> with that requirement efficiently. Now they want to move to web-based. >>> >>> Many OFBiz's forms are based on the tables instead of business objects. This >>> mean the user have to click here and there in order to edit the forms. More >>> clicking means less efficiency. >>> >>> This component was quickly put up so that I can rework the code to support >>> forms based on business object. That means having the request header, >>> request items etc on the same screen. >>> >>> Regards, >>> James >>> >>> >>> Jacques Le Roux wrote: >>>> >>>> James, >>>> >>>> It's quite clear, and IMO you did an excellent and interesting work. >>>> Unfortunately, I don't know if we will find enough interest in >>>> the community to commit your patch. Mostly because it's a bit redundant >>>> and not exactly in the spirit of OFBiz (less compilations >>>> and reboots). >>>> >>>> BTW why was the reason you created this component (apart that maybe you >>>> are a huge fan of wicket ;o), did you miss something in >>>> OFBiz? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> From: "james_sg" <[hidden email]> >>>>> Hi Jacques, >>>>> >>>>> Ok, I agree one con about it, is maintenance. >>>>> >>>>> The reason is because the screen renderer in OFBiz is tightly coupled >>>>> with >>>>> the screen definition. >>>>> Since this implementation is a quick hack, I go with the easier way of >>>>> coding the screen content in java instead of using the screen definition >>>>> way. >>>>> >>>>> It will be good if OFbiz add a layer of POJOs between screen widgets and >>>>> the >>>>> renderer. >>>>> >>>>> Hope I am clear. >>>>> >>>>> Regards, >>>>> james >>>>> >>>>> >>>>> Jacques Le Roux wrote: >>>>>> >>>>>> Hi devs, >>>>>> >>>>>> James yong submitted a patch (simple enough to be quickly read) >>>>>> proposing >>>>>> to introduce Wicket as an OFBiz framework component. I's >>>>>> be interested to read your comments about pros and cons >>>>>> Note the urlrewrite stuff... >>>>>> >>>>>> One cons I see is maintenance... (We will see if James is still around, >>>>>> he >>>>>> created the Jira issue in August) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. > > |
|
Administrator
|
David: I think I will thought about that, it's a real good question! I think, with a bit of sweetener, your answer below is a good
start. We could discuss it, enhance it and put it as an explanation on the OFBiz main page: *Why OFBiz ?*. It should not be too long, it's always harder to say more with lesser words. Anyway, for the moment I will spleep on it. That's also why I put my last efforts in jQuery. For me, at the moment, the better way to improve OFBiz UI is still through such tools (javascript frameworks, jQuery being the easier to use IMO). This because, I don't want to be too far from the real code underneath. I don't, I have never trusted (so far), generators and such (GWT, etc.). One day though, we will maybe have enough power and perhaps they will be sufficiently smart and reliable, for the moment they are still too much verbose for me... But all is stale because it's always commercial powers struggling below (sometimes very well hidden), so it's like building on sand. We are still in this crasy period, or at least still feeling its madness. James: this said, though I think we don't really need it in OFBiz, Apache Wicket is also nice by itself. I was trying to understand, why you needed it. I thought you had maybe to reuse legacy code in OFBiz and found a good way with Wicket. Jacques David E Jones wrote: > That brings up a good question, how could we convince people? > > -David > > > On Jan 24, 2011, at 2:19 PM, Jacques Le Roux wrote: > >> Thanks David, >> >> It's a long way to convince people >> >> Jacques >> >> From: "David E Jones" <[hidden email]> >>> James, >>> >>> There is a difference between the design of a screen and the tools used to implement it. The generic screens in OFBiz in the >>> business applications layer are meant to be just that: generic. They are not designed around any particular business process >>> because there are SO many different possible business processes, and the more unique yours is, the greater the chance that >>> custom screens will be required to meet the needs of your intended users. >>> >>> This is not rare for OFBiz, or for business applications in general. In fact, this is EXACTLY the situation that the OFBiz >>> framework, and many of the generic business application artifacts, are meant for. These sorts of generic screens are far easier >>> to reuse than very custom screens would be, and depending on your needs some may be far easier than building screens from >>> scratch (ie from just data model and services). >>> >>> What you are proposing is a layer of Java objects to represent the data model, and a tool (Wicket) to use Java objects to >>> represent the UI. That is a preference for Java objects, it is just a different technology. It has nothing to do with what the >>> resulting UI will be like... that is simply a result of designing what you want, and then implementing it. In other words, >>> technology bias has little to do with user interface design. >>> >>> If you give the OFBiz framework a chance as-is I'm sure you'll find that what you develop will be better organized, easier to >>> maintain, and the artifacts will be easier to reuse. This is even more true with a certain next generation framework >>> (www.moqui.org) that is based on many ideas in the OFBiz framework, but with a number of key differences and in general totally >>> rethought and rewritten. >>> >>> Either way, the approach is not object-oriented for the business-level artifacts. That is intentional. Objects are great for >>> implementing certain things, but for business development it tends to result in massive amounts of poorly organized and highly >>> redundant code. This seems to be more true the larger the team gets, and is true even when writing things that extend OFBiz >>> when the recommended tools and practices are not used. One extreme example of this I've seen is a case where over 500,000 lines >>> of Java were written, just for an ecommerce application with around 20 screens. The bulk of the problem was that there were 100 >>> developers who were given license to develop in their preferred way and few of them learned about the tools and practices and >>> reusable artifacts that could save them time and money. >>> >>> So yes, you'll find bias against object-mapping here. What's the point in mapping everything to objects, especially things that >>> do not naturally have an object-like structure? Why do object-relational mapping, object-service mapping, object-html mapping, >>> object-everything mapping when you could just use the relational, service, html, etc concepts more directly? >>> >>> And yes, that concept applies no matter what kind of fancy clothing you try to put on that pig. By fancy clothing I mean things >>> like annotations, inversion of control, and so on. A pig is a pig, and using objects for everything is inefficient, redundant, >>> self-obfuscating, bloated, messy, and inflexible. >>> >>> -David >>> >>> >>> On Jan 24, 2011, at 9:24 AM, james_sg wrote: >>> >>>> >>>> Hi Jacques, >>>> >>>> Let me put it another way. I don't think this patch is good as it doesn't >>>> reuse the screen definition. >>>> Before any improvement can be made to use the screen definition, OFBiz >>>> should understand why a layer of POJOs should exist between the screen >>>> definition and renderers. >>>> >>>> Why this component? >>>> >>>> My client handles numerous orders each day. Each order have hundreds of >>>> items. Their existing desktop based ERP system supports the order clerks >>>> with that requirement efficiently. Now they want to move to web-based. >>>> >>>> Many OFBiz's forms are based on the tables instead of business objects. This >>>> mean the user have to click here and there in order to edit the forms. More >>>> clicking means less efficiency. >>>> >>>> This component was quickly put up so that I can rework the code to support >>>> forms based on business object. That means having the request header, >>>> request items etc on the same screen. >>>> >>>> Regards, >>>> James >>>> >>>> >>>> Jacques Le Roux wrote: >>>>> >>>>> James, >>>>> >>>>> It's quite clear, and IMO you did an excellent and interesting work. >>>>> Unfortunately, I don't know if we will find enough interest in >>>>> the community to commit your patch. Mostly because it's a bit redundant >>>>> and not exactly in the spirit of OFBiz (less compilations >>>>> and reboots). >>>>> >>>>> BTW why was the reason you created this component (apart that maybe you >>>>> are a huge fan of wicket ;o), did you miss something in >>>>> OFBiz? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> From: "james_sg" <[hidden email]> >>>>>> Hi Jacques, >>>>>> >>>>>> Ok, I agree one con about it, is maintenance. >>>>>> >>>>>> The reason is because the screen renderer in OFBiz is tightly coupled >>>>>> with >>>>>> the screen definition. >>>>>> Since this implementation is a quick hack, I go with the easier way of >>>>>> coding the screen content in java instead of using the screen definition >>>>>> way. >>>>>> >>>>>> It will be good if OFbiz add a layer of POJOs between screen widgets and >>>>>> the >>>>>> renderer. >>>>>> >>>>>> Hope I am clear. >>>>>> >>>>>> Regards, >>>>>> james >>>>>> >>>>>> >>>>>> Jacques Le Roux wrote: >>>>>>> >>>>>>> Hi devs, >>>>>>> >>>>>>> James yong submitted a patch (simple enough to be quickly read) >>>>>>> proposing >>>>>>> to introduce Wicket as an OFBiz framework component. I's >>>>>>> be interested to read your comments about pros and cons >>>>>>> Note the urlrewrite stuff... >>>>>>> >>>>>>> One cons I see is maintenance... (We will see if James is still around, >>>>>>> he >>>>>>> created the Jira issue in August) >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html >>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
|
In reply to this post by Jacques Le Roux
Hi Jacques,
Wicket component aside, I am proposing reading screen xml definitions and store this information as POJOs in an object oriented way. When this is done, existing or new renderer (like wicket) can read from the POJOs, without knowledge on how the screen definition is represented. Currently I need to click around the pages to add / modifiy data, because the pages tends to follow the tables design (form is mapped to only one table ) rather than at business level (form is mapped to several tables ). I didn't use OFBiz widget because the user wants to create or edit the header and items information in one screen before saving them in one go. Currently, OFBiz widget also doesn't natively support changing part of the form according to what the user selects. Regards, James
|
|
|
On Jan 24, 2011, at 6:06 PM, james_sg wrote: > I didn't use OFBiz widget because the user wants to create or edit the > header and items information in one screen before saving them in one go. Actually, it does support that. I've even done screens with multiple forms (single and tabular) all submitted together as one big form. > Currently, OFBiz widget also doesn't natively support changing part of the > form according to what the user selects. Could you be more specific, ie what does this mean? -David |
|
|
Hi all,
To illustrate my point, i have attached a screenshot of an order form in edit mode. Items can be added, updated or removed before saving. Users do not need to click around the different forms to create/edit an order.  Regards, James
|
|
|
Is that an example of something you built with Wicket, or what was it built with? It's a nice complex form, and might be a pain to build with the form widget, but why not just use an FTL template? -David On Jan 24, 2011, at 7:58 PM, james_sg wrote: > > Hi all, > > To illustrate my point, i have attached a screenshot of an order form in > edit mode. Items can be added, updated or removed before saving. Users do > not need to click around the different forms to create/edit an order. > > http://ofbiz.135035.n4.nabble.com/file/n3235394/Image2.jpg > > Regards, > James > > > David E Jones-4 wrote: >> >> >> On Jan 24, 2011, at 6:06 PM, james_sg wrote: >> >>> I didn't use OFBiz widget because the user wants to create or edit the >>> header and items information in one screen before saving them in one go. >> >> Actually, it does support that. I've even done screens with multiple forms >> (single and tabular) all submitted together as one big form. >> >>> Currently, OFBiz widget also doesn't natively support changing part of >>> the >>> form according to what the user selects. >> >> Could you be more specific, ie what does this mean? >> >> -David >> >> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3235394.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
Administrator
|
In reply to this post by james_sg
From: "james_sg" <[hidden email]>
> Hi Jacques, > > Wicket component aside, I am proposing reading screen xml definitions and > store this information as POJOs in an object oriented way. When this is > done, existing or new renderer (like wicket) can read from the POJOs, > without knowledge on how the screen definition is represented. > > Currently I need to click around the pages to add / modifiy data, because > the pages tends to follow the tables design (form is mapped to only one > table ) rather than at business level (form is mapped to several tables ). > > I didn't use OFBiz widget because the user wants to create or edit the > header and items information in one screen before saving them in one go. > Currently, OFBiz widget also doesn't natively support changing part of the > form according to what the user selects. Like David said it's possible using skip-start, skip-end and hide-header (sometimes hard). But the real question David already asked: why not Groovy/FTL couple then? You can do anything you want with it, if needed add a big of js/Ajax, et voilà. There are many examples in OFBiz as well. Jacques > Regards, > James > > > Jacques Le Roux wrote: >> >> James, >> >> Inline ... >> >> From: "james_sg" <[hidden email]> >>> Hi Jacques, >>> >>> Let me put it another way. I don't think this patch is good as it doesn't >>> reuse the screen definition. >>> Before any improvement can be made to use the screen definition, OFBiz >>> should understand why a layer of POJOs should exist between the screen >>> definition and renderers. >> >> So why a layer of POJOs should exist? It seems we don't need them >> internally. You mean to be able to reuse the screen definitions >> using Wicket? >> >>> Why this component? >>> >>> My client handles numerous orders each day. Each order have hundreds of >>> items. Their existing desktop based ERP system supports the order clerks >>> with that requirement efficiently. Now they want to move to web-based. >>> >>> Many OFBiz's forms are based on the tables instead of business objects. >>> This >>> mean the user have to click here and there in order to edit the forms. >>> More >>> clicking means less efficiency. >> >> I don't get it. What is the difference between "the tables" (what are the >> tables?) and the "business objects" (what are the business >> objects?) >> >>> This component was quickly put up so that I can rework the code to >>> support >>> forms based on business object. That means having the request header, >>> request items etc on the same screen. >> >> If I get it right you need to have the order/request header and items on >> the same screen (makes sense in your case). Why not create >> your own screen(s) with OFBiz widgets? Did you need to interface with >> existing code+data? >> >> Jacques >> >>> Regards, >>> James >>> >>> >>> Jacques Le Roux wrote: >>>> >>>> James, >>>> >>>> It's quite clear, and IMO you did an excellent and interesting work. >>>> Unfortunately, I don't know if we will find enough interest in >>>> the community to commit your patch. Mostly because it's a bit redundant >>>> and not exactly in the spirit of OFBiz (less compilations >>>> and reboots). >>>> >>>> BTW why was the reason you created this component (apart that maybe you >>>> are a huge fan of wicket ;o), did you miss something in >>>> OFBiz? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> From: "james_sg" <[hidden email]> >>>>> Hi Jacques, >>>>> >>>>> Ok, I agree one con about it, is maintenance. >>>>> >>>>> The reason is because the screen renderer in OFBiz is tightly coupled >>>>> with >>>>> the screen definition. >>>>> Since this implementation is a quick hack, I go with the easier way of >>>>> coding the screen content in java instead of using the screen >>>>> definition >>>>> way. >>>>> >>>>> It will be good if OFbiz add a layer of POJOs between screen widgets >>>>> and >>>>> the >>>>> renderer. >>>>> >>>>> Hope I am clear. >>>>> >>>>> Regards, >>>>> james >>>>> >>>>> >>>>> Jacques Le Roux wrote: >>>>>> >>>>>> Hi devs, >>>>>> >>>>>> James yong submitted a patch (simple enough to be quickly read) >>>>>> proposing >>>>>> to introduce Wicket as an OFBiz framework component. I's >>>>>> be interested to read your comments about pros and cons >>>>>> Note the urlrewrite stuff... >>>>>> >>>>>> One cons I see is maintenance... (We will see if James is still >>>>>> around, >>>>>> he >>>>>> created the Jira issue in August) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html >>>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> >> >> >> >> > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3235305.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
|
|
In reply to this post by David E. Jones-2
Hi David,
Yes, that example is built with the Wicket component. The reason why I didn't use FTL is the same reason why people uses GWT, Wicket etc., than coding directly with javascript library. Regards, James
|
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |