General questions
Locked
123
123
 
|
Cedric,
I get the same impression as Adrian too. Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too. Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case. While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main . In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang. I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow. For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users. If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated. Hope you enjoy OFBiz as much as I have. :) Jonathon Adrian Crum wrote: > Cedric, > > I might be wrong, but I get the impression you are trying to approach > OFBiz from the bottom up (examining java classes versus examining > higher-level layers). I made that mistake when I first got involved with > OFBiz. > > It would be better to look at things like the service engine, entity > engine, screen widgets, etc. Get an idea of how the presentation layer > works, then work your way down to the service layer, then down to the > database schema, etc. > > Typically, the only reason anyone would want to get into the java source > would be to fix a bug or make a modification at a very low level of the > architecture "stack." > > > > PRONZATO Cedric RD-BIZZ-GRE wrote: > >> Re, >> >> Yes you are true but I think I didn't explained myself. >> These questions may have been answered in the javadocs. I am sure you >> know (you that architects of OFBiz) why you decided to make a >> Container class and so on. >> So perhaps a little enhancement of javadoc on foundation classes to >> explain why and where to use it would be so nice. >> >> I hope I do not look like too much arrogant with my questions on that >> thread "General questions"; I just expose the problems I was faced to. >> >> Regards, >> Cédric >> >> -----Message d'origine----- >> De : David E. Jones [mailto:[hidden email]] Envoyé : vendredi >> 9 février 2007 18:12 >> À : [hidden email] >> Objet : Re: General questions >> >> >> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >> >> >>> A related problem is how to do "framework" components, I mean >>> patterns. I think about my SMSC component, I base my code on the mail >>> container and questions arised: >>> - When do I have to make my own xml language (ie. MCA for the mail >>> container)? >>> - When do I have to make a Container? I guess the answer is if you >>> have to manage the lifetime (create/release connections, ...). >>> - When do I have to make an Engine? >>> - ... >>> >>> So I guess we can finish with the following statement: "How to >>> *use* is quite well documented but how to *make* is a bit less". >> >> >> Have you ever found such a document for anything? >> >> My usual approach is generally something like: >> >> 1. understand everything that exists, or research anything that is >> unclear 2. write something manually a number of times so you know what >> is always the same, and what varies 3. see if a paramerized tool would >> be helpful 4. apply a significant amount of "genius" >> 5. apply even more "sweat" to try stuff >> 6. create an incredible tool or service or however it is best implemented >> >> If there was a way to make creation deterministic, what would be the >> point of creativity? >> >> -David >> >> > |
Administrator
|
In reply to this post by cjhowe
Chris,
> I'm shocked Jacques, this is a perfect opportunity to plug Mylar :-) Mylar is great, but I'm not sure it would be useful in what Cedric wants to achieve :p Either I'm no sure to have clearly understood what he tries to achieve, so perhaps you are right ;o) Jacques |
RE: General questions
|
|
In reply to this post by jonwimp
Hi all,
Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :) My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment. Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part. Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...) So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much. Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =) I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned. I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ... Thank you all, Regards, Cédric -----Message d'origine----- De : Jonathon -- Improov [mailto:[hidden email]] Envoyé : vendredi 9 février 2007 20:12 À : [hidden email] Objet : Re: General questions Cedric, I get the same impression as Adrian too. Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too. Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case. While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main . In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang. I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow. For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users. If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated. Hope you enjoy OFBiz as much as I have. :) Jonathon Adrian Crum wrote: > Cedric, > > I might be wrong, but I get the impression you are trying to approach > OFBiz from the bottom up (examining java classes versus examining > higher-level layers). I made that mistake when I first got involved > with OFBiz. > > It would be better to look at things like the service engine, entity > engine, screen widgets, etc. Get an idea of how the presentation layer > works, then work your way down to the service layer, then down to the > database schema, etc. > > Typically, the only reason anyone would want to get into the java > source would be to fix a bug or make a modification at a very low > level of the architecture "stack." > > > > PRONZATO Cedric RD-BIZZ-GRE wrote: > >> Re, >> >> Yes you are true but I think I didn't explained myself. >> These questions may have been answered in the javadocs. I am sure you >> know (you that architects of OFBiz) why you decided to make a >> Container class and so on. >> So perhaps a little enhancement of javadoc on foundation classes to >> explain why and where to use it would be so nice. >> >> I hope I do not look like too much arrogant with my questions on that >> thread "General questions"; I just expose the problems I was faced to. >> >> Regards, >> Cédric >> >> -----Message d'origine----- >> De : David E. Jones [mailto:[hidden email]] Envoyé : >> vendredi >> 9 février 2007 18:12 >> À : [hidden email] >> Objet : Re: General questions >> >> >> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >> >> >>> A related problem is how to do "framework" components, I mean >>> patterns. I think about my SMSC component, I base my code on the >>> mail container and questions arised: >>> - When do I have to make my own xml language (ie. MCA for the mail >>> container)? >>> - When do I have to make a Container? I guess the answer is if you >>> have to manage the lifetime (create/release connections, ...). >>> - When do I have to make an Engine? >>> - ... >>> >>> So I guess we can finish with the following statement: "How to >>> *use* is quite well documented but how to *make* is a bit less". >> >> >> Have you ever found such a document for anything? >> >> My usual approach is generally something like: >> >> 1. understand everything that exists, or research anything that is >> unclear 2. write something manually a number of times so you know >> what is always the same, and what varies 3. see if a paramerized tool >> would be helpful 4. apply a significant amount of "genius" >> 5. apply even more "sweat" to try stuff 6. create an incredible tool >> or service or however it is best implemented >> >> If there was a way to make creation deterministic, what would be the >> point of creativity? >> >> -David >> >> > |
|
|
Please be thanked to read into details of my 2 cents
We all are from R&D teams. Can we pool up resources to add few stuff to OFbiz. I agree challenge with ofbiz it was ahead of time but "Open Source Changes Everything". Things / Ideas I want to add to ofbiz (1) C-JDBC drivers. --- I know it is LPGL. I want to understand the benefits of C-JDBC if add to the mix (2) OpenTerracotta --- For seamless clustering if possible. http://www.terracotta.org/confluence/display/orgsite/Download Note : Lots of open source uses struts ; spring. They keep adding to the established Open source as value add. Any pointers of usefullness of (1) and (2) and how much it can add to performance. Chand ----- Original Message ----- From: "PRONZATO Cedric RD-BIZZ-GRE" <[hidden email]> To: <[hidden email]> Sent: Monday, February 12, 2007 1:07 AM Subject: RE: General questions > Hi all, > > Yes, you are all true! My approach is bottom-up learning. All of you here > seem to read in me like an opened book; I now know that OFBiz is a > training area for FBI Profilers. :) > > My aim (I think) was to fully understand the framework to be able to > change/replace/add new *core* functionalities and test them in a real > ecommerce environment. > Yet I never played with 'call to a service' or so as the documents about > that was enough clear. I said: All should be OK on this part. > Entity engine and Service engine are clear and in respect of all the > common and trusted laws of java development. (By the way is there any plan > to turn to the new standards? OFBiz was in advance in 2000 but now much > developer well knows Spring just to name one ...) > So after these 2 majors things there are questions about the use of > screen/form widgets and Beanshell/minilang. I am not well experienced but > I don't know if developers will like to learn these new things instead of > working with what they know. So I decided to not investigate it much. > > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you > much things because you are more experienced than me =) > I will check about what I am allowed to do with my company policy but I am > confidant as OFBiz is a personal choice not too much tied to a project > need. I stay you tuned. > > I now have to think about what is wrong on this approach, think about what > is the next thing I have to investigate ... > > Thank you all, > Regards, > Cédric > > -----Message d'origine----- > De : Jonathon -- Improov [mailto:[hidden email]] > Envoyé : vendredi 9 février 2007 20:12 > À : [hidden email] > Objet : Re: General questions > > Cedric, > > I get the same impression as Adrian too. > > Since you're from the R&D department, I suppose you're as much of a freak > as I am. I took apart OFBiz at the source code level too. > > Unless you're employing some language-processing heuristics in your > reverse-engineering, you'll be spending way too much time doing > brute-force studies from the bottom-up. Better to just learn from playing > with OFBiz framework (not the framework source codes), such as service > engine and entity engine, in this case. > > While it is true that learning by playing with the framework will > certainly be faster, I do admit it is not as easy as many would hope. > Technical references for working the OFBiz framework are not all in one > place, or even complete (mostly still in form of cookbooks at the moment). > Ie, there are no "javadocs equivalent" for the OFBiz framework, except at > http://www.undersunconsulting.com/ecommerce/control/main . > > In fact, some folks here have never gotten around to using all of the > OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some > use Beanshell rather than Minilang. > > I guess what I'm trying to say is this. Since you're from the R&D > department, it would be "within your scope" to learn the OFBiz framework > in any way possible, such as from studying the source codes or playing > with the framework itself. No use complaining what isn't there; better to > get things working somehow. > > For those not from the R&D department, though, then yes I do admit OFBiz > doesn't have a nice polished expensive "welcome mat/carpet" for new users. > > If you do want to get help learning the OFBiz framework, you can either > work with me and write down all that I've discovered through my own > reverse-engineering, or you can employ some of the experts here to teach > you. I'll have to train some staff on OFBiz before I sign off my current > project, so your help here would be much appreciated. > > Hope you enjoy OFBiz as much as I have. :) > > Jonathon > > Adrian Crum wrote: >> Cedric, >> >> I might be wrong, but I get the impression you are trying to approach >> OFBiz from the bottom up (examining java classes versus examining >> higher-level layers). I made that mistake when I first got involved >> with OFBiz. >> >> It would be better to look at things like the service engine, entity >> engine, screen widgets, etc. Get an idea of how the presentation layer >> works, then work your way down to the service layer, then down to the >> database schema, etc. >> >> Typically, the only reason anyone would want to get into the java >> source would be to fix a bug or make a modification at a very low >> level of the architecture "stack." >> >> >> >> PRONZATO Cedric RD-BIZZ-GRE wrote: >> >>> Re, >>> >>> Yes you are true but I think I didn't explained myself. >>> These questions may have been answered in the javadocs. I am sure you >>> know (you that architects of OFBiz) why you decided to make a >>> Container class and so on. >>> So perhaps a little enhancement of javadoc on foundation classes to >>> explain why and where to use it would be so nice. >>> >>> I hope I do not look like too much arrogant with my questions on that >>> thread "General questions"; I just expose the problems I was faced to. >>> >>> Regards, >>> Cédric >>> >>> -----Message d'origine----- >>> De : David E. Jones [mailto:[hidden email]] Envoyé : >>> vendredi >>> 9 février 2007 18:12 >>> À : [hidden email] >>> Objet : Re: General questions >>> >>> >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>> >>> >>>> A related problem is how to do "framework" components, I mean >>>> patterns. I think about my SMSC component, I base my code on the >>>> mail container and questions arised: >>>> - When do I have to make my own xml language (ie. MCA for the mail >>>> container)? >>>> - When do I have to make a Container? I guess the answer is if you >>>> have to manage the lifetime (create/release connections, ...). >>>> - When do I have to make an Engine? >>>> - ... >>>> >>>> So I guess we can finish with the following statement: "How to >>>> *use* is quite well documented but how to *make* is a bit less". >>> >>> >>> Have you ever found such a document for anything? >>> >>> My usual approach is generally something like: >>> >>> 1. understand everything that exists, or research anything that is >>> unclear 2. write something manually a number of times so you know >>> what is always the same, and what varies 3. see if a paramerized tool >>> would be helpful 4. apply a significant amount of "genius" >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool >>> or service or however it is best implemented >>> >>> If there was a way to make creation deterministic, what would be the >>> point of creativity? >>> >>> -David >>> >>> >> > > > |
|
|
On Monday 12 February 2007 09:38, Chandresh Turakhia wrote:
> Please be thanked to read into details of my 2 cents > > We all are from R&D teams. Can we pool up resources to add few stuff to > OFbiz. > > I agree challenge with ofbiz it was ahead of time but "Open Source Changes > Everything". > > Things / Ideas I want to add to ofbiz > > (1) C-JDBC drivers. --- I know it is LPGL. I want to understand the > benefits of C-JDBC if add to the mix JDBC URLs and there are things that C-JDBC does not support that I think OfBiz needs. David > (2) OpenTerracotta --- For seamless clustering if possible. > http://www.terracotta.org/confluence/display/orgsite/Download > > Note : Lots of open source uses struts ; spring. They keep adding to the > established Open source as value add. > > Any pointers of usefullness of (1) and (2) and how much it can add to > performance. > > Chand > > ----- Original Message ----- > From: "PRONZATO Cedric RD-BIZZ-GRE" <[hidden email]> > To: <[hidden email]> > Sent: Monday, February 12, 2007 1:07 AM > Subject: RE: General questions > > > Hi all, > > > > Yes, you are all true! My approach is bottom-up learning. All of you here > > seem to read in me like an opened book; I now know that OFBiz is a > > training area for FBI Profilers. :) > > > > My aim (I think) was to fully understand the framework to be able to > > change/replace/add new *core* functionalities and test them in a real > > ecommerce environment. > > Yet I never played with 'call to a service' or so as the documents about > > that was enough clear. I said: All should be OK on this part. > > Entity engine and Service engine are clear and in respect of all the > > common and trusted laws of java development. (By the way is there any > > plan to turn to the new standards? OFBiz was in advance in 2000 but now > > much developer well knows Spring just to name one ...) > > So after these 2 majors things there are questions about the use of > > screen/form widgets and Beanshell/minilang. I am not well experienced but > > I don't know if developers will like to learn these new things instead of > > working with what they know. So I decided to not investigate it much. > > > > Jonathon, a collaboration? Yes, why not? But I am sure I will not show > > you much things because you are more experienced than me =) > > I will check about what I am allowed to do with my company policy but I > > am confidant as OFBiz is a personal choice not too much tied to a project > > need. I stay you tuned. > > > > I now have to think about what is wrong on this approach, think about > > what is the next thing I have to investigate ... > > > > Thank you all, > > Regards, > > Cédric > > > > -----Message d'origine----- > > De : Jonathon -- Improov [mailto:[hidden email]] > > Envoyé : vendredi 9 février 2007 20:12 > > À : [hidden email] > > Objet : Re: General questions > > > > Cedric, > > > > I get the same impression as Adrian too. > > > > Since you're from the R&D department, I suppose you're as much of a freak > > as I am. I took apart OFBiz at the source code level too. > > > > Unless you're employing some language-processing heuristics in your > > reverse-engineering, you'll be spending way too much time doing > > brute-force studies from the bottom-up. Better to just learn from playing > > with OFBiz framework (not the framework source codes), such as service > > engine and entity engine, in this case. > > > > While it is true that learning by playing with the framework will > > certainly be faster, I do admit it is not as easy as many would hope. > > Technical references for working the OFBiz framework are not all in one > > place, or even complete (mostly still in form of cookbooks at the > > moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, > > except at http://www.undersunconsulting.com/ecommerce/control/main . > > > > In fact, some folks here have never gotten around to using all of the > > OFBiz framework. Some don't use screen/form widgets, but FTL instead. > > Some use Beanshell rather than Minilang. > > > > I guess what I'm trying to say is this. Since you're from the R&D > > department, it would be "within your scope" to learn the OFBiz framework > > in any way possible, such as from studying the source codes or playing > > with the framework itself. No use complaining what isn't there; better to > > get things working somehow. > > > > For those not from the R&D department, though, then yes I do admit OFBiz > > doesn't have a nice polished expensive "welcome mat/carpet" for new > > users. > > > > If you do want to get help learning the OFBiz framework, you can either > > work with me and write down all that I've discovered through my own > > reverse-engineering, or you can employ some of the experts here to teach > > you. I'll have to train some staff on OFBiz before I sign off my current > > project, so your help here would be much appreciated. > > > > Hope you enjoy OFBiz as much as I have. :) > > > > Jonathon > > > > Adrian Crum wrote: > >> Cedric, > >> > >> I might be wrong, but I get the impression you are trying to approach > >> OFBiz from the bottom up (examining java classes versus examining > >> higher-level layers). I made that mistake when I first got involved > >> with OFBiz. > >> > >> It would be better to look at things like the service engine, entity > >> engine, screen widgets, etc. Get an idea of how the presentation layer > >> works, then work your way down to the service layer, then down to the > >> database schema, etc. > >> > >> Typically, the only reason anyone would want to get into the java > >> source would be to fix a bug or make a modification at a very low > >> level of the architecture "stack." > >> > >> PRONZATO Cedric RD-BIZZ-GRE wrote: > >>> Re, > >>> > >>> Yes you are true but I think I didn't explained myself. > >>> These questions may have been answered in the javadocs. I am sure you > >>> know (you that architects of OFBiz) why you decided to make a > >>> Container class and so on. > >>> So perhaps a little enhancement of javadoc on foundation classes to > >>> explain why and where to use it would be so nice. > >>> > >>> I hope I do not look like too much arrogant with my questions on that > >>> thread "General questions"; I just expose the problems I was faced to. > >>> > >>> Regards, > >>> Cédric > >>> > >>> -----Message d'origine----- > >>> De : David E. Jones [mailto:[hidden email]] Envoyé : > >>> vendredi > >>> 9 février 2007 18:12 > >>> À : [hidden email] > >>> Objet : Re: General questions > >>> > >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: > >>>> A related problem is how to do "framework" components, I mean > >>>> patterns. I think about my SMSC component, I base my code on the > >>>> mail container and questions arised: > >>>> - When do I have to make my own xml language (ie. MCA for the mail > >>>> container)? > >>>> - When do I have to make a Container? I guess the answer is if you > >>>> have to manage the lifetime (create/release connections, ...). > >>>> - When do I have to make an Engine? > >>>> - ... > >>>> > >>>> So I guess we can finish with the following statement: "How to > >>>> *use* is quite well documented but how to *make* is a bit less". > >>> > >>> Have you ever found such a document for anything? > >>> > >>> My usual approach is generally something like: > >>> > >>> 1. understand everything that exists, or research anything that is > >>> unclear 2. write something manually a number of times so you know > >>> what is always the same, and what varies 3. see if a paramerized tool > >>> would be helpful 4. apply a significant amount of "genius" > >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool > >>> or service or however it is best implemented > >>> > >>> If there was a way to make creation deterministic, what would be the > >>> point of creativity? > >>> > >>> -David |
|
|
In reply to this post by PRONZATO Cedric RD-BIZZ-GRE
Cedric,
> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you > much things because you are more experienced than me =) I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway). Believe me, OFBiz is easy to pick up. Somewhat exact time requirements (in case your boss asks): 1. 10 minutes to learn structure of OFBiz, so you know how to move around. 2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading OFBiz like an open REFERENCE book. > there are questions about the use of screen/form widgets and > Beanshell/minilang. I am not well experienced but I don't know if developers > will like to learn these new things instead of working with what they know. As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes. But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying criteria to screen volunteers before making them committers; you do get many top brains in open source projects, so good that you/I probably can't ever argue with those). And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never created an open source project myself. Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the time). I'll be sorry if I missed it. Jonathon PRONZATO Cedric RD-BIZZ-GRE wrote: > Hi all, > > Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :) > > My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment. > Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part. > Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...) > So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much. > > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =) > I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned. > > I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ... > > Thank you all, > Regards, > Cédric > > -----Message d'origine----- > De : Jonathon -- Improov [mailto:[hidden email]] > Envoyé : vendredi 9 février 2007 20:12 > À : [hidden email] > Objet : Re: General questions > > Cedric, > > I get the same impression as Adrian too. > > Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too. > > Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case. > > While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main . > > In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang. > > I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow. > > For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users. > > If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated. > > Hope you enjoy OFBiz as much as I have. :) > > Jonathon > > Adrian Crum wrote: >> Cedric, >> >> I might be wrong, but I get the impression you are trying to approach >> OFBiz from the bottom up (examining java classes versus examining >> higher-level layers). I made that mistake when I first got involved >> with OFBiz. >> >> It would be better to look at things like the service engine, entity >> engine, screen widgets, etc. Get an idea of how the presentation layer >> works, then work your way down to the service layer, then down to the >> database schema, etc. >> >> Typically, the only reason anyone would want to get into the java >> source would be to fix a bug or make a modification at a very low >> level of the architecture "stack." >> >> >> >> PRONZATO Cedric RD-BIZZ-GRE wrote: >> >>> Re, >>> >>> Yes you are true but I think I didn't explained myself. >>> These questions may have been answered in the javadocs. I am sure you >>> know (you that architects of OFBiz) why you decided to make a >>> Container class and so on. >>> So perhaps a little enhancement of javadoc on foundation classes to >>> explain why and where to use it would be so nice. >>> >>> I hope I do not look like too much arrogant with my questions on that >>> thread "General questions"; I just expose the problems I was faced to. >>> >>> Regards, >>> Cédric >>> >>> -----Message d'origine----- >>> De : David E. Jones [mailto:[hidden email]] Envoyé : >>> vendredi >>> 9 février 2007 18:12 >>> À : [hidden email] >>> Objet : Re: General questions >>> >>> >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>> >>> >>>> A related problem is how to do "framework" components, I mean >>>> patterns. I think about my SMSC component, I base my code on the >>>> mail container and questions arised: >>>> - When do I have to make my own xml language (ie. MCA for the mail >>>> container)? >>>> - When do I have to make a Container? I guess the answer is if you >>>> have to manage the lifetime (create/release connections, ...). >>>> - When do I have to make an Engine? >>>> - ... >>>> >>>> So I guess we can finish with the following statement: "How to >>>> *use* is quite well documented but how to *make* is a bit less". >>> >>> Have you ever found such a document for anything? >>> >>> My usual approach is generally something like: >>> >>> 1. understand everything that exists, or research anything that is >>> unclear 2. write something manually a number of times so you know >>> what is always the same, and what varies 3. see if a paramerized tool >>> would be helpful 4. apply a significant amount of "genius" >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool >>> or service or however it is best implemented >>> >>> If there was a way to make creation deterministic, what would be the >>> point of creativity? >>> >>> -David >>> >>> > > |
|
|
On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote: > But you could be right. IMHO, the lack of clear OFBiz framework > references (not videos that are unsearchable) may be hindering the > explosive growth of the OFBiz-enabled engineer population. Also > IMHO, an explosion in the number of OFBiz-enabled engineers will > likely feed back into OFBiz very rapidly. And further IMHO, David > Jones (creator of OFBiz) will then probably have a whole army of > willing volunteers to choose from (many open source projects employ > ULTRA STRINGENT qualifying criteria to screen volunteers before > making them committers; you do get many top brains in open source > projects, so good that you/I probably can't ever argue with those). > > And finally, IMHO, I could be entirely wrong in above paragraph. I > am not David Jones; I never created an open source project myself. the Apache license right away. As far as causality goes, knowing about OFBiz is a "necessary" cause for contribution, but not a "sufficient" cause. If knowing about OFBiz was a sufficient cause for heavy involvement in contributing to OFBiz, we would have at least twenty to thirty active (ie daily) committers, and we would probably go through easily 100 Jira issues a week from outside contributors. For an excellent thesis on causality, I recommend "Causality and Chance in Modern Physics" by David Bohm and Louis De Broglie, especially the first few chapters which apply to a good deal other than just physics (though of course honest physics involves a great deal of real life so very little imagination is required to bridge the gap). Actually, that book is more of a philosophy of science book than a book about the results of science. -David |
smime.p7s (3K) |
|
> If this were the only factor I would release those materials under the
> Apache license right away. Agreed. I would've put full muscle behind writing down what I learned about OFBiz. I kinda gave up after dishing out detailed explanations of form/screen widget entities and seeing... zilch in return. > As far as causality goes, knowing about OFBiz is a "necessary" cause for > contribution, but not a "sufficient" cause. If knowing about OFBiz was a > sufficient cause for heavy involvement in contributing to OFBiz, we > would have at least twenty to thirty active (ie daily) committers, and > we would probably go through easily 100 Jira issues a week from outside > contributors. Agreed. Currently, I'm unable to contribute myself due to time constraints (or mad rush for business profit?). After I'm done with my project, I may examine myself and find out why I can/cannot contribute back actively to OFBiz. At least start studying the phenomenon 1 case at a time, starting with myself. Jonathon David E. Jones wrote: > > On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote: > >> But you could be right. IMHO, the lack of clear OFBiz framework >> references (not videos that are unsearchable) may be hindering the >> explosive growth of the OFBiz-enabled engineer population. Also IMHO, >> an explosion in the number of OFBiz-enabled engineers will likely feed >> back into OFBiz very rapidly. And further IMHO, David Jones (creator >> of OFBiz) will then probably have a whole army of willing volunteers >> to choose from (many open source projects employ ULTRA STRINGENT >> qualifying criteria to screen volunteers before making them >> committers; you do get many top brains in open source projects, so >> good that you/I probably can't ever argue with those). >> >> And finally, IMHO, I could be entirely wrong in above paragraph. I am >> not David Jones; I never created an open source project myself. > > If this were the only factor I would release those materials under the > Apache license right away. > > As far as causality goes, knowing about OFBiz is a "necessary" cause for > contribution, but not a "sufficient" cause. If knowing about OFBiz was a > sufficient cause for heavy involvement in contributing to OFBiz, we > would have at least twenty to thirty active (ie daily) committers, and > we would probably go through easily 100 Jira issues a week from outside > contributors. > > For an excellent thesis on causality, I recommend "Causality and Chance > in Modern Physics" by David Bohm and Louis De Broglie, especially the > first few chapters which apply to a good deal other than just physics > (though of course honest physics involves a great deal of real life so > very little imagination is required to bridge the gap). Actually, that > book is more of a philosophy of science book than a book about the > results of science. > > -David > |
|
|
In reply to this post by David E Jones
David & team
We do need cross pollination between Apache projects - Lets bank on it. Open source works on Word of mouth. (1) ServiceMix - Fuse framework for services - James from Logicblaze might appreciate too. (2) XAL - Let me talk to Bob from nexaweb, we can help you convert in mass to XAL-HTML . Think about it. (3) C-JDBC Ofbiz was way ahead of time...... But open source changes everything. Please understand the "drop-out" candidates due to lots of new learning. my 2 cents on acceptance of framework. Half of career has being in US telecom and rest in India. It is culturally more challenging in India / Asia for non - standard approaches for web frameworks. e.g Verizon for VXML ( Voice XML ) decided to use customized Struts.Verizon Software team wrote extensions back in 2000. VXML needs something like SCXML for reusable dialogs which finally came in Struts2. While it is not possible in Asian scenarios.You have back ur decisions with case studies. Better if case study is that field - finance to win the debate. e.g I see some value in C-JDBC . But it is 3 months and I am still backing my case. It is funny that moment something becomes defacto standard and is asked by US CLIENTS , Indian Software companies churn out guys well-versed in that software in millions :) but very few take the first risk even if it architecturally beautiful. While French simply cannot stop appreciately good architecture. Someone found it challenging to make them accept standard software like JSP. You are bound to loose them in architectural debate. Open Source is to some extent about credibility of suggestions. I was not the best fan of Freemarket but http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse Mark Rabbies article on Freemaker made me feel JSP 2.0 is more or less Freemarker. we had managed to get Appfuse in Large bank's Archtiecture and Mark article made me Look at Freemarker with better frame of mind. It clicked. Chand ----- Original Message ----- From: "David E. Jones" <[hidden email]> To: <[hidden email]> Sent: Monday, February 12, 2007 11:38 PM Subject: Re: General questions > > On Feb 12, 2007, at 11:20 PM, Jonathon -- Improov wrote: > >> But you could be right. IMHO, the lack of clear OFBiz framework >> references (not videos that are unsearchable) may be hindering the >> explosive growth of the OFBiz-enabled engineer population. Also >> IMHO, an explosion in the number of OFBiz-enabled engineers will >> likely feed back into OFBiz very rapidly. And further IMHO, David >> Jones (creator of OFBiz) will then probably have a whole army of >> willing volunteers to choose from (many open source projects employ >> ULTRA STRINGENT qualifying criteria to screen volunteers before >> making them committers; you do get many top brains in open source >> projects, so good that you/I probably can't ever argue with those). >> >> And finally, IMHO, I could be entirely wrong in above paragraph. I >> am not David Jones; I never created an open source project myself. > > If this were the only factor I would release those materials under > the Apache license right away. > > As far as causality goes, knowing about OFBiz is a "necessary" cause > for contribution, but not a "sufficient" cause. If knowing about > OFBiz was a sufficient cause for heavy involvement in contributing to > OFBiz, we would have at least twenty to thirty active (ie daily) > committers, and we would probably go through easily 100 Jira issues a > week from outside contributors. > > For an excellent thesis on causality, I recommend "Causality and > Chance in Modern Physics" by David Bohm and Louis De Broglie, > especially the first few chapters which apply to a good deal other > than just physics (though of course honest physics involves a great > deal of real life so very little imagination is required to bridge > the gap). Actually, that book is more of a philosophy of science book > than a book about the results of science. > > -David > > |
|
|
On Feb 13, 2007, at 1:15 AM, Chandresh Turakhia wrote: > David & team > > We do need cross pollination between Apache projects - Lets bank on > it. Open source works on Word of mouth. > > (1) ServiceMix - Fuse framework for services - James from > Logicblaze might appreciate too. IMO ServiceMix is a good alternative to Axis (and much more flexible) and would complement the Service Engine in OFBiz, but it would in no way would it be able to replace it. > (2) XAL - Let me talk to Bob from nexaweb, we can help you convert > in mass to XAL-HTML . Think about it. This looks like a nice tool and it would be great to use it going forward. I don't like the idea of doing any sort of mass conversion because many pages simply don't need AJAX-like functionality, and it would be best to keep these as simple and multi-browser friendly as possible. Simplicity has other advantages too, like being easier to create and maintain in general. > (3) C-JDBC This is a cool tool and great for use in production to be used as part of deployment efforts. I guess the best thing to do for this is document how to use it with OFBiz. > Ofbiz was way ahead of time...... But open source changes > everything. Please understand the "drop-out" candidates due to lots > of new learning. I guess I'm missing something... how would use of these other projects reduce the learning curve for OFBiz? In general the OFBiz framework is still unique in my opinion. From the beginning we have tried to use other open source projects wherever possible, but so many popular approaches are just no good for development and maintenance of large scale enterprise applications. If there were other open source projects we could lean on to eliminate framework tools, I'd totally push for it, but I have yet to see anything that would do the trick. -David |
|
|
In reply to this post by PRONZATO Cedric RD-BIZZ-GRE
Jonathon,
I think it's great that you found it so easy to learn, but I'd have to urge caution to any newbie who thinks setting aside a time period measured in minutes will be enough to get productive. Generally I find the longer people study the less refactoring they find themselves doing down the line. Be very careful of writing code before you've undertaken an exhaustive study! - Andrew On Tue, 2007-02-13 at 14:20 +0800, Jonathon -- Improov wrote: > Cedric, > > > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you > > much things because you are more experienced than me =) > > I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a > week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and > struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with > other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd > schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway). > > Believe me, OFBiz is easy to pick up. > > Somewhat exact time requirements (in case your boss asks): > > 1. 10 minutes to learn structure of OFBiz, so you know how to move around. > > 2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading > OFBiz like an open REFERENCE book. > > > there are questions about the use of screen/form widgets and > > Beanshell/minilang. I am not well experienced but I don't know if developers > > will like to learn these new things instead of working with what they know. > > As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes. > > But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are > unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also > IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very > rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of > willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying > criteria to screen volunteers before making them committers; you do get many top brains in open > source projects, so good that you/I probably can't ever argue with those). > > And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never > created an open source project myself. > > Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the > time). I'll be sorry if I missed it. > > Jonathon > > PRONZATO Cedric RD-BIZZ-GRE wrote: > > Hi all, > > > > Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :) > > > > My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment. > > Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part. > > Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...) > > So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much. > > > > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =) > > I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned. > > > > I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ... > > > > Thank you all, > > Regards, > > Cédric > > > > -----Message d'origine----- > > De : Jonathon -- Improov [mailto:[hidden email]] > > Envoyé : vendredi 9 février 2007 20:12 > > À : [hidden email] > > Objet : Re: General questions > > > > Cedric, > > > > I get the same impression as Adrian too. > > > > Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too. > > > > Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case. > > > > While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main . > > > > In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang. > > > > I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow. > > > > For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users. > > > > If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated. > > > > Hope you enjoy OFBiz as much as I have. :) > > > > Jonathon > > > > Adrian Crum wrote: > >> Cedric, > >> > >> I might be wrong, but I get the impression you are trying to approach > >> OFBiz from the bottom up (examining java classes versus examining > >> higher-level layers). I made that mistake when I first got involved > >> with OFBiz. > >> > >> It would be better to look at things like the service engine, entity > >> engine, screen widgets, etc. Get an idea of how the presentation layer > >> works, then work your way down to the service layer, then down to the > >> database schema, etc. > >> > >> Typically, the only reason anyone would want to get into the java > >> source would be to fix a bug or make a modification at a very low > >> level of the architecture "stack." > >> > >> > >> > >> PRONZATO Cedric RD-BIZZ-GRE wrote: > >> > >>> Re, > >>> > >>> Yes you are true but I think I didn't explained myself. > >>> These questions may have been answered in the javadocs. I am sure you > >>> know (you that architects of OFBiz) why you decided to make a > >>> Container class and so on. > >>> So perhaps a little enhancement of javadoc on foundation classes to > >>> explain why and where to use it would be so nice. > >>> > >>> I hope I do not look like too much arrogant with my questions on that > >>> thread "General questions"; I just expose the problems I was faced to. > >>> > >>> Regards, > >>> Cédric > >>> > >>> -----Message d'origine----- > >>> De : David E. Jones [mailto:[hidden email]] Envoyé : > >>> vendredi > >>> 9 février 2007 18:12 > >>> À : [hidden email] > >>> Objet : Re: General questions > >>> > >>> > >>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: > >>> > >>> > >>>> A related problem is how to do "framework" components, I mean > >>>> patterns. I think about my SMSC component, I base my code on the > >>>> mail container and questions arised: > >>>> - When do I have to make my own xml language (ie. MCA for the mail > >>>> container)? > >>>> - When do I have to make a Container? I guess the answer is if you > >>>> have to manage the lifetime (create/release connections, ...). > >>>> - When do I have to make an Engine? > >>>> - ... > >>>> > >>>> So I guess we can finish with the following statement: "How to > >>>> *use* is quite well documented but how to *make* is a bit less". > >>> > >>> Have you ever found such a document for anything? > >>> > >>> My usual approach is generally something like: > >>> > >>> 1. understand everything that exists, or research anything that is > >>> unclear 2. write something manually a number of times so you know > >>> what is always the same, and what varies 3. see if a paramerized tool > >>> would be helpful 4. apply a significant amount of "genius" > >>> 5. apply even more "sweat" to try stuff 6. create an incredible tool > >>> or service or however it is best implemented > >>> > >>> If there was a way to make creation deterministic, what would be the > >>> point of creativity? > >>> > >>> -David > >>> > >>> > > > > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
In reply to this post by David E Jones
David E. Jones wrote:
> If there were other open source projects we could lean on to eliminate > framework tools, I'd totally push for it, but I have yet to see anything > that would do the trick. > > -David > > And I'd say that an higher priority is to find out a good alternative for the OFBiz connection pool (still based on an old/customized version of Minerva)... we also recently tried to find a good open source tool that could fit the requirements of OFBiz but without too luck. Jacopo |
|
|
In reply to this post by Andrew Sykes
Andrew,
You're right. I've seen too many refactors and manhours wasted. But don't you often wish you had programmers who could hit the ground sprinting? I guess I do have this problem of telling everybody "you can do it, in minutes". I think all newbies should at least try to get the ML's help to review methods before proceeding (like I did). Be it bottom-up or top-down learning of OFBiz, I still say OFBiz is easy to pick up. And once we do, we'd wonder how to get on without it. I guess, in general (to answer the "General Questions"), there really is a point to learn OFBiz, whether it's tough or easy to learn. David wrote somewhere that OFBiz does try to use open source tools whenever feasible. OFBiz framework is a feasible tool, far as I can tell. (There ARE great tools out there that a quite infeasible, at least in some situations.) And now, other less important/general stuff. "Exhaustive study" to me equals an "evil automated language-processing heuristics search across all OFBiz examples and templates to catch candidates possible for use". Yeah, I did that. Every widget entity I use, I take apart that entity's insides, know how it works inside-out, then employ it (if it's appropriate). As for avoiding refactoring, there's always some "enough is enough" point where I leap off of my "let's make an ultra extensible structure" pre-project project. I've looked at Si Chen's examples of insulating codes from OFBiz core, looked at other examples outside of hot-deploy. Even studied database transactional integrity with the various methods (eca hook-ons, chained requests, extends, implements, etc). (Thanks especially to Jacopo and Chris Howe for some final-touch reviews of my "methods"). So yeah, all newbies should be careful not to plunge in swimming in all the wrong directions. I like drowning, so don't follow me. I'm not a newbie, perhaps; I'm a nobody gone mad. Hmm. You could call David a similar nobody too (I just read his "usual approach" that looks like "wickedly agile R&D" to me). Jonathon Andrew Sykes wrote: > Jonathon, > > I think it's great that you found it so easy to learn, but I'd have to > urge caution to any newbie who thinks setting aside a time period > measured in minutes will be enough to get productive. > > Generally I find the longer people study the less refactoring they find > themselves doing down the line. > > Be very careful of writing code before you've undertaken an exhaustive > study! > > - Andrew > > > On Tue, 2007-02-13 at 14:20 +0800, Jonathon -- Improov wrote: >> Cedric, >> >> > Jonathon, a collaboration? Yes, why not? But I am sure I will not show you >> > much things because you are more experienced than me =) >> >> I started looking at OFBiz framework in Jan 07 (last month). I probably spent no more than a >> week(?) on learning OFBiz framework itself; much of my time was spent on data mapping and >> struggling(!!) with freeing my boss' data from legacy systems, and also on comparing OFBiz with >> other solutions (he kept knocking OFBiz big-time). I had no docs, no references (save xsd >> schemas), I even missed the cookbooks altogether (which really are quite skeletal, anyway). >> >> Believe me, OFBiz is easy to pick up. >> >> Somewhat exact time requirements (in case your boss asks): >> >> 1. 10 minutes to learn structure of OFBiz, so you know how to move around. >> >> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be reading >> OFBiz like an open REFERENCE book. >> >> > there are questions about the use of screen/form widgets and >> > Beanshell/minilang. I am not well experienced but I don't know if developers >> > will like to learn these new things instead of working with what they know. >> >> As I mentioned in other threads, it IS possible to learn OFBiz inside of 10 minutes. >> >> But you could be right. IMHO, the lack of clear OFBiz framework references (not videos that are >> unsearchable) may be hindering the explosive growth of the OFBiz-enabled engineer population. Also >> IMHO, an explosion in the number of OFBiz-enabled engineers will likely feed back into OFBiz very >> rapidly. And further IMHO, David Jones (creator of OFBiz) will then probably have a whole army of >> willing volunteers to choose from (many open source projects employ ULTRA STRINGENT qualifying >> criteria to screen volunteers before making them committers; you do get many top brains in open >> source projects, so good that you/I probably can't ever argue with those). >> >> And finally, IMHO, I could be entirely wrong in above paragraph. I am not David Jones; I never >> created an open source project myself. >> >> Bottom line. OFBiz framework is solid (may need tweaks, but enhancements are on the way all the >> time). I'll be sorry if I missed it. >> >> Jonathon >> >> PRONZATO Cedric RD-BIZZ-GRE wrote: >>> Hi all, >>> >>> Yes, you are all true! My approach is bottom-up learning. All of you here seem to read in me like an opened book; I now know that OFBiz is a training area for FBI Profilers. :) >>> >>> My aim (I think) was to fully understand the framework to be able to change/replace/add new *core* functionalities and test them in a real ecommerce environment. >>> Yet I never played with 'call to a service' or so as the documents about that was enough clear. I said: All should be OK on this part. >>> Entity engine and Service engine are clear and in respect of all the common and trusted laws of java development. (By the way is there any plan to turn to the new standards? OFBiz was in advance in 2000 but now much developer well knows Spring just to name one ...) >>> So after these 2 majors things there are questions about the use of screen/form widgets and Beanshell/minilang. I am not well experienced but I don't know if developers will like to learn these new things instead of working with what they know. So I decided to not investigate it much. >>> >>> Jonathon, a collaboration? Yes, why not? But I am sure I will not show you much things because you are more experienced than me =) >>> I will check about what I am allowed to do with my company policy but I am confidant as OFBiz is a personal choice not too much tied to a project need. I stay you tuned. >>> >>> I now have to think about what is wrong on this approach, think about what is the next thing I have to investigate ... >>> >>> Thank you all, >>> Regards, >>> Cédric >>> >>> -----Message d'origine----- >>> De : Jonathon -- Improov [mailto:[hidden email]] >>> Envoyé : vendredi 9 février 2007 20:12 >>> À : [hidden email] >>> Objet : Re: General questions >>> >>> Cedric, >>> >>> I get the same impression as Adrian too. >>> >>> Since you're from the R&D department, I suppose you're as much of a freak as I am. I took apart OFBiz at the source code level too. >>> >>> Unless you're employing some language-processing heuristics in your reverse-engineering, you'll be spending way too much time doing brute-force studies from the bottom-up. Better to just learn from playing with OFBiz framework (not the framework source codes), such as service engine and entity engine, in this case. >>> >>> While it is true that learning by playing with the framework will certainly be faster, I do admit it is not as easy as many would hope. Technical references for working the OFBiz framework are not all in one place, or even complete (mostly still in form of cookbooks at the moment). Ie, there are no "javadocs equivalent" for the OFBiz framework, except at http://www.undersunconsulting.com/ecommerce/control/main . >>> >>> In fact, some folks here have never gotten around to using all of the OFBiz framework. Some don't use screen/form widgets, but FTL instead. Some use Beanshell rather than Minilang. >>> >>> I guess what I'm trying to say is this. Since you're from the R&D department, it would be "within your scope" to learn the OFBiz framework in any way possible, such as from studying the source codes or playing with the framework itself. No use complaining what isn't there; better to get things working somehow. >>> >>> For those not from the R&D department, though, then yes I do admit OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for new users. >>> >>> If you do want to get help learning the OFBiz framework, you can either work with me and write down all that I've discovered through my own reverse-engineering, or you can employ some of the experts here to teach you. I'll have to train some staff on OFBiz before I sign off my current project, so your help here would be much appreciated. >>> >>> Hope you enjoy OFBiz as much as I have. :) >>> >>> Jonathon >>> >>> Adrian Crum wrote: >>>> Cedric, >>>> >>>> I might be wrong, but I get the impression you are trying to approach >>>> OFBiz from the bottom up (examining java classes versus examining >>>> higher-level layers). I made that mistake when I first got involved >>>> with OFBiz. >>>> >>>> It would be better to look at things like the service engine, entity >>>> engine, screen widgets, etc. Get an idea of how the presentation layer >>>> works, then work your way down to the service layer, then down to the >>>> database schema, etc. >>>> >>>> Typically, the only reason anyone would want to get into the java >>>> source would be to fix a bug or make a modification at a very low >>>> level of the architecture "stack." >>>> >>>> >>>> >>>> PRONZATO Cedric RD-BIZZ-GRE wrote: >>>> >>>>> Re, >>>>> >>>>> Yes you are true but I think I didn't explained myself. >>>>> These questions may have been answered in the javadocs. I am sure you >>>>> know (you that architects of OFBiz) why you decided to make a >>>>> Container class and so on. >>>>> So perhaps a little enhancement of javadoc on foundation classes to >>>>> explain why and where to use it would be so nice. >>>>> >>>>> I hope I do not look like too much arrogant with my questions on that >>>>> thread "General questions"; I just expose the problems I was faced to. >>>>> >>>>> Regards, >>>>> Cédric >>>>> >>>>> -----Message d'origine----- >>>>> De : David E. Jones [mailto:[hidden email]] Envoyé : >>>>> vendredi >>>>> 9 février 2007 18:12 >>>>> À : [hidden email] >>>>> Objet : Re: General questions >>>>> >>>>> >>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>>>> >>>>> >>>>>> A related problem is how to do "framework" components, I mean >>>>>> patterns. I think about my SMSC component, I base my code on the >>>>>> mail container and questions arised: >>>>>> - When do I have to make my own xml language (ie. MCA for the mail >>>>>> container)? >>>>>> - When do I have to make a Container? I guess the answer is if you >>>>>> have to manage the lifetime (create/release connections, ...). >>>>>> - When do I have to make an Engine? >>>>>> - ... >>>>>> >>>>>> So I guess we can finish with the following statement: "How to >>>>>> *use* is quite well documented but how to *make* is a bit less". >>>>> Have you ever found such a document for anything? >>>>> >>>>> My usual approach is generally something like: >>>>> >>>>> 1. understand everything that exists, or research anything that is >>>>> unclear 2. write something manually a number of times so you know >>>>> what is always the same, and what varies 3. see if a paramerized tool >>>>> would be helpful 4. apply a significant amount of "genius" >>>>> 5. apply even more "sweat" to try stuff 6. create an incredible tool >>>>> or service or however it is best implemented >>>>> >>>>> If there was a way to make creation deterministic, what would be the >>>>> point of creativity? >>>>> >>>>> -David >>>>> >>>>> >>> |
Re: General questions ( ServiceMiz )
|
|
In reply to this post by David E Jones
Team,
My Question ) Whats the quickest hack to make Ofbiz services as ServiceMiz SE ? Question asked to me ) Usecase for ServiceMiz. Answering "why you want to use ServiceMiz ". Distributed JBI ( Celtrix ) can save us lot on Roaming charges - Lot term view. Answer ) http://www.logicblaze.com/ ( ServiceMiz and Fuse ) On the minimum front , decoupling the request ( HTTP , Wireless ) and actual service is good. Also integrating Telecom Authentication from jNetX ( Telecom Application server - SOA of telecom ) integration could be easily scritable in ServiceMiz. We telecom company needs such functionality even if it hurts a bit on performance. Binding component for request handlers. Some of the services needs to trigger based on arrival of file ( ftp ). ServiceMiz uses http://www.enterpriseintegrationpatterns.com/DynamicRouter.html Dynamic router pattern to send servicerequest on different instances on ofbiz based on different request parametetrs. It is scriptable to implement in ServiceMIX. e.g. We might have ofbiz service server 1 with data for Northern India and code customized for Northern indian law. - small changes. ofbiz service server 2 with data from southern India ofbiz service server 3 with data from rest of india. We may want to direct to different servers EVEN if the code is same. Help legal issues. Also Cost consideration , the return SMS needs to sent from NEAREST location so telecom bill is less. Also different circles have different telecom infrastructure :) so based on the location the logic changes. e.g Sometimes we do not get XXX information if the request comes from XYZ zone, so there is lot of hacking code around. There is lot of "dumb" reason which we need separate service integrator. Chand > > On Feb 13, 2007, at 1:15 AM, Chandresh Turakhia wrote: > >> David & team >> >> We do need cross pollination between Apache projects - Lets bank on it. >> Open source works on Word of mouth. >> >> (1) ServiceMix - Fuse framework for services - James from Logicblaze >> might appreciate too. > > IMO ServiceMix is a good alternative to Axis (and much more flexible) and > would complement the Service Engine in OFBiz, but it would in no way > would it be able to replace it. > |
|
|
In reply to this post by jonwimp
Jonathon,
Have just been thinking about what you've been saying about learning the OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open REFERENCE book.' A short document describing exactly how to go about such a thing couldn't take more than 10 minutes to read by definition, and probably wouldn't take you much longer than that to write. I'd certainly be interested in reading such a thing and I bet a lot of other people would too. It could be a major drawing point for our site. Just a thought! (Or a wish fulfilment on my part perhaps. Wading through the 1000+ pages of awful, miserable rubbish generated by Les Austin, the technical writer drafted in by David at apparently huge expense. Wishing I could find something myself that I could put together in a couple of hours rather than a couple of months!) Ian Jonathon -- Improov wrote: > Cedric, > > > Jonathon, a collaboration? Yes, why not? But I am sure I will not > show you > > much things because you are more experienced than me =) > > I started looking at OFBiz framework in Jan 07 (last month). I > probably spent no more than a week(?) on learning OFBiz framework > itself; much of my time was spent on data mapping and struggling(!!) > with freeing my boss' data from legacy systems, and also on comparing > OFBiz with other solutions (he kept knocking OFBiz big-time). I had no > docs, no references (save xsd schemas), I even missed the cookbooks > altogether (which really are quite skeletal, anyway). > > Believe me, OFBiz is easy to pick up. > > Somewhat exact time requirements (in case your boss asks): > > 1. 10 minutes to learn structure of OFBiz, so you know how to move > around. > > 2. 1-2 minutes to look up anything related to OFBiz, since you'll be > reading > OFBiz like an open REFERENCE book. > > > there are questions about the use of screen/form widgets and > > Beanshell/minilang. I am not well experienced but I don't know if > developers > > will like to learn these new things instead of working with what > they know. > > As I mentioned in other threads, it IS possible to learn OFBiz inside > of 10 minutes. > > But you could be right. IMHO, the lack of clear OFBiz framework > references (not videos that are unsearchable) may be hindering the > explosive growth of the OFBiz-enabled engineer population. Also IMHO, > an explosion in the number of OFBiz-enabled engineers will likely feed > back into OFBiz very rapidly. And further IMHO, David Jones (creator > of OFBiz) will then probably have a whole army of willing volunteers > to choose from (many open source projects employ ULTRA STRINGENT > qualifying criteria to screen volunteers before making them > committers; you do get many top brains in open source projects, so > good that you/I probably can't ever argue with those). > > And finally, IMHO, I could be entirely wrong in above paragraph. I am > not David Jones; I never created an open source project myself. > > Bottom line. OFBiz framework is solid (may need tweaks, but > enhancements are on the way all the time). I'll be sorry if I missed it. > > Jonathon > > PRONZATO Cedric RD-BIZZ-GRE wrote: >> Hi all, >> >> Yes, you are all true! My approach is bottom-up learning. All of you >> here seem to read in me like an opened book; I now know that OFBiz is >> a training area for FBI Profilers. :) >> >> My aim (I think) was to fully understand the framework to be able to >> change/replace/add new *core* functionalities and test them in a real >> ecommerce environment. >> Yet I never played with 'call to a service' or so as the documents >> about that was enough clear. I said: All should be OK on this part. >> Entity engine and Service engine are clear and in respect of all the >> common and trusted laws of java development. (By the way is there any >> plan to turn to the new standards? OFBiz was in advance in 2000 but >> now much developer well knows Spring just to name one ...) >> So after these 2 majors things there are questions about the use of >> screen/form widgets and Beanshell/minilang. I am not well experienced >> but I don't know if developers will like to learn these new things >> instead of working with what they know. So I decided to not >> investigate it much. >> >> Jonathon, a collaboration? Yes, why not? But I am sure I will not >> show you much things because you are more experienced than me =) I >> will check about what I am allowed to do with my company policy but I >> am confidant as OFBiz is a personal choice not too much tied to a >> project need. I stay you tuned. >> >> I now have to think about what is wrong on this approach, think about >> what is the next thing I have to investigate ... >> >> Thank you all, >> Regards, >> Cédric >> >> -----Message d'origine----- >> De : Jonathon -- Improov [mailto:[hidden email]] Envoyé : vendredi >> 9 février 2007 20:12 >> À : [hidden email] >> Objet : Re: General questions >> >> Cedric, >> >> I get the same impression as Adrian too. >> >> Since you're from the R&D department, I suppose you're as much of a >> freak as I am. I took apart OFBiz at the source code level too. >> >> Unless you're employing some language-processing heuristics in your >> reverse-engineering, you'll be spending way too much time doing >> brute-force studies from the bottom-up. Better to just learn from >> playing with OFBiz framework (not the framework source codes), such >> as service engine and entity engine, in this case. >> >> While it is true that learning by playing with the framework will >> certainly be faster, I do admit it is not as easy as many would hope. >> Technical references for working the OFBiz framework are not all in >> one place, or even complete (mostly still in form of cookbooks at the >> moment). Ie, there are no "javadocs equivalent" for the OFBiz >> framework, except at >> http://www.undersunconsulting.com/ecommerce/control/main . >> >> In fact, some folks here have never gotten around to using all of the >> OFBiz framework. Some don't use screen/form widgets, but FTL instead. >> Some use Beanshell rather than Minilang. >> >> I guess what I'm trying to say is this. Since you're from the R&D >> department, it would be "within your scope" to learn the OFBiz >> framework in any way possible, such as from studying the source codes >> or playing with the framework itself. No use complaining what isn't >> there; better to get things working somehow. >> >> For those not from the R&D department, though, then yes I do admit >> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for >> new users. >> >> If you do want to get help learning the OFBiz framework, you can >> either work with me and write down all that I've discovered through >> my own reverse-engineering, or you can employ some of the experts >> here to teach you. I'll have to train some staff on OFBiz before I >> sign off my current project, so your help here would be much >> appreciated. >> >> Hope you enjoy OFBiz as much as I have. :) >> >> Jonathon >> >> Adrian Crum wrote: >>> Cedric, >>> >>> I might be wrong, but I get the impression you are trying to >>> approach OFBiz from the bottom up (examining java classes versus >>> examining higher-level layers). I made that mistake when I first got >>> involved with OFBiz. >>> >>> It would be better to look at things like the service engine, entity >>> engine, screen widgets, etc. Get an idea of how the presentation >>> layer works, then work your way down to the service layer, then down >>> to the database schema, etc. >>> >>> Typically, the only reason anyone would want to get into the java >>> source would be to fix a bug or make a modification at a very low >>> level of the architecture "stack." >>> >>> >>> >>> PRONZATO Cedric RD-BIZZ-GRE wrote: >>> >>>> Re, >>>> >>>> Yes you are true but I think I didn't explained myself. >>>> These questions may have been answered in the javadocs. I am sure >>>> you know (you that architects of OFBiz) why you decided to make a >>>> Container class and so on. >>>> So perhaps a little enhancement of javadoc on foundation classes to >>>> explain why and where to use it would be so nice. >>>> >>>> I hope I do not look like too much arrogant with my questions on >>>> that thread "General questions"; I just expose the problems I was >>>> faced to. >>>> >>>> Regards, >>>> Cédric >>>> >>>> -----Message d'origine----- >>>> De : David E. Jones [mailto:[hidden email]] Envoyé : vendredi >>>> 9 février 2007 18:12 >>>> À : [hidden email] >>>> Objet : Re: General questions >>>> >>>> >>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>>> >>>> >>>>> A related problem is how to do "framework" components, I mean >>>>> patterns. I think about my SMSC component, I base my code on the >>>>> mail container and questions arised: >>>>> - When do I have to make my own xml language (ie. MCA for the mail >>>>> container)? >>>>> - When do I have to make a Container? I guess the answer is if you >>>>> have to manage the lifetime (create/release connections, ...). >>>>> - When do I have to make an Engine? >>>>> - ... >>>>> >>>>> So I guess we can finish with the following statement: "How to >>>>> *use* is quite well documented but how to *make* is a bit less". >>>> >>>> Have you ever found such a document for anything? >>>> >>>> My usual approach is generally something like: >>>> >>>> 1. understand everything that exists, or research anything that is >>>> unclear 2. write something manually a number of times so you know >>>> what is always the same, and what varies 3. see if a paramerized >>>> tool would be helpful 4. apply a significant amount of "genius" >>>> 5. apply even more "sweat" to try stuff 6. create an incredible >>>> tool or service or however it is best implemented >>>> >>>> If there was a way to make creation deterministic, what would be >>>> the point of creativity? >>>> >>>> -David >>>> >>>> >> >> > > > -- ---------------------------------------------------------------------------------------------- mcnultyMEDIA 60 Birkdale Gardens Durham DH1 2UL t: +44 (0)191 384 4736 e: [hidden email] w: www.mcnultymedia.co.uk ============================================================================================== This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736 This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment. ============================================================================================== |
|
|
To all,
please ignore this troll. Jacopo Ian McNulty wrote: > Jonathon, > > Have just been thinking about what you've been saying about learning the > OFBiz framework inside of 10 minutes and how to read OFBiz 'like an open > REFERENCE book.' > > A short document describing exactly how to go about such a thing > couldn't take more than 10 minutes to read by definition, and probably > wouldn't take you much longer than that to write. > > I'd certainly be interested in reading such a thing and I bet a lot of > other people would too. It could be a major drawing point for our site. > > Just a thought! (Or a wish fulfilment on my part perhaps. Wading through > the 1000+ pages of awful, miserable rubbish generated by Les Austin, the > technical writer drafted in by David at apparently huge expense. Wishing > I could find something myself that I could put together in a couple of > hours rather than a couple of months!) > > Ian > > > > > Jonathon -- Improov wrote: >> Cedric, >> >> > Jonathon, a collaboration? Yes, why not? But I am sure I will not >> show you >> > much things because you are more experienced than me =) >> >> I started looking at OFBiz framework in Jan 07 (last month). I >> probably spent no more than a week(?) on learning OFBiz framework >> itself; much of my time was spent on data mapping and struggling(!!) >> with freeing my boss' data from legacy systems, and also on comparing >> OFBiz with other solutions (he kept knocking OFBiz big-time). I had no >> docs, no references (save xsd schemas), I even missed the cookbooks >> altogether (which really are quite skeletal, anyway). >> >> Believe me, OFBiz is easy to pick up. >> >> Somewhat exact time requirements (in case your boss asks): >> >> 1. 10 minutes to learn structure of OFBiz, so you know how to move >> around. >> >> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be >> reading >> OFBiz like an open REFERENCE book. >> >> > there are questions about the use of screen/form widgets and >> > Beanshell/minilang. I am not well experienced but I don't know if >> developers >> > will like to learn these new things instead of working with what >> they know. >> >> As I mentioned in other threads, it IS possible to learn OFBiz inside >> of 10 minutes. >> >> But you could be right. IMHO, the lack of clear OFBiz framework >> references (not videos that are unsearchable) may be hindering the >> explosive growth of the OFBiz-enabled engineer population. Also IMHO, >> an explosion in the number of OFBiz-enabled engineers will likely feed >> back into OFBiz very rapidly. And further IMHO, David Jones (creator >> of OFBiz) will then probably have a whole army of willing volunteers >> to choose from (many open source projects employ ULTRA STRINGENT >> qualifying criteria to screen volunteers before making them >> committers; you do get many top brains in open source projects, so >> good that you/I probably can't ever argue with those). >> >> And finally, IMHO, I could be entirely wrong in above paragraph. I am >> not David Jones; I never created an open source project myself. >> >> Bottom line. OFBiz framework is solid (may need tweaks, but >> enhancements are on the way all the time). I'll be sorry if I missed it. >> >> Jonathon >> >> PRONZATO Cedric RD-BIZZ-GRE wrote: >>> Hi all, >>> >>> Yes, you are all true! My approach is bottom-up learning. All of you >>> here seem to read in me like an opened book; I now know that OFBiz is >>> a training area for FBI Profilers. :) >>> >>> My aim (I think) was to fully understand the framework to be able to >>> change/replace/add new *core* functionalities and test them in a real >>> ecommerce environment. >>> Yet I never played with 'call to a service' or so as the documents >>> about that was enough clear. I said: All should be OK on this part. >>> Entity engine and Service engine are clear and in respect of all the >>> common and trusted laws of java development. (By the way is there any >>> plan to turn to the new standards? OFBiz was in advance in 2000 but >>> now much developer well knows Spring just to name one ...) >>> So after these 2 majors things there are questions about the use of >>> screen/form widgets and Beanshell/minilang. I am not well experienced >>> but I don't know if developers will like to learn these new things >>> instead of working with what they know. So I decided to not >>> investigate it much. >>> >>> Jonathon, a collaboration? Yes, why not? But I am sure I will not >>> show you much things because you are more experienced than me =) I >>> will check about what I am allowed to do with my company policy but I >>> am confidant as OFBiz is a personal choice not too much tied to a >>> project need. I stay you tuned. >>> >>> I now have to think about what is wrong on this approach, think about >>> what is the next thing I have to investigate ... >>> >>> Thank you all, >>> Regards, >>> Cédric >>> >>> -----Message d'origine----- >>> De : Jonathon -- Improov [mailto:[hidden email]] Envoyé : vendredi >>> 9 février 2007 20:12 >>> À : [hidden email] >>> Objet : Re: General questions >>> >>> Cedric, >>> >>> I get the same impression as Adrian too. >>> >>> Since you're from the R&D department, I suppose you're as much of a >>> freak as I am. I took apart OFBiz at the source code level too. >>> >>> Unless you're employing some language-processing heuristics in your >>> reverse-engineering, you'll be spending way too much time doing >>> brute-force studies from the bottom-up. Better to just learn from >>> playing with OFBiz framework (not the framework source codes), such >>> as service engine and entity engine, in this case. >>> >>> While it is true that learning by playing with the framework will >>> certainly be faster, I do admit it is not as easy as many would hope. >>> Technical references for working the OFBiz framework are not all in >>> one place, or even complete (mostly still in form of cookbooks at the >>> moment). Ie, there are no "javadocs equivalent" for the OFBiz >>> framework, except at >>> http://www.undersunconsulting.com/ecommerce/control/main . >>> >>> In fact, some folks here have never gotten around to using all of the >>> OFBiz framework. Some don't use screen/form widgets, but FTL instead. >>> Some use Beanshell rather than Minilang. >>> >>> I guess what I'm trying to say is this. Since you're from the R&D >>> department, it would be "within your scope" to learn the OFBiz >>> framework in any way possible, such as from studying the source codes >>> or playing with the framework itself. No use complaining what isn't >>> there; better to get things working somehow. >>> >>> For those not from the R&D department, though, then yes I do admit >>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" for >>> new users. >>> >>> If you do want to get help learning the OFBiz framework, you can >>> either work with me and write down all that I've discovered through >>> my own reverse-engineering, or you can employ some of the experts >>> here to teach you. I'll have to train some staff on OFBiz before I >>> sign off my current project, so your help here would be much >>> appreciated. >>> >>> Hope you enjoy OFBiz as much as I have. :) >>> >>> Jonathon >>> >>> Adrian Crum wrote: >>>> Cedric, >>>> >>>> I might be wrong, but I get the impression you are trying to >>>> approach OFBiz from the bottom up (examining java classes versus >>>> examining higher-level layers). I made that mistake when I first got >>>> involved with OFBiz. >>>> >>>> It would be better to look at things like the service engine, entity >>>> engine, screen widgets, etc. Get an idea of how the presentation >>>> layer works, then work your way down to the service layer, then down >>>> to the database schema, etc. >>>> >>>> Typically, the only reason anyone would want to get into the java >>>> source would be to fix a bug or make a modification at a very low >>>> level of the architecture "stack." >>>> >>>> >>>> >>>> PRONZATO Cedric RD-BIZZ-GRE wrote: >>>> >>>>> Re, >>>>> >>>>> Yes you are true but I think I didn't explained myself. >>>>> These questions may have been answered in the javadocs. I am sure >>>>> you know (you that architects of OFBiz) why you decided to make a >>>>> Container class and so on. >>>>> So perhaps a little enhancement of javadoc on foundation classes to >>>>> explain why and where to use it would be so nice. >>>>> >>>>> I hope I do not look like too much arrogant with my questions on >>>>> that thread "General questions"; I just expose the problems I was >>>>> faced to. >>>>> >>>>> Regards, >>>>> Cédric >>>>> >>>>> -----Message d'origine----- >>>>> De : David E. Jones [mailto:[hidden email]] Envoyé : vendredi >>>>> 9 février 2007 18:12 >>>>> À : [hidden email] >>>>> Objet : Re: General questions >>>>> >>>>> >>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>>>> >>>>> >>>>>> A related problem is how to do "framework" components, I mean >>>>>> patterns. I think about my SMSC component, I base my code on the >>>>>> mail container and questions arised: >>>>>> - When do I have to make my own xml language (ie. MCA for the mail >>>>>> container)? >>>>>> - When do I have to make a Container? I guess the answer is if you >>>>>> have to manage the lifetime (create/release connections, ...). >>>>>> - When do I have to make an Engine? >>>>>> - ... >>>>>> >>>>>> So I guess we can finish with the following statement: "How to >>>>>> *use* is quite well documented but how to *make* is a bit less". >>>>> >>>>> Have you ever found such a document for anything? >>>>> >>>>> My usual approach is generally something like: >>>>> >>>>> 1. understand everything that exists, or research anything that is >>>>> unclear 2. write something manually a number of times so you know >>>>> what is always the same, and what varies 3. see if a paramerized >>>>> tool would be helpful 4. apply a significant amount of "genius" >>>>> 5. apply even more "sweat" to try stuff 6. create an incredible >>>>> tool or service or however it is best implemented >>>>> >>>>> If there was a way to make creation deterministic, what would be >>>>> the point of creativity? >>>>> >>>>> -David >>>>> >>>>> >>> >>> >> >> >> > |
|
|
In reply to this post by Ian McNulty
OK Guys. I was hoping to keep quiet until I had something useful to
show, but the cat is now out of the bag. I've been sitting at my desk solidly for 13 hours now trying to make a contribution by trying to pull together the User pdfs into something useful and I'm rapidly losing my marbles. I'm sure David and Les did an excellent job under the circumstances. It's just that the pdfs contain so many html tags and complicated paragraph numbers which need to be cut out. I've been suffering from RSI in my mouse arm for several years now and dragging and dropping 1000 pages of text is causing me a lot of misery and pain. I blasted off a reply to Jonathon's over-bounding enthusiasm without stopping to count to 10. Not an excuse. Just some kind of an explanation, if such a thing is possible. I guess Jacopo proved to be right in the end. I have ended up as nothing more than a troll. Sad or wot? :( Ian Ian McNulty wrote: > Jonathon, > > Have just been thinking about what you've been saying about learning > the OFBiz framework inside of 10 minutes and how to read OFBiz 'like > an open REFERENCE book.' > > A short document describing exactly how to go about such a thing > couldn't take more than 10 minutes to read by definition, and probably > wouldn't take you much longer than that to write. > > I'd certainly be interested in reading such a thing and I bet a lot of > other people would too. It could be a major drawing point for our site. > > Just a thought! (Or a wish fulfilment on my part perhaps. Wading > through the 1000+ pages of awful, miserable rubbish generated by Les > Austin, the technical writer drafted in by David at apparently huge > expense. Wishing I could find something myself that I could put > together in a couple of hours rather than a couple of months!) > > Ian > > > > > Jonathon -- Improov wrote: >> Cedric, >> >> > Jonathon, a collaboration? Yes, why not? But I am sure I will not >> show you >> > much things because you are more experienced than me =) >> >> I started looking at OFBiz framework in Jan 07 (last month). I >> probably spent no more than a week(?) on learning OFBiz framework >> itself; much of my time was spent on data mapping and struggling(!!) >> with freeing my boss' data from legacy systems, and also on comparing >> OFBiz with other solutions (he kept knocking OFBiz big-time). I had >> no docs, no references (save xsd schemas), I even missed the >> cookbooks altogether (which really are quite skeletal, anyway). >> >> Believe me, OFBiz is easy to pick up. >> >> Somewhat exact time requirements (in case your boss asks): >> >> 1. 10 minutes to learn structure of OFBiz, so you know how to move >> around. >> >> 2. 1-2 minutes to look up anything related to OFBiz, since you'll be >> reading >> OFBiz like an open REFERENCE book. >> >> > there are questions about the use of screen/form widgets and >> > Beanshell/minilang. I am not well experienced but I don't know if >> developers >> > will like to learn these new things instead of working with what >> they know. >> >> As I mentioned in other threads, it IS possible to learn OFBiz inside >> of 10 minutes. >> >> But you could be right. IMHO, the lack of clear OFBiz framework >> references (not videos that are unsearchable) may be hindering the >> explosive growth of the OFBiz-enabled engineer population. Also IMHO, >> an explosion in the number of OFBiz-enabled engineers will likely >> feed back into OFBiz very rapidly. And further IMHO, David Jones >> (creator of OFBiz) will then probably have a whole army of willing >> volunteers to choose from (many open source projects employ ULTRA >> STRINGENT qualifying criteria to screen volunteers before making them >> committers; you do get many top brains in open source projects, so >> good that you/I probably can't ever argue with those). >> >> And finally, IMHO, I could be entirely wrong in above paragraph. I am >> not David Jones; I never created an open source project myself. >> >> Bottom line. OFBiz framework is solid (may need tweaks, but >> enhancements are on the way all the time). I'll be sorry if I missed it. >> >> Jonathon >> >> PRONZATO Cedric RD-BIZZ-GRE wrote: >>> Hi all, >>> >>> Yes, you are all true! My approach is bottom-up learning. All of you >>> here seem to read in me like an opened book; I now know that OFBiz >>> is a training area for FBI Profilers. :) >>> >>> My aim (I think) was to fully understand the framework to be able to >>> change/replace/add new *core* functionalities and test them in a >>> real ecommerce environment. >>> Yet I never played with 'call to a service' or so as the documents >>> about that was enough clear. I said: All should be OK on this part. >>> Entity engine and Service engine are clear and in respect of all the >>> common and trusted laws of java development. (By the way is there >>> any plan to turn to the new standards? OFBiz was in advance in 2000 >>> but now much developer well knows Spring just to name one ...) >>> So after these 2 majors things there are questions about the use of >>> screen/form widgets and Beanshell/minilang. I am not well >>> experienced but I don't know if developers will like to learn these >>> new things instead of working with what they know. So I decided to >>> not investigate it much. >>> >>> Jonathon, a collaboration? Yes, why not? But I am sure I will not >>> show you much things because you are more experienced than me =) I >>> will check about what I am allowed to do with my company policy but >>> I am confidant as OFBiz is a personal choice not too much tied to a >>> project need. I stay you tuned. >>> >>> I now have to think about what is wrong on this approach, think >>> about what is the next thing I have to investigate ... >>> >>> Thank you all, >>> Regards, >>> Cédric >>> >>> -----Message d'origine----- >>> De : Jonathon -- Improov [mailto:[hidden email]] Envoyé : vendredi >>> 9 février 2007 20:12 >>> À : [hidden email] >>> Objet : Re: General questions >>> >>> Cedric, >>> >>> I get the same impression as Adrian too. >>> >>> Since you're from the R&D department, I suppose you're as much of a >>> freak as I am. I took apart OFBiz at the source code level too. >>> >>> Unless you're employing some language-processing heuristics in your >>> reverse-engineering, you'll be spending way too much time doing >>> brute-force studies from the bottom-up. Better to just learn from >>> playing with OFBiz framework (not the framework source codes), such >>> as service engine and entity engine, in this case. >>> >>> While it is true that learning by playing with the framework will >>> certainly be faster, I do admit it is not as easy as many would >>> hope. Technical references for working the OFBiz framework are not >>> all in one place, or even complete (mostly still in form of >>> cookbooks at the moment). Ie, there are no "javadocs equivalent" for >>> the OFBiz framework, except at >>> http://www.undersunconsulting.com/ecommerce/control/main . >>> >>> In fact, some folks here have never gotten around to using all of >>> the OFBiz framework. Some don't use screen/form widgets, but FTL >>> instead. Some use Beanshell rather than Minilang. >>> >>> I guess what I'm trying to say is this. Since you're from the R&D >>> department, it would be "within your scope" to learn the OFBiz >>> framework in any way possible, such as from studying the source >>> codes or playing with the framework itself. No use complaining what >>> isn't there; better to get things working somehow. >>> >>> For those not from the R&D department, though, then yes I do admit >>> OFBiz doesn't have a nice polished expensive "welcome mat/carpet" >>> for new users. >>> >>> If you do want to get help learning the OFBiz framework, you can >>> either work with me and write down all that I've discovered through >>> my own reverse-engineering, or you can employ some of the experts >>> here to teach you. I'll have to train some staff on OFBiz before I >>> sign off my current project, so your help here would be much >>> appreciated. >>> >>> Hope you enjoy OFBiz as much as I have. :) >>> >>> Jonathon >>> >>> Adrian Crum wrote: >>>> Cedric, >>>> >>>> I might be wrong, but I get the impression you are trying to >>>> approach OFBiz from the bottom up (examining java classes versus >>>> examining higher-level layers). I made that mistake when I first >>>> got involved with OFBiz. >>>> >>>> It would be better to look at things like the service engine, >>>> entity engine, screen widgets, etc. Get an idea of how the >>>> presentation layer works, then work your way down to the service >>>> layer, then down to the database schema, etc. >>>> >>>> Typically, the only reason anyone would want to get into the java >>>> source would be to fix a bug or make a modification at a very low >>>> level of the architecture "stack." >>>> >>>> >>>> >>>> PRONZATO Cedric RD-BIZZ-GRE wrote: >>>> >>>>> Re, >>>>> >>>>> Yes you are true but I think I didn't explained myself. >>>>> These questions may have been answered in the javadocs. I am sure >>>>> you know (you that architects of OFBiz) why you decided to make a >>>>> Container class and so on. >>>>> So perhaps a little enhancement of javadoc on foundation classes >>>>> to explain why and where to use it would be so nice. >>>>> >>>>> I hope I do not look like too much arrogant with my questions on >>>>> that thread "General questions"; I just expose the problems I was >>>>> faced to. >>>>> >>>>> Regards, >>>>> Cédric >>>>> >>>>> -----Message d'origine----- >>>>> De : David E. Jones [mailto:[hidden email]] Envoyé : >>>>> vendredi >>>>> 9 février 2007 18:12 >>>>> À : [hidden email] >>>>> Objet : Re: General questions >>>>> >>>>> >>>>> On Feb 9, 2007, at 9:12 AM, PRONZATO Cedric RD-BIZZ-GRE wrote: >>>>> >>>>> >>>>>> A related problem is how to do "framework" components, I mean >>>>>> patterns. I think about my SMSC component, I base my code on the >>>>>> mail container and questions arised: >>>>>> - When do I have to make my own xml language (ie. MCA for the >>>>>> mail container)? >>>>>> - When do I have to make a Container? I guess the answer is if >>>>>> you have to manage the lifetime (create/release connections, ...). >>>>>> - When do I have to make an Engine? >>>>>> - ... >>>>>> >>>>>> So I guess we can finish with the following statement: "How to >>>>>> *use* is quite well documented but how to *make* is a bit less". >>>>> >>>>> Have you ever found such a document for anything? >>>>> >>>>> My usual approach is generally something like: >>>>> >>>>> 1. understand everything that exists, or research anything that is >>>>> unclear 2. write something manually a number of times so you know >>>>> what is always the same, and what varies 3. see if a paramerized >>>>> tool would be helpful 4. apply a significant amount of "genius" >>>>> 5. apply even more "sweat" to try stuff 6. create an incredible >>>>> tool or service or however it is best implemented >>>>> >>>>> If there was a way to make creation deterministic, what would be >>>>> the point of creativity? >>>>> >>>>> -David >>>>> >>>>> >>> >>> >> >> >> > -- ---------------------------------------------------------------------------------------------- mcnultyMEDIA 60 Birkdale Gardens Durham DH1 2UL t: +44 (0)191 384 4736 e: [hidden email] w: www.mcnultymedia.co.uk ============================================================================================== This communication is for the exclusive use of the intended recipient(s) named above and is confidential. Any form of distribution, copying, discussion or use of this communication, its contents, or any information contained herein without prior consent is strictly prohibited. If you receive this communication in error, please notify the sender by email or by telephone on +44 (0)191 384 4736 This email has been checked for viruses, however, we cannot accept any liability sustained as a result of software viruses and would recommend that you carry out your own virus checks before opening any attachment. ============================================================================================== |
|
|
On Feb 13, 2007, at 11:14 AM, Ian McNulty wrote: > I'm sure David and Les did an excellent job under the > circumstances. It's just that the pdfs contain so many html tags > and complicated paragraph numbers which need to be cut out. I've > been suffering from RSI in my mouse arm for several years now and > dragging and dropping 1000 pages of text is causing me a lot of > misery and pain. I blasted off a reply to Jonathon's over-bounding > enthusiasm without stopping to count to 10. Is that what you find terrible about the documentation? The formatting? I hope you didn't think these PDFs were designed to be this way... You may have already guessed that this documentation was made for an online system, not to go into PDFs. The reason they are in PDFs and we won't let people access the online system anymore is that we don't want to maintain and pay for the hosting and manually grant people permission when they ask (and for the most part have not contributed to the migration and editing effort as promised in order to get the access). -David |
|
|
David,
David E. Jones wrote: > > On Feb 13, 2007, at 11:14 AM, Ian McNulty wrote: > >> I'm sure David and Les did an excellent job under the circumstances. >> It's just that the pdfs contain so many html tags and complicated >> paragraph numbers which need to be cut out. I've been suffering from >> RSI in my mouse arm for several years now and dragging and dropping >> 1000 pages of text is causing me a lot of misery and pain. I blasted >> off a reply to Jonathon's over-bounding enthusiasm without stopping >> to count to 10. > > Is that what you find terrible about the documentation? The formatting? Yes. Primarily. The enormous amount of work that has gone into creating those 1000+ pages is evident. I just find it so difficult to scan through is all. > I hope you didn't think these PDFs were designed to be this way... Well, yes I did actually. Why would I assume otherwise? > > You may have already guessed that this documentation was made for an > online system, not to go into PDFs. Ehr, no I'm afraid I didn't. I just took them at face value and tried to work with them as they are. > The reason they are in PDFs and we won't let people access the online > system anymore is that we don't want to maintain and pay for the > hosting and manually grant people permission when they ask (and for > the most part have not contributed to the migration and editing effort > as promised in order to get the access). OK. Fair do's. I've already had enough of a kicking from this ML and don't want to lay myself open to any more. I appreciate all the work and expense that's gone into creating all this stuff and apologise for any comments I may have made which could be interpreted as negative, critical or counter-productive in any way. Ian |
|
|
In reply to this post by jonwimp
I find it an irony, the quest to the top of the world is littered with the defeated bodies of those who where unable to meet the final challenge. Returning from the top of the world. That said building a website should not be like climbing Mount Everest, always weary of the next step because you don't know which rope someone else put out that might get you killed on the way down more often than on the way up!
I must admit that many who venture here seem to be looking for tools that can be reshaped. Others seem to be here looking to learn or for a pleasurable journey, shared in good company. As for me I enjoy learning from a well written, well organized and graphically illustrated/interesting book/web site. These can be both relaxing, enlightening and invigorating. In my time I have learned things we do with ease we also do with grace, and such things soon take on a life that is vibrant and impossible to hide. This inspires creativity and loosens the soul. The other side to this coin is in space no one can hear you scream because you don't have 15 minutes to string together an obstacle course represented by a series of laborious documents and a labyrinth of hints. ;¬)
|
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |