>>>

Thanks lukas... I will try to help. Stef On 19 juil. 04, at 17:58, Lukas Renggli wrote: > Hi everybody, > > I published a first version of SmallWiki 2 to Cincom Public StORE > (SmallWiki2, 1.12, renggli). I hope it loads without troubles :/ > > Don't expect much! And *don't use it on your production server*, the > model might still change and I won't care about backward compatibility > before reaching the final 2.0 version! > > Some of the consideration of the new implementation: > > - the model is completely separated from the view: e.g. there is a view > based on Seaside and for demonstration purposes a very simple and buggy > one on the trippy-inspector framework. > > - the model of the structure has been refined to allow better > versioning, external storage, etc. > > - even better extensibility ;) > > - the model of the document and the parser has been improved to allow a > more generic use of the entities: smilies, code are now possible within > headings and links; links are now possible within headings, etc. > > - the parser tests have been improved and all the production rules are > covered now. > > - the old model is easily transformable into the new one by writing a > visitor (not proven yet, but I expect it to be very easy). > > I'm looking for any comments and feedback on the new implementation. > I'm looking for people as well that are willing to help and/or comment > in the following areas: > > - Improving the model. > > - Writing more tests. > > - Improving the Renderers: e.g. error-checking, more functionality, > better user experience, etc. > creating a nice userinterface. > > - Finish the existing but incomplete and add more subclasses to > WikiComponent. Currently most of them are empty classes without any > useful functunatliy. > > - Improving the trippy-inspector wiki, that is nice to use but > currently badly implemented. > > - A SmallWiki 1 to SmallWiki 2 model convertor. > > Cheers, > Lukas > > -- Lukas Renggli > http://renggli.freezope.org >

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

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?

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.