>
> So how do you build an application if you don't use #call:? The  
> WAStore example seems to use #call: exclusively and it is not clear  
> to me how exactly one would actually build an application in  
> Seaside without using call:.


You write it using callbacks to change state that drives the rendering.

e.g. for want of a better example look at WAMultiCounter.  Change  
these methods:

initialize
	counters := OrderedCollection new

renderContentOn: html
	html anchor
		callback: [counters add: WACounter new];
		with: 'Add counter'.
	counters
		do: [:ea | html render: ea]
		separatedBy: [html horizontalRule]

If you compare to the original you can see I make the counter's  
collection empty and just add the callback at the top of the render  
method.  The callback changes the state of the component and this  
dictates what is rendered.  #children is already valid but important  
for this to work.

#call: is useful when you want to be able to switch a component in  
the page layout, in place, with zero effort.  In the example above,  
we are in direct control of the component's composition.  #call: is a  
lower-level framework feature.  For example, add this callback:

html anchor
	callback: [counters atRandom call: WAMiniCalendar new];
	with: 'Call component at random'.

we #call: one of the components.  The effect of this is to show the  
mini calendar in place of one of the counters.  We have not had to  
say anything else to achieve this, and get #answer support, back  
button support, etc.

Instead if we do this:

html anchor
	callback: [counters at: counters size atRandom
				put: WAMiniCalendar new];
	with: 'Replace component at random'.

we get the same visual effect but the side-effect is quite  
different.  You can see this if you turn the halos on.  In the former  
example of #call: the framework completely handles the layering of  
the components (and any #answer that unwinds the layering and hands a  
result back).

In the later example, we just ditch the component and replace it.   
Hopefully you can see the difference.  Deciding which to use is more  
difficult.  This example is contrived but the principle is to show  
that call: is orthogonal to page layout / component composition.

There is REST support in Seaside as Philippe says, and whilst it is  
not as central as other features it is not difficult to create entry  
points into your application, or just have multiple applications.  I  
think this approach scales well, you define any entry points that you  
want and stop thinking about URLs after that.

Also the subjects of complexity and "magic" have been raised in this  
thread.  Whilst I understand where this is coming from, really you  
just need to look at WACounter.  Seaside is not that complicated,  
after all WACounter is a fully dynamic web application.  I think what  
we could do with is some better examples.  I don't find WAStore the  
best starting point I have to say.

By all means ask any questions on the Seaside list.  That is one of  
the other advantages to your framework selection.... Have fun.

Cheers,

Mike