goran.hultgren at bluefish.se wrote:
> Chris Burkert <christian.burkert at s2000.tu-chemnitz.de> wrote:
[snip]

>>>If HttpView sounds interesting I can dig up some sample code for you.
>>>NOTE: The HttpView on SM is not up to date. I need to scramble together
>>>my latest into a release.
>>
>>This would be the greatest. Göran you _are_ great!
> 
> Darn, now I just added another thing to my todo list... :-) I will get
> back on this, remind me - there is a lot going on here...

Yes, please!!!  :)

>>>So in short - go with Comance + Seaside/HttpView and build it from
>>>there. The Swiki syntax class you can get from me or Avi (he may have
>>>improved it). I also have lots of other code around like an "upload
>>>documents" facility etc.

Yes, please. When convenient. :)
[snip]

> Yeah, I should document HttpView much better...

You just did some. :)
Below is the extract of your email which could be put on an appropriate 
swiki or included with your code as you wish.

> PS. Btw, the Homepage Builder project I did also uses ImageSegments for
> very easy persistence. It also offer the users a "test site" and a
> "published site". And they can easily revert to an earlier snapshot of
> the whole site.

Cool. :)

Göran, thanks for these informative emails. I look forward to seeing 
your update on SM. (When convenient.)

Jimmie Houchin

HttpView Documentation.

Compared to Seaside I think HttpView is:
- Much simpler (and thus less capable of the advanced stuff, on the
   other hand HttpView doesn't tie your hands so that you can't do things
   "your own way" when you want to.)
  - Much smaller (let me count - 22 classes of which you only need to
  learn 3. The other 19 are "internal")

 > What are these 3 classes?

HVModule
HVHttpView
HVHtmlBuilder

HVModule is the thing you instantiate once and register in Comanche. It
is a very small class, only has 4 oneliner methods and the method
#process: which Comanche likes. It is 6 lines long and sort of
kickstarts the url dispatching by creating the top view instance for the
model. HVModule holds a "model" and a "prefix". The prefix is used to
filter out if the url is meant for this module (so you can have multiple
apps running using different prefixes). The model is the top model
object for your system.

HVHttpView is the base class for the view instances that gets created.
Currently these are created on every request (initially I toyed with the
idea of keeping them around but have not yet needed to). A view has a
reference to a model and its methods correspond to the urls - so
"calling" an url is like "calling" a method in the view and each
"directory" in the url maps to a method in the views. So if you have an
url like "/myapp/account/settings/save" - "myapp" is the prefix for the
module, "account" is the #account method in the top view. It typically
finds the account instance based for the logged in person and creates a
view with the account as a model and then continues the dispatch by
calling the #settings method in THAT view. That method typically creates
a new view on the settings object and calls #save on that, etc.etc. In
this way each request creates a chain of HVHttpView (subclasses thereof)
instances that can use their "parent" reference if needed.

HVHtmlBuilder is the object that I use to create XHTML pages. It has a
very rich protocol with many different variants for especially Forms.
When used it builds an internal collection of objects representing the
webpage and in the end it renders this structure on a stream for
Comanche to return. Sortof DOM like. The cool thing is that it can
autoconnect the posts with the previous request that built the form so
that you get the "feeling" of widgets - as you saw in my sample. No ids
(they are all autogenerated by the builder) etc.

When I build an app with HttpView I typically create a subclass of
HVModule for my app - but it very seldom do anything than override
#initialize to use a different prefix. Then I create a base view class
which inherits from HVHttpView and which I use for all the generic stuff
that all my views in this app should share. Then I create my first view
class - the top view for the model - and make it inherit this base
class.

So my app consists of one dead trivial HVModule subclass and a bunch of
subclasses of HVHttpView (with a common base class) like this:

HVHttpView
	HVMyAppBaseView
		HVMyAppTopView
		HVAccountView
		HVWhateverView

Anyway, enough blabbering - I think you get the picture.



To Swikify...

It is very easy to use. Just create an instance and tell it to swikify a
text, like this:

formatter _ WBHtmlFormatter base: 'http:/yaddayadda/' model: aModel.
html _ formatter swikify: aText.