syntax for internal links/link rewriting

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://" 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:// 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  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 
optional. but that
>> would lead to a "polymorphic" protocol:
>>
>> (a) lenyadoc:/*/*
>>      means language,  means uuid.
>> (b) lenyadoc://*/*/*/*
>>      means pub-id,  means area,  means
language,  means uuid
>> (c) lenyadoc://*/*/*
>>      means pub-id,  means language,  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">Ge
rman</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&
amp;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: pol-adminuni-due.de, Telefon: 0203/379-2736

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org