ajax invocations

[ghost]

Reported by @cristianbogdan on 3 Dec 2009 14:35 UTC more help should be available for the programmer to make ajax invocations, i.e. to invoke server operations without loading a new page. then the page can change in just some of its sections (bug 1123)

two types of ajax invocations come to mind

1) ajax form submission here you don't have any form action, but you specify in some way how the submission affects the page (event, result variable, see below)

two issues here:

• widget to submit the form: an input type=submit will not do... maybe we can define someText</mak:submit> which will work both with normal and ajax forms
• events to submit the form, e.g. onChange=function(){makSubmit();} which could also be used for both kinds of forms

2) ajax operation invocation. the form submission is actually enough but the trouble with forms is that one associates them with a user input, when in fact we just have a control to invoke some operation.

the proposal is to have instead of and instead of and the rest is as in forms (including the submission widget), maybe including full postback submission if action= is indicated.

for all of the above, in case of ajax submission, there are two issues: a) how to indicate the name of the event (bug 1125) indicating that the ajax invocation ended. b) how to get hold of the result of the ajax call. since the ajax call will often result to a partial page rendering (bug 1124), it does make sense to put the result in a server-side variable / page attribute. It also makes sense to put the result in a javascript variable, just in case the client-side wants to do something about this

it seems suitable to actually combine the above, so the name of the result variable is the name of the event

---

so my proposal

Create student then $inserted will be available to the sections (bug 1123) that need it event becomes then the same as name="" for forms, or we could even keep name="" instead. this would mean that ajax forms become simply forms with no action Migrated-From: http://trac.makumba.org/ticket/1133

[ghost]

Comment by @manuelbernhardt on 28 Dec 2009 02:23 UTC another aspect of the invocation is what to invoke the operation on.

in java-based web 2.0 environments, ajax invocations are done on a servlet which returns JSON data.

one proposal that has been discussed is the introduction of "middle JSPs" which would represent such logic. another approach would be to introduce ajax methods inside of MDDs, side-by-side with query fragments.

as JSPs and the tag-based languages seem to be quite easy to grasp, one might want to investigate this direction a bit further. it would also make it possible to mix procedural logic with queries, such as in:

calling page:

Vote ${voted} vote.op: You already voted, don't try to cheat! You're too late! Deadline is over! Total votes: ${mak:maxCount()} mak:choose would result in a query, very similar to the way mak:list works, looking like SELECT (exists(vote.Vote v where v.submitter = actor(company.Employee) and v.topic = $topic)) AS when1, (t.deadline > now() from vote.Topic t where t = $topic) AS when2 FROM vote.Topic t WHERE t = $topic and the boolean result of where1, where2, whereN, ... would be used in order to render the content of the page. the response content itself would then be simple text, stored: - server side, as variable "voted" - client side, as variable "voted" (this being achieved by having the makumba client-side script that generated the mak:invoke AJAX call evaluate "var vote = " on the fly on the response, using the prototype mechanism for this.

[ghost]

Comment by @manuelbernhardt on 28 Dec 2009 11:26 UTC (In reply to comment #1)

You already voted, don't try to cheat! You're too late! Deadline is over! Total votes: ${mak:maxCount()}

of course this example defeats the puropose of validation rules:

• the first when should be a multi-uniqueness rule in vote.Vote: unique(submitter, topic) : "You already voted, don't try to cheat!"
• the second when should be a comparison rule in vote.Vote: compare(topic.deadline) { topic.deadline > $now } "You're too late! Deadline is over!"

I think that one big difference between invocations and traditional forms is that:

• the invocation should really only happen with the right parameters and the right conditions. the operation logic has to make sure nobody tries to cheat by doing a direct invokation (http request) on the logic/servlet page, but then the way the error is displayed does not matter too much

• the invoked operation is all about processing data and returning data as a result

in the examples, this translates into:

Vote ${voted} show the vote count of course then, the operation does not need to be a custom one but could be a generic new operation, hence the validity of the example is questionable. one question remains though: how to display/deal with "exceptions" from the operations? such as e.g. validation rules kicking in, uniqueness exceptions (that happen only on db insert and are detected by db constraints, ...)

[ghost]

Comment by @cristianbogdan on 29 Dec 2009 16:42 UTC (In reply to comment #0)

1) ajax form submission

let me be more precise here

here you don't have any form action, but you specify in some way how the submission affects the page (event, result variable, see below)

Create student > > two issues here: > - widget to submit the form: an input type=submit will not do... maybe we can > define someText which will work both with normal and > ajax forms > - events to submit the form, e.g. onChange=function(){makSubmit();} which could > also be used for both kinds of forms > > 2) ajax operation invocation. > the form submission is actually enough but the trouble with forms is that one > associates them with a user input, when in fact we just have a control to > invoke some operation. > > the proposal is to have instead of and > instead of and the rest is as in forms (including the submission > widget), maybe including full postback submission if action= is indicated. > > for all of the above, in case of ajax submission, there are two issues: > a) how to indicate the name of the event (bug 1125) indicating that the ajax > invocation ended. > b) how to get hold of the result of the ajax call. since the ajax call will > often result to a partial page rendering (bug 1124), it does make sense to put > the result in a server-side variable / page attribute. It also makes sense to > put the result in a javascript variable, just in case the client-side wants to > do something about this > > it seems suitable to actually combine the above, so the name of the result > variable is the name of the event > > ---- > so my proposal > > > Create student > > > then $inserted will be available to the sections (bug 1123) that need it > event becomes then the same as name="" for forms, or we could even keep name="" > instead. this would mean that ajax forms become simply forms with no action

