Jacopo, I noticed your changes. Thanks for taking initiative of this.
On Wed, Jul 16, 2008 at 2:04 PM, Jacopo Cappellato < [EMAIL PROTECTED]> wrote: > For now I have added a description for the workEffortParentId field in rev. > 677193 > > Jacopo > > > On Jul 16, 2008, at 9:24 AM, Jacques Le Roux wrote: > > BTW, what do you think of this message I sent to user list ? >> >> <<Maybe we should even add a comment at each denormalised field (in model) >> to explain and make this more clear (maybe it's ealready done I did not >> check)>> >> >> It could be a good way to stop the pb at root. >> >> Thanks >> >> Jacques >> >> David, >>> >>> From: "David E Jones" <[EMAIL PROTECTED]> >>> >>>> >>>> Jacques, >>>> >>>> We can't document every little thing. If best practices and other >>>> recommendations and guidelines are too big then we might as well not >>>> have them because no one will take the time to understand them, and >>>> even those few who read them all the way through won't be able to >>>> remember them. >>>> >>> >>> I thought about putting some organised links from bottom of Contributors >>> Best Practice page. Hence those interested would read. I know it's not easy >>> to remember, sometimes I have to read things twice (with often a long time >>> between) or even more to really absorb them. Maybe because there are a lot >>> of them. Nevertheless, I believe that having them documented is better than >>> not. At least the Commiters should be aware of them. I'm one from 2 years >>> and I'm still not aware of all I should be. Thanks to your repeated efforts >>> I was able to grab most of the framework and some subtleties here and there. >>> Really... documentation help ! >>> >>> If you'd like to then by all means please do (this is not a centrally >>>> driven organization). Just keep in mind your target audience. If your >>>> question is really "how can we avoid this sort of conversation in the >>>> future" then I'm not really sure there is a good answer. With anything >>>> complex people really have to explore it and learn for themselves and >>>> telling them what they need to know before they realize they need to >>>> know it usually doesn't help. It just takes time for people to learn >>>> about things and understand common patterns. >>>> >>> >>> Yes you are right, my father always told me the same :o) >>> >>> If anything I'd prefer people to have a good understanding of data >>>> structure theories and then converse intelligently based on that, and >>>> not have to converse at all for common situations that really need no >>>> discussion. However, most people don't have that background and can't >>>> tolerate weeks or months of study about graphs and trees and lists and >>>> sets and tables and indexes and hashes... and the differences and >>>> similarities between them... and common algorithms for working with >>>> them, and so on and so forth. >>>> I really wish EVERYONE involved with enterprise software would learn >>>> about these things. They are the foundational tools that we all work >>>> with on a daily basis and the theory and ideas around them are not >>>> really all that difficult compared with their utility and value in the >>>> things we create with them. >>>> >>> >>> Yes I agree, and I'm missing such a detailled knowledge too, coming more >>> from the algorithm branch of IT studies (sorry, BD always bored me, even if >>> I liked them more viewed from the logic theory side ;o). However, to be >>> pragmatic, I'm rather sure that pointing some details out will help people >>> to better understand underlying concepts. >>> >>> Thansk for taking the time to comment. >>> >>> Jacques >>> >>> -David >>>> >>>> >>>> On Jul 15, 2008, at 11:31 AM, Jacques Le Roux wrote: >>>> >>>> David, All, >>>>> >>>>> Should we not write something around such aspects in the best >>>>> practices. I could begin by using the detailled recommandations >>>>> below... >>>>> David could you provide a plan to follow ? I believe it's very >>>>> important for contributors to keep mains and other applications clean. >>>>> >>>>> Jacques >>>>> >>>>> From: "David E Jones" <[EMAIL PROTECTED]> >>>>> >>>>>> >>>>>> Just like with Product and ProductCategory going through >>>>>> ProductCategoryMember, when two WorkEfforts are associated they >>>>>> should always go through WorkEffortAssoc. >>>>>> >>>>>> I don't know why the decision was made in the Project Manager >>>>>> specialpurpose application to use the workEffortParentId, but it >>>>>> shouldn't have been used there. You'll notice in the workeffort >>>>>> component and webapp for the child WorkEffort tree it uses the >>>>>> WorkEffortAssoc, and that is how it should be. >>>>>> >>>>>> Just as with products and categories the use of this direct fields >>>>>> is for going in the other direction, in other words when going up >>>>>> the tree when you want a single WorkEffort record. When going down >>>>>> the tree you should always use WorkEffortAssoc (just like you >>>>>> would always use ProductCategoryRollup). When going up the tree >>>>>> and you want the multiple parents always use WorkEffortAssoc. When >>>>>> you want to specify one of the various parent WorkEfforts already >>>>>> setup in WorkEffortAssoc that is the primary parent or the like >>>>>> then use the workEffortParentId. >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Jul 15, 2008, at 4:35 AM, Ashish Vijaywargiya wrote: >>>>>> >>>>>> Thanks Jacopo for your comments. >>>>>>> Let's see what other has to say about workEffortParentId field. >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 15, 2008 at 3:51 PM, Jacopo Cappellato < >>>>>>> [EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>> I have to admit that I don't like very much the >>>>>>>> workEffortParentId field >>>>>>>> and the way it is used; it would be better if the >>>>>>>> WorkEffortAssoc entity was >>>>>>>> used every time you have to specify an association between work >>>>>>>> effort: in >>>>>>>> this way you'll have the ability to set the type ofassociation >>>>>>>> and also >>>>>>>> validity dates. >>>>>>>> Sometimes having denormalized fields is useful (to speed up >>>>>>>> queries and >>>>>>>> simplify code) but unfortunately the workEffortParentId field is >>>>>>>> not used >>>>>>>> only for this and it is used a lot, especially by the manufacturing >>>>>>>> component, ven when the WorkEffortAssoc would do much more sense. >>>>>>>> >>>>>>>> My general suggestion would be that of using WorkEffortAssoc as >>>>>>>> much as >>>>>>>> possible (especially for new code/features). >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jul 15, 2008, at 11:46 AM, Ashish Vijaywargiya wrote: >>>>>>>> >>>>>>>> Can anybody having good insight on WorkEffort module put some >>>>>>>> comments to >>>>>>>> >>>>>>>>> understand this scenario ? >>>>>>>>> I am also interested to know about it. >>>>>>>>> >>>>>>>>> Thanks !!! >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Jun 14, 2008 at 8:46 PM, Rishi Solanki < >>>>>>>>> [EMAIL PROTECTED] >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>>> >>>>>>>>>> We have *WorkEffort* Entity in OFBiz in which we maintain a >>>>>>>>>> recursive >>>>>>>>>> relation ship using attribute *parentWorkEffortId.* >>>>>>>>>> Here we again have the *WorkEffortAssoc *in which we again >>>>>>>>>> relate two >>>>>>>>>> workeffort by using the *workEffortFrom *and* workEffortTo.* >>>>>>>>>> Now my question is like that, if we have a relationship to >>>>>>>>>> relate the >>>>>>>>>> workEffortId by it self ( i.e by an another workEffortId ), >>>>>>>>>> then why we >>>>>>>>>> need >>>>>>>>>> the >>>>>>>>>> *WorkEffortAssoc *for the same purpose. >>>>>>>>>> >>>>>>>>>> *Or it is for handeling a different scenario in (OFBiz Work >>>>>>>>>> Effort Data >>>>>>>>>> Modeling). >>>>>>>>>> ** >>>>>>>>>> * >>>>>>>>>> *Thanks and Regards >>>>>>>>>> [Rishi Solanki]* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ashish Vijaywargiya >>>>>>>>> Indore, India >>>>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ashish Vijaywargiya >>>>>>> Indore, India >>>>>>> http://en.wikipedia.org/wiki/Indore >>>>>>> >>>>>> >>>>> >>>> >> > -- Ashish Vijaywargiya Indore, India http://en.wikipedia.org/wiki/Indore
