Ralph Goers wrote:
Daniel Fagerstrom wrote:
Is it a Map of the Site? ------------------------
The Forrest people don't think that the sitemap is enough as map of the site. They have a special linkmap [1] that gives a map over the site and that is used for internal navigation and for creating menu trees. I have a similar view. From the sitemap it can be hard to answer basic questions like:
* What is the URL space of the application * What is the structure of the URL space * How is the resource refered by this URL produced
The basic view of a URL in the sitemap is that it is any string. Even if there are constructions like mount, the URL space is not considered as hierarchial. That means that the URLs can be presented as patterns in any order in the sitemap and you have to read through all of it to see if there is a rule for a certain URL.
A real map for the site should be tree structured like the linkmap in forrest. Take a look at the example in [1], (I don't suggest using the "free form" XML, something stricter is required). Such a tree model will also help in planning the URI space as it gives a good overview of it.
Out of curiosity, have you looked at the Portal block?
Not until now. But I spent to large part of the night writing my RT to be able to understand how everything worked together :/
The layout actually separates the site layout from the sitemap quite nicely.
Care to explain what I should look for, and in what document I find the info?
Unfortunately, the Portal URLs are not cool. I'm in the process right now of attempting to fix that.
Have you looked at XFrames URLs http://www.w3.org/TR/xframes/, they adress a problem area that should be quite similar to the one you have in portals, IIUC.
| http://example.org/home.frm#frames(id1=uri1,id2=uri2,...)|
You need to write a parser for the frames part, but I could use that booth in my attribute template language proposal and in the virtual pipeline URLs that I proposed in the current thread, so it is well invested time for me if I convince you to write such a parser ;)
/Daniel
We are finding that exposing the Portal's events in the browser causes JSR-168 portlets to fall on their face simply by reloading the page. Not cool at all.
Ralph
