Content documentation ...

[Ian Gilbert-2]

Hi All,

I am in the process of updating my documentation which was last released a few months ago.  In the
process of doing this it has become apparent that the current article on content management is
misleading and incorrect (apologies to anyone who has spent time on this).  I will either overhaul
this or delete it from the document.  I would much prefer to do the former.  With this in mind I
am looking at the current docs on the cms to see if I can make any progress on my own.  I did this
a while ago and was unsucessful and am writing to enquire if anyone in the know can give me some
help with this or if there are other considerations that I should take into account (say if the
whole project was in the process of being rewritten).

I was thinking that I'd take a sample project (say creating a wiki or news site) and document that
from and end user perspective.  I will be happy to give a co-author credit to anyone who can help
me with this.  There are a number of ways this might happen but I have had a lot of luck with vnc
and direct email in the past :)

I am looking to flesh out other aspects of this document as well.  Currently it is geared up for
drop shipping but the company who currently provides our warehousing services may well become our
next client and so I will be looking to flesh out the stuff about inventory and asset management.
I hope to touch on other applications in due course as well.

Thanks and very best wishes

Ian Gilbert

--
Ian Gilbert
www.ethicalshopper.net
Fair trade: the alternative choice for your everyday shopping
0845 456 2429

WHAT DO YOU DRINK AT WORK?
We can supply your organisation with high quality fair trade tea and
coffee.  Discounts are available for regular orders.  Contact us for more
details.

[byersa]

Ian,

I am the one who probably wrote the documentation of which you speak and
no apologies are needed. It is great that someone is taking an interest
in content management. I had to drop it a while back. I am using it
slightly now, though I am not working with OFBiz full-time at the
moment. I will do whatever I can to help move things along.

I think the sample project idea is good. Perhaps we can pick something
that will build on and exercise Hans's blog upgrade. I wrote a lot of
code to produce the documentation site that was used by Undersun
Consulting. It is similar to the code that is contained in the community
specialized app, which is really just a blogging site. Anyway, I think a
documentation site would be very useful. I would contribute whatever
code I have.

I like the wiki idea too. At my current job, someone introduced a wiki
and said they chose it because it was one of the only J2EE-based wikis
out there. That got me to thinking that it would be nice to have a wiki
feature in OFBiz. In fact, that would probably be a much better
documentation site, than what I did before.

One issue that I see needing resolving at this time is the "direction"
of the ContentAssoc entity. It has a from  field (contentId) and a "to"
field (contentIdTo). In any content managed site, there is the concept
of relating dynamic pieces of content to fixed pieces. This is like a
newspaper where the editorials are always at the same place, but the
content changes. This association is done via the ContentAssoc entity,
which is dated. The problem is that I think I wrongly introduced the
idea that the fixed content would be the "to" component and the dynamic
piece would be the "from".  The contentAssocTypeId for this link is
"PUBLISH_LINK". If I had know, then I think I would have drawn from the
PartyRelationship example, in which the from and to partyIds and roles
are designated based on the direction of the partyRelationshipName (and
partyRelationshipTypeId, which is like the contentAssocTypeId field,
follows the name).
This is taken from the party/data/PartyTypeData.xml file:
    <!-- NOTE: The partyRelationshipName describes the TO party, ie A is
a customer of B, so A is the partyTo and B is the partyFrom -->

So maybe I just contradicted myself, and what is there is correct.
PUBLISH_LINK (the contentAssocTypeId) is sort of the "name" of the
ContentAssoc and that sort of names the "fixed" content, which  by the
statement above, should be the contentIdTo. In any event, this is
something that should be in the documentation.

I know a good bit about the content and I will try to do what I can to
answer any questions and try to take some of the load off of David.

-Al

Ian Gilbert wrote:

> Hi All,
>
> I am in the process of updating my documentation which was last released a few months ago.  In the
> process of doing this it has become apparent that the current article on content management is
> misleading and incorrect (apologies to anyone who has spent time on this).  I will either overhaul
> this or delete it from the document.  I would much prefer to do the former.  With this in mind I
> am looking at the current docs on the cms to see if I can make any progress on my own.  I did this
> a while ago and was unsucessful and am writing to enquire if anyone in the know can give me some
> help with this or if there are other considerations that I should take into account (say if the
> whole project was in the process of being rewritten).
>
> I was thinking that I'd take a sample project (say creating a wiki or news site) and document that
> from and end user perspective.  I will be happy to give a co-author credit to anyone who can help
> me with this.  There are a number of ways this might happen but I have had a lot of luck with vnc
> and direct email in the past :)
>
> I am looking to flesh out other aspects of this document as well.  Currently it is geared up for
> drop shipping but the company who currently provides our warehousing services may well become our
> next client and so I will be looking to flesh out the stuff about inventory and asset management.
> I hope to touch on other applications in due course as well.
>
> Thanks and very best wishes
>
> Ian Gilbert
>
>  

[David E Jones-2]

Al Byers wrote:

