Re: Content management questions

[byersa]

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 <[hidden email]> 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
>
>

[Tim Ruppert]

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 <[hidden email]> 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]

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 <[hidden email]> 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 <[hidden email]> 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:: [phone]