Re: Content management questions

[Leon Torres <le...@oss.minimetria.com>]

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 <ea...@brainfood.com> 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 <jo...@undersunconsulting.com> 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
>>> ean@brainfood.com
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>>
> 
> 

Re: Content management questions

[Al Byers <by...@automationgroups.com>]

On 1/18/07, Leon Torres <le...@oss.minimetria.com> 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 <ea...@brainfood.com> 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 <jo...@undersunconsulting.com> 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
> >>> ean@brainfood.com
> >>> 214-720-0700 x 315
> >>> Brainfood, Inc.
> >>> http://www.brainfood.com
> >>>
> >
> >
>