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 HA-JDBC would be a lot easier to do. It only requires a change to the 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" <[EMAIL PROTECTED]> > To: <[email protected]> > 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:[EMAIL PROTECTED] > > Envoyé : vendredi 9 février 2007 20:12 > > À : [email protected] > > 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:[EMAIL PROTECTED] Envoyé : > >>> vendredi > >>> 9 février 2007 18:12 > >>> À : [email protected] > >>> 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
