Yes the idea i mentioned above
Don't think in javascript!
javascript is not importand here. Just generated ONE callback to the server.
but call BOTH behaviors after each other.
Handle duplicated behaviors one the server side not client
johan
On 1/15/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
but the thing is you might not want it ignored sometimes
if (!confirm('delete?')) return false; foo();
-igor
On 1/16/07, Johan Compagner [EMAIL PROTECTED] wrote:
yes this can only be done for the calls where we generated the callback.
(so mostly ajax things)
else we should generate
and what if i add an attributemodifer that sets some javascript for the same
attrs, then it overrides the callback completely. you cant not think in
javascript without a good abstraction from it.
-igor
On 1/16/07, Johan Compagner [EMAIL PROTECTED] wrote:
Yes the idea i mentioned above
Don't
yes this can only be done for the calls where we generated the callback. (so
mostly ajax things)
else we should generate functions and call the functions one by one.
(then return false; will be ignored...)
johan
On 1/16/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
and what if i add an
Hi,
In my current application I added 2 AjaxFormComponentUpdatingBehaviors
with event onchange to the same form component. Only the behavior that
is added last will actually be called. Is this on purpose? I would like
both to be called.
I tried both on 1.2.4 and a fresh (today) 1.2 snapshot.
yes this is how it works now
Maybe we could somehow merge it on the server side
when we see 2 behavior attached to the same event only generate for one but
also call the other..
johan
On 1/15/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi,
In my current application I added 2
Ok, that's too bad.
Yes, I would very much like that feature. I created a JIRA issue to
request it (https://issues.apache.org/jira/browse/WICKET-214).
Thanks Johan,
Erik.
Johan Compagner schreef:
yes this is how it works now
Maybe we could somehow merge it on the server side
when we
thats a kludge, there is no good way to do this cleanly.
what if i have a regular behavior that sets an onchange attr, and then add
an ajax behavior? then the script generated by the first behavior is erased.
you can say, lets just append them, but what if the first behavior's script
includes
Yeah, that is a bit dangerous. Currently, we don't do much to check
whether behaviors overwrite each other. We probably could if we think
up another interface that cooperates with IBehavior. And maybe we can
combine that with a convenience class a la AppendingBehavior, it would
make things easier
problem with appending, etc, is that in my experience most behaviors will
have a return statement for every path, so appending will pretty much be a
noop
-igor
On 1/15/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah, that is a bit dangerous. Currently, we don't do much to check
whether
Ok, so that wouldn't solve anything. Recognizing you're trying to
overwrite an attribute that was previously written by another behavior
might help in at least figuring out that there is a problem. Though
otoh, I don't think it's gonna be a big saver.
Any other ideas?
Eelco
On 1/15/07, Igor
No big ideas here, I am afraid.
For me it seems logical to just call both behaviors sequentially from
the Wicket servlet/filter and combine the results (where the only
results I know are things added to the AjaxRequestTarget). But the inner
workings of Wicket are mostly terra incognita for me
12 matches
Mail list logo
