On 1/10/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> I totally agree. I implemented this behaviour in a customer project
> using an Action. A little selector magic will certainly be sufficient in
> most cases.
Everybody agrees a URL should contain all the information to uniquely
create a page. That helps with caching and exporters, and is just
good web design.
> >>It might occur that multiple URLs represent a single Document object.
> >>With URLs u1 and u2, it is not possible to check if u1 and u2 represent
> >>the same document without using the DocumentBuilder.
> > With the flat structure, every document has a UNID (Unique Identifier):
> > getUNID(url1) == getUNID(url2)
> > tells if they are the same document. The display may be different
> > based on the module/area/usecase used for the display:
> > /live/foo.html
> > /map/foo.html
> > both refer to the same document, but the first displays the document
> > and the last display the sitemap with the document highlighted.
> OK - IIUC that would mean that you have to provide a context information
> to obtain a document's URL. Is that right?
> For instance something like that:
> String[] document.getSupportedUrlHints();
> String document.getUrl("content");
> String document.getUrl("sitemap");
Yes, Document.getUrl() should contain the context, although we can
default it to "live" if it is missing. Would that help
backwards-compatibility? What does getUrl() return for Usecases,
which use the querystring to change the display?
> > ======
> > On 1/9/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> >>Michael Wechner wrote:
> >>>Andreas Hartmann wrote:
> >>The DefaultDocumentBuilder returns /foo.html for the default language
> >>and /foo_xx.html for the other languages as canonical URLs.
> > Is that desirable?
> That's up to you - you can simply override this behaviour.
I did, but programming was messy until I realized I should. It would
be easier to program internally and for newbies if it defaulted to
inserting the language.
> > Should the document for the default language
> > return "/foo_{language}.html"?
> IIRC the main reason for this behaviour is to support single-language
> sites without language tags in the URL, without applying additional magic.
How important is it to provide no-language-URLs natively? Lenya
already requires proxying/URL rewriting to remove the "/pubname/live"?
Should the "_en" (or whichever default language) also be removed at
that time? Lenya would still understand
"/pubname/live/foo.html", but it would convert it to
"/pubname/live/foo_{defaultLanguage}.html" before any other
processing. Links are mostly created by XSL, and a single language
publication would not need to add the language to its links. That
leads into my next point about consistent programming:
> > The consistency makes XSL programming
> > much easier. Before I converted our publication to always use the
> > language in the URLs, every function related to language had to check
> > if the language existed, approximately doubling the code required. I
> > noticed the same extra code because of inconsistent URLs thoughout
> > Lenya. If we add a few lines as early as possible to add the language
> > to any requested URL that does not contain the language, much of Lenya
> > would be cleaner.
> >>>I am not sure if I understand you correctly, but I would say we should
> >>>go with (2), but
> >>>I guess if you make an example, e.g.
> >>>/en/developers/andreas-hartmann
> >>>/de/entwickler/andreas-hartmann
> >>>/en/committers/andi
> >>>/de/committers/andreas
> >>In my opinion, only one of these URLs should actually represent the
> >>document.
> >>The others should merely point to the document, i.e. by redirects, URL
> >>rewriting or another concept like this. If you ask the document for its
> >>URL, there should be only one option that can be returned.
> > Is this "multiple parents" or "softlinks"? In other words, should one
> > document be accessible through multiple parents, or are there several
> > documents that dereference to one document with the content? (Let us
> > support both, and let the editors decide when each is appropriate.)
> What I don't like is when these two calls can return the same document
> object:
>
> site = publication.getPrimarySiteStructure();
> doc1 = site.getNode("/en/developers/andreas-hartmann").getDocument();
> doc2 = site.getNode("/en/committers/andi").getDocument();
>
> It is fine with me if doc2 uses some internal reference mechanism
> (XInclude or whatever) to return the content of doc1.
OK. You (Andreas) prefers "softlinks" over "multiple parents". They
are not mutually exclusive. Multiple parents would be easier for
maintenance by newbies. Is there any reason to not include both
abilities?
> >>>>Another question: With multiple site structures, how does the system keep
> >>>>track of the currently selected site structure?
> >>>> - URL prefix
> >>>that would be my first suggestion, similar to "context" for servlets
> >>Yes, but it would require reserved URL spaces.
> > Back to my "Use Areas for Modules". I do not think of them as
> > "reserved". The intention is to remove the currently reserved "live"
> > and "authoring" URL spaces by using the same process for all URLs.
> > Keep the Usecase/Module framework, and use the old Area to specify
> > which Module to use. This adds much flexibility without losing
> > backwards-compatibility. (We should keep the "?lenya.usecase="
> > override format for backwards-compatibility.)
> How would that work with proxies? If you point your proxy to the
> URL space of the live module, how will other modules be called?
The hard configuration would explicitly list each of the modules:
/pubid/* -> /pubid/*
/module1/* -> /pubid/module1/*
/module2/* -> /pubid/module2/*
/module3/* -> /pubid/module3/*
/* -> /pubid/live/*
That may be good for security, but annoying when a publication has
many modules, and most will. It would be easier (more generic/less
configuration) to add something that indicates the next part is the
module (either the pubid, or something static like "mod" or "alt", or
several):
/pubid/* -> /pubid/*
/mod/* -> /pubid/*
/* -> /pubid/live/*
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
