getting back to this thread after a month of other issues...
lenya devs, please participate, since this is a major issue that *must*
be settled before 1.4 can go out the door.
Andreas Hartmann wrote:
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?
obviously not :)
[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.
agreed.
* 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.
sounds ok.
moreover, i think something that never really touches the actual
lenyadoc: source factory should not be called lenyadoc:
for this reason, i still think the new thing should be called something
else.
[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.
agreed.
then let's just call it lenya-document:// to avoid confusion with the
lenyadoc source factory.
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
nice ideas. but let's use a request param for area - that way, link
syntax does not break when we finally chuck out the area concept, as it
would with "positional", colon-separated parameters.
here's my take:
lenya-document://uuid?lang=de&area=live&pub=default&revision=...
wdyt?
should we introduce a new source factory of the same name that follows
the same semantics? that way, we can slowly deprecate the old
lenyadoc:// stuff that's hard to read and easy to get wrong because of
the positional parameters.
i like this idea very much :)
[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.
yes, let's tackle this issues rsn - i want to finish my tinymce stuff :)
regards,
jörn
--
"It's sad to behold how lately the wonderful English language has,
in the hands of corporate executives and marketing experts, re-
adjusted its prospective itinerary towards mythical subterranean
realms of discomfort, leveraging traditional woven containment
devices."
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
