jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: jackrabbit-jcr-demo. Another idea.
Date Sat, 07 Apr 2007 07:02:46 GMT
Hi,

On 4/2/07, Pavel Konnikov <konnikov@gmail.com> wrote:
> I have also submit an application on the subject ?jackrabbit-jcr-demo?.

Excellent, thanks! I'm sorry for the late response, I was partly
offline this week.

> Imho demo-application like blog or wiki are unsuitable. That's the reason:
> just imagine what would gonna be when we first start your blog! An entry
> like "Hello, world!"? Or you run wiki and see an empty toc? Who will be
> interested in that?

Well, the idea is to showcase JCR features and using an application
where everyone already knows the basic content model and feature set
probably makes things easier. But that's not a strict requirement, I'd
be happy to mentor also other types of demo applications.

> I propose to discuss the other idea - testing system. Simplified, of
> course.

Sounds good! Some comments below.

> The application should allow users to pass the test they have choosen.
> A test includes set of questions, has It's title and contains information
> about their author, publication date and version. Each question contains
> a question text, additional resources (ex. images), fixed mark for correct
> answer and answer variants. An answer variant contains an answer in
> the true sence and boolean variable - if it's true or false. All resources are
> simple files.

OK. Do you plan to keep also test results in the repository?

> All tests are organized by exact topics. Each topic contains tests, oriented
> on this topic. Each topic contains references to corresponded tests.

Instead of using references, would it make more sense to use the tree
structure for the topic-test relationships? Something like
/mu:tests/<topic>/<test>. Or is it possible to have multiple topics
for a single test?

> Also the system has It's users. Each user represents information about his
> login, password and for example full name.

OK.

> System also has an admin that can add question packages, to form (assamly)
> tests of them, to create new topics and to add tests to different topics.

OK.

> [mu:root] > rep:root
>    + questions (mu:questions)
>    + tests (mu:tests)
>    + topics (mu:topics)
>    + users (mu:users)

Using a content root for your application is good practice, but I'd
rather use a normal nt:folder node instead of specifying a custom node
type. Using nt:folder allows you to easily add other content subtrees
later on, and also works better with existing browser tools.

> [mu:questions] > nt:folder

Is it possible for a single question to appear in more than one test?
If yes, then having a separate "questions" tree is OK, otherwise I'd
put the questions as subnodes of the test that they belong in.

>    + question (mu:question)

The nt:folder node already has a residual nt:hierarchyNode child node
definition. I'd rather use that instead of a custom child node
definition.

>    - author (String)
>    - date (Date)

Do you need these properties on the top-level questions node? Or would
they be more appropriate for the "question package" concept you
mentioned?

> [mu:question] > nt:folder
>    + answer (mu:answer)
>    + image (nt:file)
>    - text (String)
>    - weight (Long)

I would again use the existing residual child node definition in
nt:folder instead of the custom "answer" and "image" definitions. Just
decide that all mu:answer child nodes of the folder are the answer
options, and that all other child nodes are images or other resources
associated with the question.

Also, if you want to have a single question appear in more than one
test, you should make the question nodes referenceable.

    [mu:question] > nt:folder, mix:referenceable
    - text (STRING) mandatory primary
    - weight (LONG) mandatory

BTW, I would assume that the "weight" of a question would be relative
to a test in which the question appearsh.

> [mu:answer] > nt:resource
>    - text (String)
>    - isRight (Boolean)

Using nt:hierarchyNode is probably more appropriate than nt:resource,
unless you want the answers to contain a binary document.

    [mu:answer] > nt:hierarchyNode
    - text (STRING) mandatory primary
    - correct (BOOLEAN) mandatory

> [mu:tests] > nt:folder
>    + test (mu:test)

You can (should) use the normal nt:folder node when there is no
specific need for a subtype.

> [mu:test] > nt:folder
>    + question (mix:referencable)
>    - title (String)

Assuming you want to allow a single question to appear in multiple
tests, the following type definition would be more appropriate:

    [mu:test] > nt:hierarchyNode
    - title (STRING) mandatory primary
    - questions (REFERENCE) mandatory multiple < 'mu:question'

Also, as discussed for tagging in Nandana's proposal, it would
probably make sense to have the test nodes reference the topics
associated with the test:

    - topics (REFERENCE) mandatory multiple < 'mu:topic'

> [mu:topics] > nt:folder
>    + topic (mu:topic)

No need for a custom node type where nt:folder is good enough.

> [mu:topic] > nt:folder
>    + test (mix:referencable)
>    - theme (String)

I believe the following type definition would be more appropriate:

    [mu:topic] > nt:hierarchyNode, mix:referenceable
    - theme (STRING) mandatory primary

> [mu:users] > nt:folder
>    + user (mu:user)

Again, no need for a custom node type where nt:folder is good enough.

> [mu:user] > nt:resource
>    - login (String)
>    - password (String)
>    - fullName (String)

It would make more sense for the user node type to descend from
nt:hierarchyNode (and mix:referenceable) instead of nt:resource.

BR,

Jukka Zitting

Mime
View raw message