jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@onehippo.com>
Subject RE: David's Model and translation projects
Date Mon, 08 Sep 2008 08:19:44 GMT
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.

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 <fmandelbaum@gmail.com> 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.
> >>
> >>     
> 
> 

Mime
View raw message