[SW2] First Commit to Cincom Public StORE
renggli at iam.unibe.ch
Wed Jul 21 19:03:53 MEST 2004
> So I try to work on the renderers and components during this week, as
> much as possible.
> Then I have a question to the message Session>>goTo: aModel: There you
> set a
> new model (and renderer) to the session, so a new model is rendered
> with a
> new renderer, when a user clicks on a link. That works perfectly if the
> model has the same url as the page where this link was into. For
> when I'm on http://localhost:8080/page1, then the Edit or History links
> works well. But what is when there's an internal link in the wiki, for
> instance a link to page3, which would be accessible under the url
> http://localhost:8080/folder2/page3? Then I try to goTo the model of
> but the request has still the url of page1, so I can't resolve the
> of page3 from the url of the request, but I will goTo again to page1
> defined in message Session>>initializeModel, because the resolved
> is not the same as the structure in model).
Mhh, I do not get this? As far as I understand you concern isn't a
problem, as Seaside is doing a redirect to the correct path after every
link/submit anyway. Actually this is the standard behavior of Seaside
and has some other advantages, like a nicer behavior of the application
when using the back-button in the web-browser.
> We could change initializeModel to not resolve the url, but then there
> be these clear urls like in SW1 anymore. And I think you want to have
> urls with the titles of a page in, even when SW is under Seaside now, I
Yes, readable and bookmark-able URL are a requirement.
> So I'm wondering how to achieve that, to have these fine urls when
> Seaside. It's not possible to simply redirect to the url of a
> structure as
> in SW1, because the Seaside session would be lost then.
Have a look at the class SmallWiki2.TreeComponent, one of the few
components that is fully working already. I think, it is showing some
of the power of Seaside in a very nice way: the links to the structure
there are defined as action callbacks
anchorWithAction: [ self session goTo: aModel ]
do: aModel title
and Seaside takes care of updating the url and keeping the session.
Another nice thing to see in this example - but not related to your
question - is how the state of the component is kept, e.g. what nodes
of the tree are collapsed/expanded. In SmallWiki 1 this would have been
extremely difficult involving the use of ugly HTTP-stuff like cookies
and it would have been impossible to have two such components on the
same page. In SmallWiki 2 you can get this with just a few lines of
More information about the SmallWiki