Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of quintesse@gmail.com designates
 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=MaEOWl5vgA6u9zx0Olp8sgUI8xhYMsKSfLzxKJLjak2cmRCw9AQr43tXiJtRNO2Yxguot8o7VkW4YK4EzAx+5BT3qvf8QuhDLvkiTUlAoD/3GXCUJlYWuPyOX2PWleOxB2P6ihxTqK+K7fZClMNZYMojAhGZg8tz27Li4NW3wGU=
Message-ID: <8641fd7c0704080830v41fbb421ob5a93e1283f3d313@mail.gmail.com>
Date: Sun, 8 Apr 2007 17:30:10 +0200
From: "Tako Schotanus" <java@codejive.org>
Sender: quintesse@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: jackrabbit-jcr-demo. Another idea.
In-Reply-To: <510143ac0704070002s18b1d658g6d4dec99a28c6bcd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7282_29002710.1176046210959"
References: <op.tp49t6bkicv7rh@pavelkonnikov>
	 <510143ac0704070002s18b1d658g6d4dec99a28c6bcd@mail.gmail.com>

------=_Part_7282_29002710.1176046210959
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <jukka.zitting@gmail.com> wrote:
>
> 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
>

------=_Part_7282_29002710.1176046210959--