Fastest way to mock up web UI?
Michael Roberts
mike at mjr104.co.uk
Wed Mar 28 22:34:01 UTC 2007
>
> 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
More information about the Squeak-dev
mailing list
|