Ajax action handlers

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


_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

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
Janko

Eli Green pravi:

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi,

I was thinking about this recently and rather than patch into the normal event / action system, why not let people pass blocks to onClickUpdate?

e addButton: 'Add New Object' onClickUpdate: objectList do: [objectList add: newObject].

From Aida's point of view, I think this should be easier since it's a callback that you can store as an instance variable of the element. Yay! Now, this is more complicated on the client side than I had first hoped because I realized that it would mean emitting code that marshaled all the form elements on the page into a JSON request. But we should know about all the form fields, shouldn't we? Does Scriptaculous make it easy to pass form parameters as JSON?

Basically I would like the above code to work with or without javascript and I think it's an achievable goal. If you omit the onClickUpdate: parameter, it would obviously just be a form post.

I'm sad to say that I won't be using Aida for my current project - not because I think it won't do it but because my inexperience makes me nervous about billing a client for me to learn a new framework. I'm going to stay on the list and try to play with it more because I think there's a great deal of potential here.

To be honest, I'm a little hazy on the technical and philosophical differences between a WebElement, WebComponent and WebApplication.

On Tuesday, January 27, 2009, at 04:39PM, "Janko Mivšek" <[hidden email]> wrote: _______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi,

With a colleague we have tweaked Aida to handle (ajax or not) actions in
WebComponent. We do it with an unique action id in the html page, each
id corresponding to an action (a block closure actually). All id/action
association is registered in a context object, itself stored in a
special session class, subclass of WebSession.

This mechanism works very well, and we have this way standalone
components. We use this to build a commercial CMS based on Scribo.

Nico


Le mardi 27 janvier 2009 à 16:39 +0100, Janko Mivšek a écrit :
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Nico,

nico pravi:

> With a colleague we have tweaked Aida to handle (ajax or not) actions in
> WebComponent. We do it with an unique action id in the html page, each
> id corresponding to an action (a block closure actually). All id/action
> association is registered in a context object, itself stored in a
> special session class, subclass of WebSession.

In WebSession we have #userValues  dynamic value for any extensions.
Well, maybe would be better to rename to #other?

> This mechanism works very well, and we have this way standalone
> components. We use this to build a commercial CMS based on Scribo.ž

I hope you'll show us to copy it to base Aida too :)

Janko

--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Eli Green pravi:

> I was thinking about this recently and rather than patch into the normal event / action system, why not let people pass blocks to onClickUpdate?
>
> e addButton: 'Add New Object' onClickUpdate: objectList do: [objectList add: newObject].

This is interesting idea and callbacks here probably won't hurt basic
MVC separation we have with action methods.
>
> From Aida's point of view, I think this should be easier since it's a callback that you can store as an instance variable of the element. Yay! Now, this is more complicated on the client side than I had first hoped because I realized that it would mean emitting code that marshaled all the form elements on the page into a JSON request. But we should know about all the form fields, shouldn't we? Does Scriptaculous make it easy to pass form parameters as JSON?

Yes, Prototype has a nice support for Ajax form posting, which is not
much more than already supported Ajax field posting in Aida
(#onChangePost etc)

> Basically I would like the above code to work with or without javascript and I think it's an achievable goal. If you omit the onClickUpdate: parameter, it would obviously just be a form post.
>
> I'm sad to say that I won't be using Aida for my current project - not because I think it won't do it but because my inexperience makes me nervous about billing a client for me to learn a new framework. I'm going to stay on the list and try to play with it more because I think there's a great deal of potential here.

And we'll try to provide more examples of real apps to learn from. A
code of new Aida website together with short description will be the first.

> To be honest, I'm a little hazy on the technical and philosophical differences between a WebElement, WebComponent and WebApplication.

First, those names and concepts are evolving and we are still learning
to find the best approach. Specially concerning WebComponent. While
WebApplication, besides the funny name, seems quite a successful concept.

You can continue with your thoughts, I'm all ears :)

Janko

--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

...
EG>>To be honest, I'm a little hazy on the technical and philosophical differences between a WebElement, WebComponent and WebApplication.
...
JM>>First, those names and concepts are evolving and we are still learning
JM>>to find the best approach. Specially concerning WebComponent. While
JM>>WebApplication, besides the funny name, seems quite a successful concept.

They seem to me to be like fractal elements of a natural system which demonstrate self-similarity at different levels. A context is necessary to clarify meaning for any particular instance.

My two pennyworth :-))

Nicholas

Janko Mivšek wrote:

Eli Green pravi:

  

I was thinking about this recently and rather than patch into the normal event / action system, why not let people pass blocks to onClickUpdate?

e addButton: 'Add New Object' onClickUpdate: objectList do: [objectList add: newObject].
    

This is interesting idea and callbacks here probably won't hurt basic
MVC separation we have with action methods.
  

From Aida's point of view, I think this should be easier since it's a callback that you can store as an instance variable of the element. Yay! Now, this is more complicated on the client side than I had first hoped because I realized that it would mean emitting code that marshaled all the form elements on the page into a JSON request. But we should know about all the form fields, shouldn't we? Does Scriptaculous make it easy to pass form parameters as JSON?
    

Yes, Prototype has a nice support for Ajax form posting, which is not
much more than already supported Ajax field posting in Aida
(#onChangePost etc)

  

Basically I would like the above code to work with or without javascript and I think it's an achievable goal. If you omit the onClickUpdate: parameter, it would obviously just be a form post.

I'm sad to say that I won't be using Aida for my current project - not because I think it won't do it but because my inexperience makes me nervous about billing a client for me to learn a new framework. I'm going to stay on the list and try to play with it more because I think there's a great deal of potential here.
    

And we'll try to provide more examples of real apps to learn from. A
code of new Aida website together with short description will be the first.

  

To be honest, I'm a little hazy on the technical and philosophical differences between a WebElement, WebComponent and WebApplication.
    

First, those names and concepts are evolving and we are still learning
to find the best approach. Specially concerning WebComponent. While
WebApplication, besides the funny name, seems quite a successful concept.

You can continue with your thoughts, I'm all ears :)

Janko

  

On Tuesday, January 27, 2009, at 04:39PM, "Janko Mivšek" [hidden email] wrote:
    

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
Janko

      

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
    

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Le jeudi 29 janvier 2009 à 18:45 +0100, Janko Mivšek a écrit : Yes, we created a subclass because userValues wasn't really good for
this kind of objects.
>
> > This mechanism works very well, and we have this way standalone
> > components. We use this to build a commercial CMS based on Scribo.ž
>
> I hope you'll show us to copy it to base Aida too :)
Hmm, I would like to, but I have to ask my colleague first.

Cheers!

Nico

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Janko,

Sorry for pick up the old theme.

Janko Mivsek wrote

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?

The problem with parameters passing can be partially solved by blocks.
Instead of converting parameters to string and then back to objects we can capture objects at closure(block). So closure will represent action with already included parameters. In that case we only need to have string representation for reference to closure.


Alex