On 9/8/08, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
> Hello Fabián Mandelbaum,
>
>  First of all, IMHO, you do not have to entirely commit to David's model. 
> IMHO, some of the rules are based on the frontend technology that is 
> displaying the data (like number 4, beware of same name siblings. When 
> creating frontends based on repository paths and cache them etc etc, I 
> understand same name siblings are nasty, but, AFAICS, it is a frontend 
> technology driven rule. Same holds for some other rules.)
>
>  So, in your case, I would preferably not structure your content in folders 
> containing the 'language' name. As you said, you break one of Davids Rules 
> (though, again, creating some basic structure doesn't seem harmful to me at 
> all, again :-))  ), but worse, you might run into cumbersome queries 
> regarding performance. You probably will need to do all queries having some 
> path info, slowing queries significantly.
>
>  I would create same name sibblings, and have meta data (a property) on the 
> file indicate the language. I must admit you might want to have some features 
> for this we have added on top of Jackrabbit, like 'filtered mirrors': below 
> some node, we expose a virtual copy of the repository, filtered on some 
> properties to only show those nodes you want to. All nodes in this virtual 
> layer are accessed jsr compliant, so, the client isn't even aware (we call 
> this a facetselect, a mirror with filters, where we also expose 
> facetsearches, a virtual facetted navigation within Jackrabbit, again jsr 
> compliant). Though even without this enhancement I would go for same name 
> sibblings and meta data. Querying on meta data is alsways fast, as opposed to 
> querying with path info.


the nice thing about not having SNS and having a folder structure for
the language is that you can easily access it via webdav. so you just
drop your translated files in the respective folder again, and your
done. having SNS and meta data just renders this impossible.

regards, toby

ps: imo SNS were a stupid idea (the way they were speced in jcr1.0.
there are some efforts in jsr283 to correct this) and are actually
only valid to use when importing/exploding XML files into the
repository. but you always have troubles as soon as you have SNS, and
you need a lot of application logic to handle and use them
efficiently.


>
>  Just my 2 cents,
>
>  Regards Ard
>
>
>
>  > Fabián Mandelbaum wrote:
>  > Approach #2 is indeed, natural, however the "problem" I see
>  > with approach #2 is that it seems to break David's rule #1
>  > (data 1st vs.
>  > structure 1st) by imposing a fixed content structure to
>  > projects (for example, /common/ /en/ /fr/ /es/ /it/ etc.).
>  >
>  > I'm not saying I won't end doing things this way (actually,
>  > it is so far my personal choice), I just wanted to know if
>  > there was a way to do it in a way that conforms a bit more to
>  > David's rule #1.
>  >
>  > Thanks again.
>  >
>  > Tobias Bocanegra escribió:
>  > > hi,
>  > > it certainly depends on your intention, but having a folder
>  > for each
>  > > language is imo the best approach. you might have other resources
>  > > later (like images) that are language dependent that you can put in
>  > > the folder.
>  > >
>  > > regards, toby
>  > >
>  > > On 9/6/08, Fabián Mandelbaum <[EMAIL PROTECTED]> wrote:
>  > >
>  > >> Hello there,
>  > >>
>  > >>     I'm considering David's Model
>  > >>  (http://wiki.apache.org/jackrabbit/DavidsModel) and was wondering
>  > >> how  would David handle translations of documents.
>  > >>
>  > >>     Let's say I have a file, for example: file.xml which
>  > is written
>  > >> in  English, and I want to store its translation to, say, Spanish.
>  > >> Which  would be the recommended storage model?
>  > >>
>  > >>     1) Common storage place
>  > >>
>  > >>     /content/file.xml (English version)
>  > >>     /content/file-es.xml (Spanish version)
>  > >>     /content/file-fr.xml (French version)
>  > >>
>  > >>     2) Folders for each language
>  > >>
>  > >>     /content/en/file.xml
>  > >>     /content/es/file.xml
>  > >>     /content/fr/file.xml
>  > >>
>  > >>     3) Workspaces for each language
>  > >>
>  > >>     /content/file.xml (in 'en' workspace)
>  > >>     /content/file.xml (in 'es' workspace)
>  > >>     /content/file.xml (in 'fr' workspace)
>  > >>
>  > >>     Other? My ears are open, Thanks in advance.
>  > >>
>  > >>
>  >
>  >
>

Reply via email to