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 <[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. > >> > >> > >
