You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Pavel Konnikov <ko...@gmail.com> on 2007/04/02 09:02:20 UTC
jackrabbit-jcr-demo. Another idea.
Hello,
I have also submit an application on the subject ?jackrabbit-jcr-demo?.
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?
I propose to discuss the other idea - testing system. Simplified, of
course.
This is the short description of domain problem:
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.
All tests are organized by exact topics. Each topic contains tests,
oriented on this topic. Each topic contains
references to corresponded tests.
Also the system has It's users. Each user represents information about his
login, password and for example full name.
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.
Find my application on http://konnikov.net/GSoC/2007/jackrabbit-jcr-demo/
Thinking in testing system CND:
<mu = 'http://www.konnikov.net/GSoC/2007/jackrabbit-jcr-demo/0.1'>
[mu:root] > rep:root
+ questions (mu:questions)
+ tests (mu:tests)
+ topics (mu:topics)
+ users (mu:users)
[mu:questions] > nt:folder
+ question (mu:question)
- author (String)
- date (Date)
[mu:question] > nt:folder
+ answer (mu:answer)
+ image (nt:file)
- text (String)
- weight (Long)
[mu:answer] > nt:resource
- text (String)
- isRight (Boolean)
[mu:tests] > nt:folder
+ test (mu:test)
[mu:test] > nt:folder
+ question (mix:referencable)
- title (String)
[mu:topics] > nt:folder
+ topic (mu:topic)
[mu:topic] > nt:folder
+ test (mix:referencable)
- theme (String)
[mu:users] > nt:folder
+ user (mu:user)
[mu:user] > nt:resource
- login (String)
- password (String)
- fullName (String)
--
Best regards. Pavel Konnikov
Re: jackrabbit-jcr-demo. Another idea.
Posted by Pavel Konnikov <ko...@gmail.com>.
On Mon, 09 Apr 2007 10:00:24 +0400, Jukka Zitting
<ju...@gmail.com> wrote:
> just wanted to
> check if you had planned something like that since it would affect
> content modeling at least somewhat.
The results could be kept with different range of refining. It's possible
to keep not only result mark but also full
information about each exact answer too.
The easiest variant is something like this:
...
mu-root/results (nt:folder)
mu-root/results/result (mu:result)
[mu:result] > nt:hierarchyNode, mix:referenceable
- ball (LONG) mandatory primary
- date (DATE) mandatory
- test (REFERENCE) mandatory < 'mu:test'
- user (REFERENCE) mandatory < 'mu:user'
More detailed variant is:
It's necessary to add mix:referenceable to mu:answer declaration, change
declaration mu:result in this way:
[mu:result] > nt:hierarchyNode, mix:referenceable
- ball (LONG) mandatory
- date (DATE) mandatory
- test (REFERENCE) mandatory < 'mu:test'
- user (REFERENCE) mandatory < 'mu:user'
add new nodes to the tree:
mu-root/results/result/user-answers (nt:folder)
mu-root/results/result/user-answers/user-answer (mu:user-answer)
add declaration:
[mu:user-answer] > nt:hierarchyNode
- ball (LONG) mandatory
- question (REFERENCE) mandatory < 'mu:question'
- selected-answer (REFERENCE) mandatory multiple < 'mu:answer'
> References in JCR are essentially two-way relations that you can
> traverse both ways, using Property.getNode() and Node.getReferences().
> This allows the reference properties to be placed on either end of the
> relation.
Imho, that doesn't guarantee consistency.
> In your content model a test "has a" topic (or topics), but there's
> nothing inherent in topic model that says it only applies to tests.
Not exactly like this. Perhaps I'm not clear in stating my thoughts. I'll
try to change that:
Test could refer to one or more topics, exactly
Topic "has a" many tests.
Test is one of tests in the topic.
I think we should avoid unreasonable difficulties - relations like
"many-to-many".
The model should be clear. Moreover tests would be shown by cathegories on
page; this is only necessary to choose the
exact test.
If keeping references to topics in tests is principal, I can offer scheme
variant, answering requirements.
[mu:test] > nt:hierarchyNode, mix:referenceable
- title (STRING) mandatory primary
- question (REFERENCE) mandatory multiple < 'mu:question'
- topic (REFERENCE) mandatory multiple < 'mu:topic'
[mu:topic] > nt:hierarchyNode, mix:referenceable
- theme (STRING)
- test (REFERENCE) mandatory multiply < 'mu:test'
> For example it would be perfectly reasonable to use topics also to
> categorize the question packages. Instead of adding a separate "-
> packages (REFERENCE) < 'my:question-package'" property definition to
> the topic node definition, it makes more sense to add a "- topics
> (REFERENCE) < 'mu:topic'" property to the question package nodes.
I'm sure it's redundant. A package could contain questions that don't deal
to each other. Although it's a mistake,
but theoretically it's possible.
I hope at last we would find common optimal decision.
--
Best regards. Pavel Konnikov
Re: jackrabbit-jcr-demo. Another idea.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 4/8/07, Pavel Konnikov <ko...@gmail.com> wrote:
> On Sat, 07 Apr 2007 11:02:46 +0400, Jukka Zitting <ju...@gmail.com> wrote:
> > Do you plan to keep also test results in the repository?
>
> Initially I didn't plan to keep information of test resulting, cause I
> think it would complicate demo-application. In case of need It would
> be possible to realize result keeping.
OK. I don't think it's needed for the demo application, just wanted to
check if you had planned something like that since it would affect
content modeling at least somewhat.
> > BTW, I would assume that the "weight" of a question would be relative
> > to a test in which the question appearsh.
>
> The maximum for the test would result of simple sum of results for each
> question. I agree that the information of how much put to the question in
> each test (That would depend on the test complexity) should be pointed
> at test forming. As we are trying to simplify most things, we could leave
> this and settle the question point static at the place it would be kept.
OK, sounds good.
> > 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'
>
> Should I keep the information about test topic? I'll try to explain why shouldn't
> You do that. Imagine the situation of "JSP & Servlets" test existence. The
> topics "Java programming", "Web programming" exist. It's clear, that reference
> to test "JSP & Servlets" would be both in the topic "Java programming" and
> "Web programming". But in the test by itself there would be only reference on
> topic "Java programming" and no reference on "Web programming". The problem
> of consistency information support appears. In that case you'd better leave
> one-way relation: topic -> tests.
References in JCR are essentially two-way relations that you can
traverse both ways, using Property.getNode() and Node.getReferences().
This allows the reference properties to be placed on either end of the
relation.
In your content model a test "has a" topic (or topics), but there's
nothing inherent in topic model that says it only applies to tests.
For example it would be perfectly reasonable to use topics also to
categorize the question packages. Instead of adding a separate "-
packages (REFERENCE) < 'my:question-package'" property definition to
the topic node definition, it makes more sense to add a "- topics
(REFERENCE) < 'mu:topic'" property to the question package nodes.
Alternatively you should generalize the mu:topic definition to allow
reference to any mix:referenceable nodes.
> Repository sturcture example (in path-view):
> [...]
> Custom types in CND:
> [...]
Looks very good, thanks!
BR,
Jukka Zitting
Re: jackrabbit-jcr-demo. Another idea.
Posted by Pavel Konnikov <ko...@gmail.com>.
Hello,
On Sat, 07 Apr 2007 11:02:46 +0400, Jukka Zitting
<ju...@gmail.com> wrote:
> Do you plan to keep also test results in the repository?
Initially I didn't plan to keep information of test resulting, cause I
think it would complicate demo-application.
In case of need It would be possible to realize result keeping.
> 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?
No doubt the situation when one test refers to different topics is
possible. For example, "JSP & Servlets" test refers
to "Java programming" and to "Web programming".
> 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.
Of course questions and test are different entities. Questions don't
always need to be in a test. But always should be in "question package",
cause the only way of adding questions in the test is realized by means of
packages.
>> - 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?
It's my fault. Of course not author of "questions" - author of "question
package".
I have changed that. See below.
> BTW, I would assume that the "weight" of a question would be relative
> to a test in which the question appearsh.
The maximum for the test would result of simple sum of results for each
question. I agree that the information of how
much put to the question in each test (That would depend on the test
complexity) should be pointed at test forming. As
we are trying to simplify most things, we could leave this and settle the
question point static at the place it would be
kept.
> 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'
Should I keep the information about test topic?
I'll try to explain why shouldn't You do that.
Imagine the situation of "JSP & Servlets" test existence.
The topics "Java programming", "Web programming" exist.
It's clear, that reference to test "JSP & Servlets" would be both in the
topic "Java programming" and "Web programming".
But in the test by itself there would be only reference on topic "Java
programming" and no reference on "Web
programming".
The problem of consistency information support appears.
In that case you'd better leave one-way relation: topic -> tests.
Particularly because tests would be overlooked by
categories and if keep the topic tree, It wouldn't need to be generated in
contrast to keep the topics by simple list
when each test keeps references on topics.
Repository sturcture example (in path-view):
mu-root (nt:folder)
mu-root/questions-packages (nt:folder)
mu-root/questions-packages/questions-package (mu:question-package)
mu-root/questions-packages/questions-package/question (mu:question)
mu-root/questions-packages/questions-package/question/answer (mu:answer)
mu-root/questions-packages/questions-package/question/image (nt:file)
mu-root/tests (nt:folder)
mu-root/tests/test (mu:test)
mu-root/topics (nt:folder)
mu-root/topics/topic (mu:topic)
mu-root/users (nt:folder)
mu-root/users/user (mu:user)
Repository sturcture example in tree-view:
mu-root (nt:folder)
|
+- questions-packages (nt:folder)
| |
| +- questions-package (mu:question-package)
| | |
| | +- question (mu:question)
| | | |
| | | +- answer (mu:answer)
| | | |
| | | +- ...
| | | |
| | | +- answer (mu:answer)
| | | |
| | | +- image (nt:file)
| | | |
| | | +- ...
| | | |
| | | +- image (nt:file)
| | |
| | +- ...
| | |
| | +- question (mu:question)
| |
| +- ...
| |
| +- questions-package (nt:folder)
|
+- tests (nt:folder)
| |
| +- test (mu:test)
| |
| +- ...
| |
| +- test (mu:test)
|
+- topics (nt:folder)
| |
| +- topic (mu:topic)
| |
| +- ...
| |
| +- topic (mu:topic)
|
+- users (nt:folder)
|
+- user (mu:user)
|
+- ...
|
+- user (mu:user)
Custom types in CND:
<mu = 'http://www.konnikov.net/GSoC/2007/jackrabbit-jcr-demo/0.1'>
[mu:question-package] > nt:folder
- author (STRING)
- date (DATE)
[mu:question] > nt:folder, mix:referenceable
- text (STRING) mandatory primary
- weight (LONG) mandatory
[mu:answer] > nt:hierarchyNode
- text (STRING) mandatory primary
- correct (BOOLEAN) mandatory
[mu:test] > nt:hierarchyNode, mix:referenceable
- title (STRING) mandatory primary
- question (REFERENCE) mandatory multiple < 'mu:question'
/*
- topic (REFERENCE) mandatory multiple < 'mu:topic'
*/
[mu:topic] > nt:hierarchyNode /*, mix:referenceable */
- theme (STRING)
- test (REFERENCE) mandatory multiply < 'mu:test'
[mu:user] > nt:hierarchyNode
- login (STRING)
- password (STRING)
- fullName (STRING)
--
Best regards. Pavel Konnikov
Re: jackrabbit-jcr-demo. Another idea.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 4/8/07, Tako Schotanus <ja...@codejive.org> wrote:
> Just a question Jukka. You keep saying things like:
>
> > [mu:topics] > nt:folder
> > > + topic (mu:topic)
> >
> > No need for a custom node type where nt:folder is good enough.
>
> What are your reasons for this exactly? Is that just a personal choice of
> yours because, let's say, you don't like strict definitions or is there some
> kind of technical reason to avoid introducing too many custom types?
There's no technical reason to avoid custom types, Jackrabbit can
easily manage thousands of types if needed.
The reason to prefer using the standard types where possible is
because it makes the content model more "understandable" to generic
JCR clients that have no knowledge of the appliction internals. For
example using nt:folders here makes it easy to mount the content tree
as a folder in your file system using WebDAV support in Jackrabbit and
to for example add or modify attachment files within the tree (this is
more useful for the blog application, but might come in handy also for
the test application).
Using the standard types also gives you an extra level of flexibility
(normally when you create a custom type you want to constrain things
more), which I personally find very useful. In general I tend to let
the content tree structure remail fairly flexible and use primary node
types to dispatch appropriate processing for the nodes within the
tree.
BR,
Jukka Zitting
Re: jackrabbit-jcr-demo. Another idea.
Posted by Tako Schotanus <ja...@codejive.org>.
Just a question Jukka. You keep saying things like:
> [mu:topics] > nt:folder
> > + topic (mu:topic)
>
> No need for a custom node type where nt:folder is good enough.
>
What are your reasons for this exactly? Is that just a personal choice of
yours because, let's say, you don't like strict definitions or is there some
kind of technical reason to avoid introducing too many custom types?
Just curious.
Cheers,
-Tako
On 4/7/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 4/2/07, Pavel Konnikov <ko...@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
>
Re: jackrabbit-jcr-demo. Another idea.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 4/2/07, Pavel Konnikov <ko...@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