Content management questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Content management questions

byersa
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.

And can you copy me directly - I am still having trouble seeing my
posts to the list. Also, do I still have commit privileges? There will
be a lot of little stuff to do.

-Al
Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

David E Jones-2

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.

> And can you copy me directly - I am still having trouble seeing my
> posts to the list. Also, do I still have commit privileges? There will
> be a lot of little stuff to do.

Do you have a spam filter on? You might want to check and see if the  
mailing list address was added to a blacklist, or if it is a local  
spam filter in a client just find the messages and manually set them  
as not junk.

Anyway, no problem, you're copied on this one at least.

-David

Reply | Threaded
Open this post in threaded view
|

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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

Ean Schuessler
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 <[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

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

byersa
Ean,

I did not see this before responding. I agree that my cm code is
unnecessarily rough. It is long overdue for a clean up and now is
looking like a good time to do it.

I will explain what I am doing with persistContentAndAssoc (which is
the roughest piece of all, so I am surprised that you are using it
:0). It is closely tied to what is the "order" of the ContentAssoc
contentId/To fields. Much of what is coded now assumes that when there
is subcontent, that contentId = child content and contentIdTo = parent
conent. David feels like this is the wrong order and I agree that it
is more intuitive to assume that say the contentId and mapKey combine
to point "to" contentIdTo.

One problem with persistContentAndAssoc is that it is sometime used to
generate or update Content entities and it made sense to use contentId
as the value for Content and then I chose to use contentIdTo for the
parent content id, since that way I could let them join on "contentId"

persistContentAndAssoc has evolved in an ugly way. I intended it to be
a do-all service that would be easy to use - in that it would look at
what data was coming in and do the right thing. It is supposed to
handle the common case where the user wants to create content and
attach it to a parent. Unfortunately, that meant that I ended up
allowing a huge parameter input and output set.

Maybe the thing to do is define a new service to do what
persistContentAndAssoc does.

I do think it is important to clear up the "directional" issue.

-Al

On 12/11/06, Ean Schuessler <[hidden email]> wrote:

> 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 <[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
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

David E Jones-2

Yes, a lot of the content management code is pretty messy, but what  
worries me more about it is that a lot of it was developed without a  
very specific use in mind, which I guess is what makes a lot of it so  
messy. Fortunately I'm guessing a lot of the lower level content code  
is not being used and can be pruned.

With other stuff, like persistContentAndAssoc, there might be cleaner  
ways of doing it that would also be simpler by reusing the service to  
create a content and just have something to easily attach it to a  
parent content record. A service that does both could be created and  
inherit from the service definitions, call both services, etc.

-David


On Dec 11, 2006, at 11:54 AM, Al Byers wrote:

> Ean,
>
> I did not see this before responding. I agree that my cm code is
> unnecessarily rough. It is long overdue for a clean up and now is
> looking like a good time to do it.
>
> I will explain what I am doing with persistContentAndAssoc (which is
> the roughest piece of all, so I am surprised that you are using it
> :0). It is closely tied to what is the "order" of the ContentAssoc
> contentId/To fields. Much of what is coded now assumes that when there
> is subcontent, that contentId = child content and contentIdTo = parent
> conent. David feels like this is the wrong order and I agree that it
> is more intuitive to assume that say the contentId and mapKey combine
> to point "to" contentIdTo.
>
> One problem with persistContentAndAssoc is that it is sometime used to
> generate or update Content entities and it made sense to use contentId
> as the value for Content and then I chose to use contentIdTo for the
> parent content id, since that way I could let them join on "contentId"
>
> persistContentAndAssoc has evolved in an ugly way. I intended it to be
> a do-all service that would be easy to use - in that it would look at
> what data was coming in and do the right thing. It is supposed to
> handle the common case where the user wants to create content and
> attach it to a parent. Unfortunately, that meant that I ended up
> allowing a huge parameter input and output set.
>
> Maybe the thing to do is define a new service to do what
> persistContentAndAssoc does.
>
> I do think it is important to clear up the "directional" issue.
>
> -Al
>
> On 12/11/06, Ean Schuessler <[hidden email]> wrote:
>> 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 <[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
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>

Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

Leon Torres-2
I'm raising this thread from the dead because I'm currently working on a file
attachment feature for CRMSFA and would like to know some more about it.

First, it there some document that could help identify what entities and fields
are canonical in the Content system and what is special purpose?  I'd like to
avoid using fields that are not being used anywhere or will be refactored.

Second, I've noticed that uploaded content is stored on the filesystem.  I was
wondering if there was an alternative approach in storing Blobs instead?  Is
there code to serve Blob or files to the user so they can download the content?

- Leon


David E Jones wrote:

>
> Yes, a lot of the content management code is pretty messy, but what
> worries me more about it is that a lot of it was developed without a
> very specific use in mind, which I guess is what makes a lot of it so
> messy. Fortunately I'm guessing a lot of the lower level content code is
> not being used and can be pruned.
>
> With other stuff, like persistContentAndAssoc, there might be cleaner
> ways of doing it that would also be simpler by reusing the service to
> create a content and just have something to easily attach it to a parent
> content record. A service that does both could be created and inherit
> from the service definitions, call both services, etc.
>
> -David
>
>
> On Dec 11, 2006, at 11:54 AM, Al Byers wrote:
>
>> Ean,
>>
>> I did not see this before responding. I agree that my cm code is
>> unnecessarily rough. It is long overdue for a clean up and now is
>> looking like a good time to do it.
>>
>> I will explain what I am doing with persistContentAndAssoc (which is
>> the roughest piece of all, so I am surprised that you are using it
>> :0). It is closely tied to what is the "order" of the ContentAssoc
>> contentId/To fields. Much of what is coded now assumes that when there
>> is subcontent, that contentId = child content and contentIdTo = parent
>> conent. David feels like this is the wrong order and I agree that it
>> is more intuitive to assume that say the contentId and mapKey combine
>> to point "to" contentIdTo.
>>
>> One problem with persistContentAndAssoc is that it is sometime used to
>> generate or update Content entities and it made sense to use contentId
>> as the value for Content and then I chose to use contentIdTo for the
>> parent content id, since that way I could let them join on "contentId"
>>
>> persistContentAndAssoc has evolved in an ugly way. I intended it to be
>> a do-all service that would be easy to use - in that it would look at
>> what data was coming in and do the right thing. It is supposed to
>> handle the common case where the user wants to create content and
>> attach it to a parent. Unfortunately, that meant that I ended up
>> allowing a huge parameter input and output set.
>>
>> Maybe the thing to do is define a new service to do what
>> persistContentAndAssoc does.
>>
>> I do think it is important to clear up the "directional" issue.
>>
>> -Al
>>
>> On 12/11/06, Ean Schuessler <[hidden email]> wrote:
>>> 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 <[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
>>>
>>> --
>>> Ean Schuessler, CTO
>>> [hidden email]
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Content management questions

byersa
On 1/18/07, Leon Torres <[hidden email]> wrote:

>
> I'm raising this thread from the dead because I'm currently working on a
> file
> attachment feature for CRMSFA and would like to know some more about it.
>
> First, it there some document that could help identify what entities and
> fields
> are canonical in the Content system and what is special purpose?  I'd like
> to
> avoid using fields that are not being used anywhere or will be refactored.


I can't help you much here. There will be a refactoring, but I don't think
the general examples will change all that much.

Second, I've noticed that uploaded content is stored on the filesystem.  I
> was
> wondering if there was an alternative approach in storing Blobs
> instead?  Is
> there code to serve Blob or files to the user so they can download the
> content?


There is a DataResource.dataResourceTypeId  that controls whether or not the
content is saved to the file system or the database.
-Al

- Leon

>
>
> David E Jones wrote:
> >
> > Yes, a lot of the content management code is pretty messy, but what
> > worries me more about it is that a lot of it was developed without a
> > very specific use in mind, which I guess is what makes a lot of it so
> > messy. Fortunately I'm guessing a lot of the lower level content code is
> > not being used and can be pruned.
> >
> > With other stuff, like persistContentAndAssoc, there might be cleaner
> > ways of doing it that would also be simpler by reusing the service to
> > create a content and just have something to easily attach it to a parent
> > content record. A service that does both could be created and inherit
> > from the service definitions, call both services, etc.
> >
> > -David
> >
> >
> > On Dec 11, 2006, at 11:54 AM, Al Byers wrote:
> >
> >> Ean,
> >>
> >> I did not see this before responding. I agree that my cm code is
> >> unnecessarily rough. It is long overdue for a clean up and now is
> >> looking like a good time to do it.
> >>
> >> I will explain what I am doing with persistContentAndAssoc (which is
> >> the roughest piece of all, so I am surprised that you are using it
> >> :0). It is closely tied to what is the "order" of the ContentAssoc
> >> contentId/To fields. Much of what is coded now assumes that when there
> >> is subcontent, that contentId = child content and contentIdTo = parent
> >> conent. David feels like this is the wrong order and I agree that it
> >> is more intuitive to assume that say the contentId and mapKey combine
> >> to point "to" contentIdTo.
> >>
> >> One problem with persistContentAndAssoc is that it is sometime used to
> >> generate or update Content entities and it made sense to use contentId
> >> as the value for Content and then I chose to use contentIdTo for the
> >> parent content id, since that way I could let them join on "contentId"
> >>
> >> persistContentAndAssoc has evolved in an ugly way. I intended it to be
> >> a do-all service that would be easy to use - in that it would look at
> >> what data was coming in and do the right thing. It is supposed to
> >> handle the common case where the user wants to create content and
> >> attach it to a parent. Unfortunately, that meant that I ended up
> >> allowing a huge parameter input and output set.
> >>
> >> Maybe the thing to do is define a new service to do what
> >> persistContentAndAssoc does.
> >>
> >> I do think it is important to clear up the "directional" issue.
> >>
> >> -Al
> >>
> >> On 12/11/06, Ean Schuessler <[hidden email]> wrote:
> >>> 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 <[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
> >>>
> >>> --
> >>> Ean Schuessler, CTO
> >>> [hidden email]
> >>> 214-720-0700 x 315
> >>> Brainfood, Inc.
> >>> http://www.brainfood.com
> >>>
> >
> >
>