Jörn Nettingsmeier schrieb:
[...]
> iirc there was a discussion about using "lenyadoc:/{lang}/{uuid}" for
> both resource documents (former assets) and internal links. is anyone
> working on this?
Did we already come to a decision?
> [using lenyadoc: as it is]
>
> the problem i see with using "lenyadoc" is that we have subtly different
> semantics compared to the real lenyadoc source factory:
>
> * we can only support the relative lenyadoc:/{lang}/{uuid} URIs until we
> have a publication lookup mechanism in place. but re-using a protocol
> name should imply supporting all features imho.
IMO there's no pressing need to support inter-publication links.
We could add the lookup mechnanism later.
> * even if we eventually support cross-publication linking and thus the
> fully-qualified lenyadoc syntax, the {area} field in the URI would make
> no sense.
See above, IMO the uuid+language syntax is sufficient.
> [extending lenyadoc:]
>
> so we would have to extend lenyadoc: to make {area} optional. but that
> would lead to a "polymorphic" protocol:
>
> (a) lenyadoc:/*/*
> {1} means language, {2} means uuid.
> (b) lenyadoc://*/*/*/*
> {1} means pub-id, {2} means area, {3} means language, {4} means uuid
> (c) lenyadoc://*/*/*
> {1} means pub-id, {2} means language, {3} means uuid.
>
> this is nasty.
I agree.
> and it totally dies if we introduce "revision" as another optional
> argument to lenyadoc.
Maybe we could use something like a request parameter for this?
The site:/ protocol already supports a format parameter, IMO
we should keep this concept extensible by using named parameters.
> moreover, i think something that never really touches the actual
> lenyadoc: source factory should not be called lenyadoc:
>
> [no alternative: special tags]
[...]
> [alternative 1: a new protocol]
>
> looks like we must indeed introduce a new URI scheme. how about
> <a href="lenya-uuid://f4989872-34553443-343"/> ?
To be honest, I don't like the term UUID here because it refers
to a technical detail.
> this is then rewritten by looking the uuid up in the sitemap.
>
> another open question: should those links allow to specify language and
> pub? i think no. language switching is better handled by a separate
> mechanism, and inter-pub linking is not on the radar atm.
IMO the language should be optional. For instance:
<p>
We are currently only offering jobs in our
<a href="lenya-uuid://f4989872-34553443-343:de">German</a>
department.
</p>
I think we could change the syntax of the lenyadoc:// protocol
slightly (optional parameters in square brackets):
a) lenyadoc://pub:area:uuid:language
b) lenyadoc://[uuid]:[language]
lenyadoc://f4989872:de -> document f4989872 in German
lenyadoc://f4989872: -> document f4989872 in same language
lenyadoc://:de -> current document in German
Since the second one is probably the most common and the trailing
colon looks strange, we could allow to omit it.
This is of course not perfect.
Parameters can be added:
lenyadoc://...?format=pdf&revision=234
> [consequences]
>
> the new scheme needs to be transformed into a standard URI when the
> request is served. this job could be handled by the
> LinkRewritingTransformer.
Yes, for instance.
> the problem is that we also need to transform those uris before we call
> a wysiwyg editor, otherwise it would not be able to display images etc.
> in reverse, that also means we must apply clever heuristics to links
> coming out of an editor and map it back to lenya-uuid:// uris. clever
> heuristics are usually a stupid idea, but i see no alternative here.
Good point. Maybe we can use AJAX or something like this for client-
side link resolving in some cases.
> i suggest this algorithm:
> assume all relative links that come out of an edited document are
> pointing at lenya repository resources. walk the sitetree until you find
> the path and exchange the relative uri with a lenya-uuid:// one.
> if you don't find it in the sitetree, leave it untouched (maybe the user
> is running lenya under an apache server and does indeed have local links
> that point to non-lenya-controlled sources).
Thanks for bringing this up again!
I'll think about it again.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
