Ard,
one thing I forgot to ask: is this 'filter' thing available
somewhere? Is it part of JR1.5?
thanks in advance.
Ard Schrijvers escribió:
> 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.
>>>>
>>>>
>>>>
>>
