While we often advertise that seaBreeze provides a really simple way of creating web pages with a gui-editor. It is somewhat unknown that it also provides pretty cool features when it comes to programming the application logic.
Nowadays Ajax is used almost everywhere on the web, which is cool: Ajax allows for nice user interfaces that update only parts of their content, improving both server load and user satisfaction. The only thing where Ajax doesn’t do much good is when it comes to the work flow: If you load a new page via Ajax, the browser doesn’t recognize this and thus doesn’t change back and forward buttons accordingly. If the user presses the back button after he did quite a lot of input on an Ajax-web page he’s probably taken back way to far in history and looses much of his work.
Now Seaside has these nice continuations that help the developer so much when doing work flows in web pages. But using Ajax you can’t put them to much use. Either you have an anchor that’s used as normal callback, or you use it as Ajax-callback.
In seaBreeze we wanted to simplify the usage of Ajax a lot. The first thing we did there was making updates on the web page more like in normal desktop applications: you just tell an element to update. In normal web applications you always have to know which elements to update when you write the update-handler.
That means that Seaside’s “process the callback” and then “render the page again” is now also working for ajax-callbacks; first the callback is performed then the required elements are updated.
To request the update of an element you need to call:
SBElementUpdater updateElementWithId:#MyElement.
The same mechanism is used to trigger effects on an element. You can call:
SBEffectTrigger triggerEffect: #toggleBlind onElementWithId: #MyElement.
Getting back to the workflow problem mentioned earlier in this post, seaBreeze also solves this. In any callback you can execute a block so that it is executed like a normal non-ajax callback. This can be done by calling:
SBAjaxCallback doAsNormalCallback:[self doSomething].
This is actually called whenever you send #call: or #answer: to a seaBreeze ApplicationModel. That has the nice side effect that you can use #call: and #answer: even in Ajax-Callbacks which would lead to problems if you do that with standard Seaside. The calls inside an Ajax-callback also support continuations so you shouldn’t notice any difference.
If you execute something with #doAsNormalCallback: this will reload the whole web page and the browser will update the back and forward buttons accordingly. So even if you don’t use #call: you can still have the browser keep a history of what the user does.
Karsten