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