You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Al Byers <by...@automationgroups.com> on 2007/05/22 19:16:54 UTC
How to structure CMS?
I think it would be helpful to agree on how content management should be
used. I am thinking primarily of things like news articles, blogs, forums,
etc. They all have a lot of similarities and if there were patterns for
designing them, it would allow for more reuse.
Often with website content there is content and then there is a summary
piece that may go on a front page and then points to the main content. In
the past I have used "SUB_CONTENT" as the
ContentAssoc.contentAssocTypeIdvalue from the publish point to the
main content. Then I associate the
summary content to the main content with a
ContentAssoc.contentAssocTypeIdvalue = "SUMMARY". But I can see that
there will be situations in which
things get more complicated, where there will be comments and surveys
attached to the main content. Also, I recently made the main content hang on
the summary because at the time it made more sense.
Question #1: Should ContentAssoc.contentAssocTypeId be used to link the
other types of content to the main content (ie. "COMMENTS", "SURVEYS", etc.)
or should ContentAssoc.contentAssocPredicateId be used (ex. "summarizes",
"comments", etc.) and the contentAssocTypeId always be SUB_CONTENT?
Question #2: How should multiple page content of the same article be
structured? All content associated to the publish point as main content
with incremented ContentAssoc.sequenceNums or should they come off of the
main content and each page extend from the preceding page?
Question #3: Should we do away with the idea of "main content" and make an
"article" a complex, virtual content (sort of a placeholder) off of which
all data content hangs (main, summary, comment, etc.)?
-Al
Re: How to structure CMS?
Posted by David E Jones <jo...@hotwaxmedia.com>.
I'm kinda confused... what is it you are trying to do?
Are you trying to do high level design? If so the best approach would likely be to:
1. research what is currently implemented
2. document all you would like to content stuff do and where the current model doesn't match up
3. fill in the gaps in the design
As for #2, why would multi-page content even be split into different content records? For most cases I think it would make more sense for things to be organized in other ways. Do you have a requirement you're looking at that needs to track the pages separately in the system, ie in different templates or binary documents? Especially for templates these usually just tend to flow and you often don't even know what the page divisions will look like in advance.
-David
Al Byers wrote:
> I think it would be helpful to agree on how content management should be
> used. I am thinking primarily of things like news articles, blogs, forums,
> etc. They all have a lot of similarities and if there were patterns for
> designing them, it would allow for more reuse.
>
> Often with website content there is content and then there is a summary
> piece that may go on a front page and then points to the main content. In
> the past I have used "SUB_CONTENT" as the
> ContentAssoc.contentAssocTypeIdvalue from the publish point to the
> main content. Then I associate the
> summary content to the main content with a
> ContentAssoc.contentAssocTypeIdvalue = "SUMMARY". But I can see that
> there will be situations in which
> things get more complicated, where there will be comments and surveys
> attached to the main content. Also, I recently made the main content
> hang on
> the summary because at the time it made more sense.
>
> Question #1: Should ContentAssoc.contentAssocTypeId be used to link the
> other types of content to the main content (ie. "COMMENTS", "SURVEYS",
> etc.)
> or should ContentAssoc.contentAssocPredicateId be used (ex. "summarizes",
> "comments", etc.) and the contentAssocTypeId always be SUB_CONTENT?
>
> Question #2: How should multiple page content of the same article be
> structured? All content associated to the publish point as main content
> with incremented ContentAssoc.sequenceNums or should they come off of the
> main content and each page extend from the preceding page?
>
> Question #3: Should we do away with the idea of "main content" and make an
> "article" a complex, virtual content (sort of a placeholder) off of which
> all data content hangs (main, summary, comment, etc.)?
>
> -Al
>
Re: How to structure CMS?
Posted by Ean Schuessler <ea...@brainfood.com>.
On Tuesday 22 May 2007 12:16:54 pm Al Byers wrote:
> I think it would be helpful to agree on how content management should be
> used. I am thinking primarily of things like news articles, blogs, forums,
> etc. They all have a lot of similarities and if there were patterns for
> designing them, it would allow for more reuse.
>
> Often with website content there is content and then there is a summary
> piece that may go on a front page and then points to the main content. In
> the past I have used "SUB_CONTENT" as the
> ContentAssoc.contentAssocTypeIdvalue from the publish point to the
> main content. Then I associate the
> summary content to the main content with a
> ContentAssoc.contentAssocTypeIdvalue = "SUMMARY". But I can see that
> there will be situations in which
> things get more complicated, where there will be comments and surveys
> attached to the main content. Also, I recently made the main content hang
> on the summary because at the time it made more sense.
>
> Question #1: Should ContentAssoc.contentAssocTypeId be used to link the
> other types of content to the main content (ie. "COMMENTS", "SURVEYS",
> etc.) or should ContentAssoc.contentAssocPredicateId be used (ex.
> "summarizes", "comments", etc.) and the contentAssocTypeId always be
> SUB_CONTENT?
>
> Question #2: How should multiple page content of the same article be
> structured? All content associated to the publish point as main content
> with incremented ContentAssoc.sequenceNums or should they come off of the
> main content and each page extend from the preceding page?
>
> Question #3: Should we do away with the idea of "main content" and make an
> "article" a complex, virtual content (sort of a placeholder) off of which
> all data content hangs (main, summary, comment, etc.)?
We've spent a little time wrestling with how we would like editing to work.
I've also dug (a little) into JSR283 and Jackrabbit. One thing I like about
JSR283 is that it tries to model content as trees of maps with robust
metadata. We've been doing similar things but on top of CommonsVFS. We bind
the abstract servlet getResource() functions on top of that CommonsVFS
backend. Then we can hook in all kinds of different network and local
filesystems under VFS. Adam and I have definitely talked about binding
CommonsVFS to the content entities. This would allow servlets (even ones that
know nothing about OFBiz) to do standard servlet getResource() kinds of
things and recieve data from Content entities with from/thru date magic and
all that sort of thing.
--
Ean Schuessler, CTO
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: REMOVE ME
Posted by Scott Gray <le...@gmail.com>.
Have you tried sending an email to this address:
dev-unsubscribe@ofbiz.apache.org
It's listed here:
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/
and really is quite simple to find
Regards
Scott
On 24/05/07, PhantomsHorridC <ma...@yahoo.co.uk> wrote:
>
>
> Remove me
>
>
> ---------------------------------
> Copy addresses and emails from any email account to Yahoo! Mail - quick,
> easy and free. Do it now...
REMOVE ME
Posted by PhantomsHorridC <ma...@yahoo.co.uk>.
Remove me
---------------------------------
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. Do it now...
Re: How to structure CMS?
Posted by Chris Howe <cj...@yahoo.com>.
Hi Al,
I've been playing with Apache Xindice on and off over the past weeks
and months. Depending on how you plan on storing/ structuring content,
an integration there may be a better way to go. I haven't thought
about content much, but representing it in an RDBMS on its surface
seems troublesome. Perhaps something along storing some meta data in
the database along with the contentId and leaving the structuring to
the xml database may be workable. Perhaps I just have a new hammer so
everything looks like a nail.
On its surface it seems a better way to store xml content instead of
storing it as a blob in an RDBMS.
Let me know your thoughts.
--- Al Byers <by...@automationgroups.com> wrote:
> I think it would be helpful to agree on how content management should
> be
> used. I am thinking primarily of things like news articles, blogs,
> forums,
> etc. They all have a lot of similarities and if there were patterns
> for
> designing them, it would allow for more reuse.
>
> Often with website content there is content and then there is a
> summary
> piece that may go on a front page and then points to the main
> content. In
> the past I have used "SUB_CONTENT" as the
> ContentAssoc.contentAssocTypeIdvalue from the publish point to the
> main content. Then I associate the
> summary content to the main content with a
> ContentAssoc.contentAssocTypeIdvalue = "SUMMARY". But I can see that
> there will be situations in which
> things get more complicated, where there will be comments and surveys
> attached to the main content. Also, I recently made the main content
> hang on
> the summary because at the time it made more sense.
>
> Question #1: Should ContentAssoc.contentAssocTypeId be used to link
> the
> other types of content to the main content (ie. "COMMENTS",
> "SURVEYS", etc.)
> or should ContentAssoc.contentAssocPredicateId be used (ex.
> "summarizes",
> "comments", etc.) and the contentAssocTypeId always be SUB_CONTENT?
>
> Question #2: How should multiple page content of the same article be
> structured? All content associated to the publish point as main
> content
> with incremented ContentAssoc.sequenceNums or should they come off of
> the
> main content and each page extend from the preceding page?
>
> Question #3: Should we do away with the idea of "main content" and
> make an
> "article" a complex, virtual content (sort of a placeholder) off of
> which
> all data content hangs (main, summary, comment, etc.)?
>
> -Al
>