On 8/24/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> This was solved for 1.3:
> content:/resourceUNID
> content:/resourceUNID_language
> content:/resourceUNID!revision
Good point, we could use the revision-based syntax in 1.4 as well.
> content:/resourceUNID_language!revision
> resourceUNID is the UUID.
> language and revision are optional. language defaults to the current
> language. revision defaults to the revision marked "live" for the
> Translation.
> There are also variations for using a Resource's ID from the
> hierarchy of a Structure. XMAPs can access Resources without
> translating the path to the UNID.
> content:/1234
> content:/live/parentDocumentInLiveStructure/documentID
> both access the same Resource.
In 1.4, the site:/ protocol serves this purpose
(http://lenya.apache.org/docs/1_4/reference/protocols/site.html)
But I just noticed that the site:/ protocol doesn't allow to
omit the language, I guess the syntax should be changed.
1.4 has two protocols for accessing content? XMAP developers must
decide which is appropriate for each match? Sometimes language is
required, but sometimes it is optional? <map:match
pattern="/mypipeline/**"> must know whether ** is an ID or a UNID?
No comment. I cannot think of anything nice to say.
> From my experience, "live" uses IDs (from URLs generated for visitors)
> and "edit" uses UNIDs (from URLs generated by maintenance screens).
> Using underscore '_' and exclamation mark '!' as separators means the
> same protocol can serve both IDs and UNIDs.
>
> ---
> Each Resource can have a "defaultlanguage" parameter. If the
> specified language does not exist, defaultlanguage is also tried.
> This is very useful with images, so an image is maintained for only
> one Translation, and that Translation is used for every language.
Should we allow a default-language parameter for each document in 1.4?
This is another case where translation-independent meta data would
come in handy. Or is the per-publication parameter sufficient?
What do the others think?
If defaultlanguage is not by Resource, every page will default to the
default language. Everybody will set the default language to "xx" so
only items in that non-existent language will use a default. Why make
people use workarounds?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