> One issue that I see needing resolving at this time is the "direction"
> of the ContentAssoc entity. It has a from  field (contentId) and a "to"
> field (contentIdTo). In any content managed site, there is the concept
> of relating dynamic pieces of content to fixed pieces. This is like a
> newspaper where the editorials are always at the same place, but the
> content changes. This association is done via the ContentAssoc entity,
> which is dated. The problem is that I think I wrongly introduced the
> idea that the fixed content would be the "to" component and the dynamic
> piece would be the "from".  The contentAssocTypeId for this link is
> "PUBLISH_LINK". If I had know, then I think I would have drawn from the
> PartyRelationship example, in which the from and to partyIds and roles
> are designated based on the direction of the partyRelationshipName (and
> partyRelationshipTypeId, which is like the contentAssocTypeId field,
> follows the name).
> This is taken from the party/data/PartyTypeData.xml file:
>    <!-- NOTE: The partyRelationshipName describes the TO party, ie A is
> a customer of B, so A is the partyTo and B is the partyFrom -->
>
> So maybe I just contradicted myself, and what is there is correct.
> PUBLISH_LINK (the contentAssocTypeId) is sort of the "name" of the
> ContentAssoc and that sort of names the "fixed" content, which  by the
> statement above, should be the contentIdTo. In any event, this is
> something that should be in the documentation.

A PartyRelationship is different from a ContentAssoc and no parallel should be drawn between them.

-David

[byersa]

OK, but shouldn't there be some consistent guideline as to how to assign
from and to relationships? What is it in this case?

-Al

David E. Jones wrote:

>
>
> Al Byers wrote:
>> One issue that I see needing resolving at this time is the
>> "direction" of the ContentAssoc entity. It has a from  field
>> (contentId) and a "to" field (contentIdTo). In any content managed
>> site, there is the concept of relating dynamic pieces of content to
>> fixed pieces. This is like a newspaper where the editorials are
>> always at the same place, but the content changes. This association
>> is done via the ContentAssoc entity, which is dated. The problem is
>> that I think I wrongly introduced the idea that the fixed content
>> would be the "to" component and the dynamic piece would be the
>> "from".  The contentAssocTypeId for this link is "PUBLISH_LINK". If I
>> had know, then I think I would have drawn from the PartyRelationship
>> example, in which the from and to partyIds and roles are designated
>> based on the direction of the partyRelationshipName (and
>> partyRelationshipTypeId, which is like the contentAssocTypeId field,
>> follows the name).
>> This is taken from the party/data/PartyTypeData.xml file:
>>    <!-- NOTE: The partyRelationshipName describes the TO party, ie A
>> is a customer of B, so A is the partyTo and B is the partyFrom -->
>>
>> So maybe I just contradicted myself, and what is there is correct.
>> PUBLISH_LINK (the contentAssocTypeId) is sort of the "name" of the
>> ContentAssoc and that sort of names the "fixed" content, which  by
>> the statement above, should be the contentIdTo. In any event, this is
>> something that should be in the documentation.
>
> A PartyRelationship is different from a ContentAssoc and no parallel
> should be drawn between them.
>
> -David
>

[davidnwelton]

> I like the wiki idea too. At my current job, someone introduced a wiki
> and said they chose it because it was one of the only J2EE-based wikis
> out there. That got me to thinking that it would be nice to have a wiki
> feature in OFBiz. In fact, that would probably be a much better
> documentation site, than what I did before.

IMO, it's a good idea to be kind of careful with stuff like this.
Most companies are going to want the 'best of breed' for each app they
have, so might not be too interested in something basic.  The problem
is when they are evaluating - if they see too much 'toy' stuff around
the core app, it may give a more negative impression than if they see
a solid app that does what it does well.

Anyway, just my two cents...

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[Andrew Sykes]

That's a fair point,

But there is a counter argument too.

i.e. the more commonly used applications that OFBiz makes available the
more likely it is that developers are going to consider it worth their
time to learn OFBiz.

I think this is an important point given the scale of the time
investment you are asking a developer to commit.

- Andrew

On Wed, 2006-07-05 at 11:53 +0200, David Welton wrote:

> > I like the wiki idea too. At my current job, someone introduced a wiki
> > and said they chose it because it was one of the only J2EE-based wikis
> > out there. That got me to thinking that it would be nice to have a wiki
> > feature in OFBiz. In fact, that would probably be a much better
> > documentation site, than what I did before.
>
> IMO, it's a good idea to be kind of careful with stuff like this.
> Most companies are going to want the 'best of breed' for each app they
> have, so might not be too interested in something basic.  The problem
> is when they are evaluating - if they see too much 'toy' stuff around
> the core app, it may give a more negative impression than if they see
> a solid app that does what it does well.
>
> Anyway, just my two cents...
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[Walter Vaughan]

Andrew Sykes wrote:

> That's a fair point,
>
> But there is a counter argument too.
>
> i.e. the more commonly used applications that OFBiz makes available the
> more likely it is that developers are going to consider it worth their
> time to learn OFBiz.

As a rank newbie I have to agree heartly.

If I need to get a package across the globe... I'd rather work with a FedEx or
UPS who have ships, planes, trains, trucks, and segways who will perform
nominally at every stage of the delivery versus trying to coordinate working
with individual specialists.

I'll give up a little to avoid having to link up a mulitple best of breed
methods with their tightly wound and strong navel gazing tendencies.

 From my perspective, even proof of concept quality applications while
frustrating to just install and use, offer much in making the case for ofBiz.