--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
> Hi Chris, (all) > > hmmm... I was hoping that your comments were > motivated by a careful > review of the OFBiz existing data model and > processes, not by general > and abstract assumptions of how you think an > agreement data model should > be designed. > Aside from the assumption being in fact of base, I don't think it was an unfair assumption given that OFBiz generally has a generic data model. How does the generic term "Agreement" have anything to do with Product? If, for example, the Order entities can be so elegantly seperated from Party, why can't agreement be elegantly seperated from Product? > Hopefully now we are not in the process of drafting > out the agreement > data model from scratch (and the OFBiz data model in > general): the data > model is already in place (and it's very very good, > even if it is not > perfect), we have many users running their > applications on it, and now > we are trying to implement/complete the processes > based on it and > sometimes, while building them, we refine the data > model itself. > I agree that it is generally a very very good data model. However, the imperfections in it are obscurely imperfect. Creating functionality based on non generic, nonmodularized principles forces anyone to run that part of their business in the manner that you've implemented it, roll their own in a way that doesn't allow them to benefit from advancements in interoperability or not integrate that part of their business with OFBiz. > This is the current status of the OFBiz project and > we should all be on > the same track: I really think it would be a bad > thing for the project > (confusion for users/developers, slow down > development, backward > compatibility issues) if we were to assume that, > every time a new > feature is discussed, it is a good chance to > re-implement the OFBiz data > model starting from some very different abstract > data model we have in mind. > The only track that we "should" all be on is an interest in the project improving. I'm positive that we are all on that track. How we go about that improving, we should be as diverse as possible. Feel free to go full steam ahead on your feature. Someone else who has more general use of agreements and product pricing is simply going to have to redouble your efforts to allow it to work with other functionality. Backwards compatability issues stem from there being a need in functionality that cannot be obtained from the current structure. So, had the structure been generic enough to obtain said functionality, there wouldn't be a backwards compatability issue. Users imagination on how to use OFBiz is not going to decrease. There's not going to be a desire for less functionality. > We are working on OFBiz an we should focus on OFBiz, > limiting our > comments on what we know of OFBiz. > I think that should be slightly rephrased. We should limit our comments on what we know of business processes and how to consistantly implement those process with OFBiz. > And finally, as regards the existing OFBiz data > model and features, I > think it is wise to limit our remarks based on real > use cases we are > facing with OFBiz and not on the use cases we could > imagine that could > happen: by my experience, when we try to forecast > each and every use > cases we'll be however missing many of them - the > real ones ;-) - and we > will spend a lot of time writing code to handle > useless scenarios (that > no one will use, test, implement). > With OFBiz's now completed Apache 2.0 license anyone can strip and scrape any part of OFBiz they want to market as their own implementation and still take advantage of the Apache goodwill. You all who consult based on OFBiz will be in competition with these other implementations. Why would you want to allow them to point out specifically where things aren't generic enough to support a contract that you're both going after? Limit the remarks at your own peril (that line was for David ;) a little legitimate FUD for ya).
