jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alartin <alar...@gmail.com>
Subject Re: Node mapping question: when should I use subnode?
Date Fri, 23 Mar 2007 02:14:56 GMT

Hi Jukka,

Thanks for you patience and explanation.
In my case, the common features of question, answer and comment are:
1. date
2. content
3. author(only one)
question must has a title but answer and comment not. And only question has
tags and state/status
So, would the below definition be better?

[my:content] > nt:hierarchyNode  // inherit its jcr:created property
    - content (STRING) mandatory
    - author (REFERENCE)  mandatory < my:user

 [my:question] > my:content orderable
    - title (string) mandatory // case insensitive to type?
    - tags (REFERENCE) multiple mandatory < my:tag
    - status (REFERENCE) mandatory < my:state
    + * (my:answer)  // same as + my:answer multiple ?

[my:answer] > my:content
    - best (boolean) mandatory // whether this is the best answer
    - vote (int) mandatory // vote number count from users

Jukka Zitting wrote:
> Hi,
> On 3/22/07, alartin <alartin@gmail.com> wrote:
>> Thanks for your reply. I wanna write a simple QnA(like yahoo answers, but
>> much more simpler) demo of jackrabbit. Every question have tags and user
>> can
>> find questions by search box, by status(open,voting,close) or by tag. And
>> also, newest questions, the hottest questions(ranked by the  number of
>> answers),  the users with the highest scores are shown in the frontpage.
>> There will be a timer to calculate all the infomration above.
> OK, thanks for the details. It sounds like a date-based hierarchy
> could work for you. It wouldn't be directly applicable in the user
> interface perspective, but would make administration easy and would
> give you a fast way to build the list of most recent questions.
> I would go for a main structure like this:
>     /my:content
>     /my:content/tags
>     /my:content/tags/<tag>
>     /my:content/users
>     /my:content/users/<user>
>     /my:content/workflow
>     /my:content/workflow/<status>
>     /my:content/content
>     /my:content/content/<yyyy>/<mm>/<question>
>     /my:content/content/<yyyy>/<mm>/<question>/<answer>
> The /my:content root node is for a clean separation from /jcr:system
> and any other content applications you may want to store within the
> same workspace.
> The second level (tags, users, workflow, content) is for partitioning
> your content by type. In future you might want to generalize these
> parts into standalone /my:tags, etc. components that could be used
> with all sorts of content applications.
> Tags would be referenceable nodes with whatever metadata properties
> you may want to associate with them. If you want, you could also have
> a tag hierarchy. Question and answer nodes would have a multivalued
> "tags" reference property that points to the associated tags. The tag
> nodes would be named by the tag name
> User nodes would contain whatever user information you want to store.
> They would also be referenceable, and you'd have an "author" property
> (or perhaps "authors") on the question and answer nodes for linking to
> the associated user. User nodes would be named by the username.
> The workflow nodes would be used just like tags for tracking the
> status of a question. You'd have three referenceable workflow nodes
> ("open", "voting", "close") and a single-valued "status" property on
> the question (and answer?) nodes. This gives you a quick way to list
> all nodes in a given state, and also allows you to easily extend the
> workflow model if needed. You can also attach all sorts of extra
> metadata on the workflow nodes.
> The actual content nodes, questions and answers, would be distributed
> into a date-based <yyyy>/<mm> tree hierarchy to simplify
> administration and to avoid making the content structure too flat.
> These content nodes would have the above-mentioned reference
> properties and of course any "title" and "content" properties and
> extra metadata you need. If you want you could also allow binary
> attachments. The content nodes would be named by the title
> (potentially encoded) of the node for easy administration and URL
> mapping.
> A quick and dirty shot at node typing would be:
>     [my:user] > mix:referenceable
>     [my:tag] > mix:referenceable
>     [my:state] > mix:referenceable
>     [my:content]
>     - title (STRING) mandatory
>     - content (STRING) mandatory
>     - tags (REFERENCE) multiple mandatory < my:tag
>     - authors (REFERENCE) multiple mandatory < my:user
>     - status (REFERENCE) mandatory < my:state
>     [my:question] > my:content orderable
>     + * (my:answer)
>     [my:answer] > my:content
> You might also want to consider making the types extend
> nt:hierarchyNode in which case you could use nt:folder nodes for the
> intermediate structure, and also achieve extra interoperability with
> generic JCR clients.
>> I am eager to hear advices from experts like you. Many thanks again.
> You're welcome. It's great to have such a content modeling discussion,
> I believe there are many people who are very interested in these
> concepts.
> BR,
> Jukka Zitting

View this message in context: http://www.nabble.com/Node-mapping-question%3A-when-should-I-use-subnode--tf3439621.html#a9627954
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message