[SW2] First Commit to Cincom Public StORE

[stéphane ducasse]

Hi lukas

This afternoon and morning too in fact, we got a good design discussion 
with frederic
about the query engine. He is making progress. Then looking at some 
classes I realized that what is was doing is a kind of wizard to offer 
to the user a coherent query (i.e. you can only get certain combox 
choices depending on other choices, a kind of flow). I thought that in 
seaside this would be ***much*** simpler. So we are eager to get a 
first version of SmallWiki 2 because then frederic will be able to 
develop much better interfaces.
So keep going. :)

I also showed seaside to michael because he was planning to develop an 
application for photo gallery using css and I guess that they will look 
at Seaside :) and may be SmallWiki. :)

Stef

On 21 juil. 04, at 19:03, Lukas Renggli wrote:

> 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
>