[aida] Ajax action handlers

Janko Mivšek janko.mivsek at eranova.si
Tue Jan 27 16:39:38 CET 2009

Hi Eli,

Your perspective is welcome and also not far away from thinking we
already did so far. And form posting from standalone components is high
on the list.

You propose to add handling of Ajax events in a manner like the
exceptions are handled in Smalltalk. And to add the handling to the
WebElement. We are currently more inclined to add stronger support to
WebComponent instead and (at least for now) not handling events like
exceptions. Mostly because experience shows that exception handling is
hard for an usual programmer and therefore rarely used.

But introduction of action methods to WebComponents, that's something
worth looking at. Ok, then there will be a problem of double
implementation of essentially the same in apps and components, but this
could be resolved later. What I'd like to add soon is form posting from
standalone components, Ajax style. We can achieve a lot just with that!

Your example bellow also shows the problem of parameter passing via Ajax
requests. So far only strings are supported and you need to compose and
decomose them manually. General object passing would be nice of course,
by value or maybe even by reference?

Best regards

Eli Green pravi:
> Hi,
> Caveat: I am speaking from a position of near complete ignorance on both Aida and relative ignorance of Smalltalk. My hope is that this will bring fresh perspective rather than an absurdly wrong collection of errors and misunderstanding.
>>From my point of view, it would be perfect if there was no distinction between an Ajax-submitted action and a "Web 1.0" form post. To this end, it seems like the sensible thing to do is to push event handling down to WebElement. Now, I have not delved into the internal workings of Aida so I can only speak from the perspective of a user of the framework but from the little that I have scratched, I think more consistency in action methods would be beneficial. For example, in WebGrid there is this:
> ajaxUpdateWith: aParmString
> 	| parm |
> 	(aParmString notNil and: ['sort-*' match: aParmString]) ifTrue: 
> 		[parm := aParmString readStream upTo: $-; upToEnd.
> 		(self columnWithId: parm asInteger) sort. "or toogle sort order"
> 		self page: 1]. "always back to first page after sort change"
> 	(aParmString notNil and: ['page-*' match: aParmString]) ifTrue: 
> 		[parm := aParmString readStream upTo: $-; upToEnd.
> 		self page: parm asInteger]. 
> 	^self
> Which really, in my mind, should be this:
> actionSort: aColumnNumber
> 	(self columnWithId: parm) aColumnNumber.
> 	self page: 1.
> actionPage: aPageNumber
> 	self page: aPageNumber
> I don't really know how hard it would be to "push" those events to an upper level component but since each WebElement knows its parent, I don't see that it would be that hard. A WebElement that wanted to expose an API to its parent would simply pass the event upwards to be handled by that parent's event handlers:
> viewMain
> 	e := MyWebElement new.
> 	e action: #twiddle.
> 	self pageFrameWith: e title: 'purely hypothetical example'.
> actionMainTwiddle
> 	self doSomething.
> The action methods are still not identical because where WebApplication has views, WebElement does not but the basic mechanism is the same. I'm not sure how to cleanly handle the difference between those two. Basically in this scheme, events are passed to the components responsible for generating them. These components can ignore, consume or pass them to their parent.
> Eli

Janko Mivšek
Smalltalk Web Application Server

More information about the Aida mailing list