Hi, I am also using forums, and if this is implemented then we have to either recreate the Assosciation or do some Data Porting so that the association is corrected .. i also found this strange in the begining but i never got reply for the post i made about 4-5 months ago as one of my forums related question. surely during that time i was not much aware of ofbiz and i continued to use it .... regards G Venkata phanindra.
On 12/11/06, Tim Ruppert <[EMAIL PROTECTED]> wrote:
I've got a bunch of content management usage in one of my sites, but it's all managed in a screens file, so these should not effect me as long as that continues to operate properly. Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6594 On Dec 11, 2006, at 7:41 AM, Al Byers wrote: > David, > > 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 >> >>
-- G.Venkata Phanindra Mob:: 9849852989
