[SW2] First Commit to Cincom Public StORE

[Lukas Renggli]

Hi David,

> So I try to work on the renderers and components during this week, as 
> much as possible.

Great!

> 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 
> instance,
> 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 
> page3,
> but the request has still the url of page1, so I can't resolve the 
> structure
> of page3 from the url of the request, but I will goTo again to page1 
> (as
> defined in message Session>>initializeModel, because the resolved 
> structure
> 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 
> won't
> be these clear urls like in SW1 anymore. And I think you want to have 
> these
> urls with the titles of a page in, even when SW is under Seaside now, I
> guess?

Yes, readable and bookmark-able URL are a requirement.

> So I'm wondering how to achieve that, to have these fine urls when 
> using
> 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

	html
		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 
code.

Cheers,
Lukas

-- 
Lukas Renggli
http://renggli.freezope.org