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
