I'm currently using "persistContentAndAssoc" on a major site scheduled to roll out in February. This may be the highest profile site we've done with OFBiz and, therefore, one of the highest profile OFBiz sites ever. I'm working from a branch (as is our habit) that I forked at the beginning of development so I won't be impacted by changes immediately. I would like to stay in step with the status quo.
Please don't take a offense but the content management code is rather rough. Formatting (tabbing) is inconsistent and large sections of commented out code are in the source. Is this necessary since we are using revision control? The permission checking code could stand to be a little clearer as well. I think I've gotten the jist of what it is looking for but I'm still somewhat confused about how auxiliaryConditionId is meant to be used. In general I like quite a few of the ideas that you are working with. Unfortunately the complexity and flexibility of the infrastructure renders the management system virtually unusable by normal users. I think that is probably mostly an interface problem and a lack of documentation but we are going to need to manifest the functionality in a more usable form. That critique, however, applies to quite a few areas of OFBiz beyond content management. On Monday 11 December 2006 08:41, Al Byers wrote: > I have looked some more at this, and the scope of the changes will be > larger than I estimated. I have views setup that use the opposite > meaning of "From" and they are used about 36 places for "From" and the > same for "To". The current implementations (ie. mine) take "From" to > mean that the "parent" is contentIdTo and the child is "contentId". Up > until this time, every place that I have implemented ContentAssoc has > used that rule. > > I don't think the actual changes to OFBiz will take all that much time > - maybe 4 hours, but I do think it will break the code of anyone who > has implemented any content management. Of course, that could be > almost nobody at this point. > > I think I will change the definition of the views so that they match > the "contentId and mapKey going 'to' contentIdTo" flow. Then I will > look for the places that direction is set and reverse them. Then I > will try to fix ecommerce forums if they are broken from this. And I > will look at the admin screens. > > I have not heard anyone complain about this, but then I will copy the > user list, since this is going to become a user issue if anyone is > using content management. > > -Al > > On 12/11/06, David E Jones <[EMAIL PROTECTED]> wrote: > > On Dec 9, 2006, at 9:50 PM, Al Byers wrote: > > > David, > > > > > > I am getting back into the content management code and I see in > > > ContentWorker that you changed the direction of sub-content so that > > > "contentId" is the "parent" and "contentIdTo" is the child. > > > > > > // NOTE DEJ20060610: Changed "From" to "To" because it > > > makes the most sense for sub-content renderings using a root-contentId > > > and mapKey to determine the sub-contentId to have the ContentAssoc go > > > from the root to the sub, ie try to determine the contentIdTo from the > > > contentId and mapKey > > > // This shouldn't be changed from "To" to "From", but if > > > desired could be parameterized to make this selectable in higher up > > > calling methods > > > > > > I like that reasoning; I never could formulate a justification for > > > doing it one way or the other. Unfortunately, some of my content > > > management code was written in the reverse. Primarily, that would be > > > the "persistContentAndAssoc" service. It takes in "contentId" or > > > returns it if it is a create. The service will take in the value of > > > the parent Content to which the created content will link, so I used > > > "contentIdTo" (the reverse of what your logic would be) just because I > > > was using "contentId" for the newly generated Content. > > > > > > There are all that many places to change and I am glad to have a > > > "rule" so I don't mind changing it. It will probably break the code of > > > anyone using "persistContentAndAssoc" and that is part of the reason > > > for sending this to the list. But I doubt if many people are using it; > > > it should probably be refactored soon. So I will go and tweak it (add > > > a new parameter - contentIdFrom - INOUT) to pass in and out a new > > > parameter for the parent Content ID - unless I hear differently. > > > > As I think about this more I like the idea of having a single > > convention and not introduce or support this extra flexibility. My > > guess is it will just be confusing and lead to user and/or programmer > > errors over time. > > > > So, the basic idea with associated content looked up by map-key you > > have a contentId and a map-key and from those two, and using the > > current date/time, you would look up a contentIdTo. > > > > If we just stick to this I don't think we'll need the contentIdFrom > > thingy, but I may not be getting all of what you were trying to > > accomplish with that. > > -David -- Ean Schuessler, CTO [EMAIL PROTECTED] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