[ghost]

Comment by @cristianbogdan on 29 Dec 2009 17:03 UTC please disregard comment 3

i am adding more details to comment 0 as it wasn't expressive enough. then (in next comments) i'll try to develop the ideas further, especially to address the pessimistic case, when the operations invoked return error.

1) ajax form submission here you don't have any form action, but you specify in some way how the submission affects the page (event, result variable, see below)

Create student in this case the name of the event would also be the name of the created object. the simpler case should work too Create student > - widget to submit the form: an input type=submit will not do... maybe we can > define someText which will work both with normal and > ajax forms this would be mak:submit above, which works for both forms and mak:invoke > - events to submit the form, e.g. onChange=function(){makSubmit();} which could > also be used for both kinds of forms that is, you could submit the form from any javascript event in the form > 2) ajax operation invocation. just to recap, mak:invoke would work exactly as mak:form, except that it can only contain mak:param, which is the same as a mak:input type=hidden and should have a value, as the user cannot enter one. but for the rest mak:invoke and mak:param can be implemented with the same code as mak:form and mak:input respectively. mak:invoke, like mak:form can be used for both ajax and non-ajax (full postback) submission however i'm not sure mak:newForm should have a correspondent like mak:invokeNew. as mak:form with operation is much more versatile (bug 1131), maybe only mak:invoke is needed, and probably we can slowly deprecate mak:XXXform

[ghost]

Comment by @cristianbogdan on 29 Dec 2009 18:00 UTC (In reply to comment #2)

• the invocation should really only happen with the right parameters and the right conditions. the operation logic has to make sure nobody tries to cheat by doing a direct invokation (http request) on the logic/servlet page, but then the way the error is displayed does not matter too much

I don't understand what you mean by cheating here.

Breaking a constraint from a mak:invoke parameter or a mak:form hidden input (i.e. set by the programmer, not by the user) is indeed an issue, probably it should result in a programmer error.

one question remains though: how to display/deal with "exceptions" from the operations? such as e.g. validation rules kicking in, uniqueness exceptions (that happen only on db insert and are detected by db constraints, ...)

well let's see. we are discussing about ajax-submitted mak:form and mak:invoke.

• forms with client-side validation have less problems, they will never submit anything unless it's correct
• forms with server-side validation should probably not be accepted in ajax invocation... not sure. if we want to accept them, then the form can by default place itself in a section which is reloaded on validation error.
• what remains is displaying the post-invocation results and exceptions of mak:form and mak:invoke. putting mak:response in the section triggered by the form submission will achieve this. it is probably useful to raise a different event in case of error, to serve the programmer who wants to show invocation errors in a different section than in the optimistic case.

[ghost]

Comment by @manuelbernhardt on 4 Jan 2010 12:13 UTC part of this is now implemented by:

http://makumba.svn.sourceforge.net/makumba/?rev=4405&view=rev http://makumba.svn.sourceforge.net/makumba/?rev=4398&view=rev http://makumba.svn.sourceforge.net/makumba/?rev=4406&view=rev

i.e.:

still to be done: - improve error reporting: use attribute values of the annotation (before, after, both) and diplay the error message of non-field errors - support / test for this kind of forms in iterations - support / test for this kind of forms with multiple forms - play nice with live validation (clear error messages on partial submit that brings errors) - document all of this there is a tag, which for now only works inside of forms. for later we could think of having it outside of forms, e.g. and have the submission happen via javascript. using mak:submit is *optional* though, works just as well. this is because we need to hijack the form submit event in javascript in order to do a partial postback (otherwise, having a element inside of a tag automatically triggers a full post-back, at least in Firefox and Safari).

[ghost]

Comment by @manuelbernhardt on 10 Jan 2010 16:20 UTC (In reply to comment #6)

implemented more of this, and it seems to be working fine. still to be done is:

• support / test for this kind of forms in iterations

• support / test for this kind of forms with multiple forms

• support for annotation type "both" (doesn't work for me, i.e. the form is annotated only after, not before.

• mak:invoke and mak:param, i.e. submission of non-user data directly to the filter/controller handler. the implementation needs to be given some thought as well

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:22 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:24 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC

[ghost]

Comment by @cristianbogdan on 19 Mar 2013 00:51 UTC for now i'm happy with how mak:section and mak:form triggerEvent + mak.submit() handle this

form annotation only works if the form is in a section but that i think is fair enough