Re: Ajax form question about Tapestry 4.1
I noticed that the EventListener parameter for validating a form wasn't
being properly used, this has been fixed. (the default is still false, to
bypass validation)
On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
Yeah I was sort of wondering the same thing, and in particular, how do
I get validation messages to render via ajax -- that is, i wat the
form to go through the normal validation routine and I dont want to
enable client side validation. I actually kind of like the red stars
and custom decorators the validation classes afford you...
i remember in tacos there was an example of employing the validators
(ie, led red asterisks appeared via ajax), is this possible in
tapestry 4.1 without some weird kludge?
I read in the docs that the default is to disable validation when
using submitForm -- since most of the use cases would make incurring
the validation lifecycle cumbersome to the user. Thats the default,
which implies it can be toggled... can it, and if so, how? ;-)
Thanks,
Josh
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> Hi, I was looking at the new Tapestry 4.1 ajax features.
> EventListener/ResponseBuilder are really nice! Besides the new
annotations I
> noticed some components (such as DirectLink) already have the Tacos ajax
> functionality built in which allows you to update a certain part of the
page
> ("updateComponents" parameter), however I didn't find the same
functionality
> for the forms and submit buttons.
>
>
>
> I tried using an EventListener/ResponseBuilder combination (listening
for
> onClick and onSubmit) to try and get the same result but whenever I
click on
> a submit button the form is submitted the traditional way, the entire
page
> is reloaded. I'm guessing this could be solved by replacing the submit
> buttons with regular links and having the form submitted on the
> EventListener, but it just doesn't feel right not to use submit buttons
> where they are needed.
>
>
>
> Is there a new way to do this (maybe using the annotations) or is the
ajax
> form submit functionality just not implemented yet?
>
>
>
> Cheers
>
> Denis Souza
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Ajax form question about Tapestry 4.1
What is an "empty page"? I mean does it have the expected output or
simply nothing is rendered?
Use a @Shell component to wrap the page because @Form and
@DropdownDateTimePicker requires dojo (which is provided by @Shell).
Regards,
Norbi
Marcus wrote:
Sorry,
I've download Tapestry 4.1 and folowing jars, all in \shared\lib
aspectj-1.5.2.jar
easymock.jar
jakarta-oro-2.0.8.jar
ognl-2.6.9.jar
testng-4.7-jdk15.jar
commons-io-1.2.jar
hivemind-1.1.1.jar
hivemind-lib-1.1.1.jar
I was using Tapestry 3.03 and all of your library dependencies, then I
delete T303 jars and add T41 jars.
After I try to create a simple page with *DropdownDatePicker component
Data: value="ognl:startDate"/>
import java.util.Date;
import org.apache.tapestry.html.BasePage;
/*
* Created on 04/08/2006
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Generation - Code and Comments
*/
public class Home extends BasePage{
private Date startDate = new java.util.Date();
public Date getStartDate() {
return startDate;
}
public void setStartDate(Date startDate) {
this.startDate = startDate;
}
public void formSubmit(){
return;
}
}
And what i got is an empty page on Firefox and IE
What did I wrong? :(
Thank's for your time.
Marcus
*
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 2006.08.03.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax form question about Tapestry 4.1
Sorry,
I've download Tapestry 4.1 and folowing jars, all in \shared\lib
aspectj-1.5.2.jar
easymock.jar
jakarta-oro-2.0.8.jar
ognl-2.6.9.jar
testng-4.7-jdk15.jar
commons-io-1.2.jar
hivemind-1.1.1.jar
hivemind-lib-1.1.1.jar
I was using Tapestry 3.03 and all of your library dependencies, then I
delete T303 jars and add T41 jars.
After I try to create a simple page with *DropdownDatePicker component
Data:
import java.util.Date;
import org.apache.tapestry.html.BasePage;
/*
* Created on 04/08/2006
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Generation - Code and Comments
*/
public class Home extends BasePage{
private Date startDate = new java.util.Date();
public Date getStartDate() {
return startDate;
}
public void setStartDate(Date startDate) {
this.startDate = startDate;
}
public void formSubmit(){
return;
}
}
And what i got is an empty page on Firefox and IE
What did I wrong? :(
Thank's for your time.
Marcus
*
Re: Ajax form question about Tapestry 4.1
Hi, I've download Tapestry 4.1 and folowing jars, all in \shared\lib aspectj-1.5.2.jar easymock.jar jakarta-oro-2.0.8.jar ognl-2.6.9.jar commons-io-1.2.jar
Re: Ajax form question about Tapestry 4.1
Yeah, I think (but am not entirely sure) that I said would add
"updateComponents/async" that I stuck in all the link components into the
Form/submit related components this weekend.
On 8/3/06, Denis Souza <[EMAIL PROTECTED]> wrote:
Yes, it makes sense. My first attempt at this was actually listening for
the
"onclick" event on a submit button but it has the same effect.
Now my question is: what would be the solution in this case? (i.e. if I
should log a JIRA issue/bug, what would it contain?) When capturing the
"onsubmit" event on the form, it must be submitted, right? Would there be
a
way to stop this or would it require a completely different mechanism?
Again, I would suggest the "updateComponents" parameter as a solution
since
it has always worked so well on Tacos.
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 2 de agosto de 2006 19:39
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1
Sounds like a possible bug. It makes sense though now..
All the @EventListener would do in this instance is bind to the event
happening, not interfere with "what" happens. Your form submitting
probably
just blew away any chance of having the ajax stuff completing :)
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
>
> > I've been trying to avoid adding too many new parameters (like
> > updateComponents) all over the place before I felt like I had found a
> good
> > way to do this without code duplication.
>
> I'm all for reducing the number of parameters as long as there some
other
> way to do the same thing. It's just that I couldn't get it to work in
any
> other way.
> But I also think the updateComponents parameter could be very useful. In
> some cases it could be a welcome replacement to writing a listener
method
> with an EventListener annotation.
>
> > As for Forms, you could very easily use @EventListener, targeting a
form
> +
> > event of "onsubmit" to get the same result. (Use ResponseBuilder to
> update
> > whatever components you want, possibly event the whole form so you see
> the
> > server side rendered validators.)
>
> Yes, I tried exactly that:
>
> @EventListener(targets="form", events="onsubmit")
> public void myListener(IRequestCycle cycle) {
>... do something ...
>cycle.getResponseBuilder().updateComponent("x");
> }
>
> But when I click on a submit button, the entire page is still reloaded.
I
> tried it with my submit button's action/listener parameter being the
same
> listener as the EventListener annotation.
> From what I could understand from the tests I made, the component "x"
(as
> in
> the above example) gets rendered twice, once for the ajax update and
once
> more for the page reload.
> I think I'm failing somehow to tell the framework that this should be an
> ajax-only request. Since you said it should work, it could be something
> that
> I'm doing wrong, or could be a bug that shows under certain conditions.
> Any ideas?
>
>
> Cheers
> Denis Souza
>
> -Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: quarta-feira, 2 de agosto de 2006 18:24
> To: Tapestry users
> Subject: Re: Ajax form question about Tapestry 4.1
>
> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a
good
> way to do this without code duplication.
>
> It's probably fair that I at least add them to form/form button based
> components though.
>
> As for Forms, you could very easily use @EventListener, targeting a form
+
> event of "onsubmit" to get the same result. (Use ResponseBuilder to
update
> whatever components you want, possibly event the whole form so you see
the
> server side rendered validators.)
>
> Although, if all you care about is the UI mechanism employed to decorate
> form fields then you might find doing it on the client side to be more
> efficient.
>
> Perhaps I should allow an easier to use(understand?) method of
decorating
> form fields on the client side similar to (if not the same? will have to
> think about this) the existing ValidationDelegate?
>
> If you wanted to re-produce the "look" the server gives you could fairly
> easily take the javascript reference found here -
> http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html -
> and
> handle the UI part anyway you like.
>
> If you have a Border component or similar the perfect thing to do might
be
> to define a javascript block like so to override the default Tapestry
> client
> side decorating logic (n
RE: Ajax form question about Tapestry 4.1
Yes, it makes sense. My first attempt at this was actually listening for the
"onclick" event on a submit button but it has the same effect.
Now my question is: what would be the solution in this case? (i.e. if I
should log a JIRA issue/bug, what would it contain?) When capturing the
"onsubmit" event on the form, it must be submitted, right? Would there be a
way to stop this or would it require a completely different mechanism?
Again, I would suggest the "updateComponents" parameter as a solution since
it has always worked so well on Tacos.
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 2 de agosto de 2006 19:39
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1
Sounds like a possible bug. It makes sense though now..
All the @EventListener would do in this instance is bind to the event
happening, not interfere with "what" happens. Your form submitting probably
just blew away any chance of having the ajax stuff completing :)
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
>
> > I've been trying to avoid adding too many new parameters (like
> > updateComponents) all over the place before I felt like I had found a
> good
> > way to do this without code duplication.
>
> I'm all for reducing the number of parameters as long as there some other
> way to do the same thing. It's just that I couldn't get it to work in any
> other way.
> But I also think the updateComponents parameter could be very useful. In
> some cases it could be a welcome replacement to writing a listener method
> with an EventListener annotation.
>
> > As for Forms, you could very easily use @EventListener, targeting a form
> +
> > event of "onsubmit" to get the same result. (Use ResponseBuilder to
> update
> > whatever components you want, possibly event the whole form so you see
> the
> > server side rendered validators.)
>
> Yes, I tried exactly that:
>
> @EventListener(targets="form", events="onsubmit")
> public void myListener(IRequestCycle cycle) {
>... do something ...
>cycle.getResponseBuilder().updateComponent("x");
> }
>
> But when I click on a submit button, the entire page is still reloaded. I
> tried it with my submit button's action/listener parameter being the same
> listener as the EventListener annotation.
> From what I could understand from the tests I made, the component "x" (as
> in
> the above example) gets rendered twice, once for the ajax update and once
> more for the page reload.
> I think I'm failing somehow to tell the framework that this should be an
> ajax-only request. Since you said it should work, it could be something
> that
> I'm doing wrong, or could be a bug that shows under certain conditions.
> Any ideas?
>
>
> Cheers
> Denis Souza
>
> -Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: quarta-feira, 2 de agosto de 2006 18:24
> To: Tapestry users
> Subject: Re: Ajax form question about Tapestry 4.1
>
> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a good
> way to do this without code duplication.
>
> It's probably fair that I at least add them to form/form button based
> components though.
>
> As for Forms, you could very easily use @EventListener, targeting a form +
> event of "onsubmit" to get the same result. (Use ResponseBuilder to update
> whatever components you want, possibly event the whole form so you see the
> server side rendered validators.)
>
> Although, if all you care about is the UI mechanism employed to decorate
> form fields then you might find doing it on the client side to be more
> efficient.
>
> Perhaps I should allow an easier to use(understand?) method of decorating
> form fields on the client side similar to (if not the same? will have to
> think about this) the existing ValidationDelegate?
>
> If you wanted to re-produce the "look" the server gives you could fairly
> easily take the javascript reference found here -
> http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html -
> and
> handle the UI part anyway you like.
>
> If you have a Border component or similar the perfect thing to do might be
> to define a javascript block like so to override the default Tapestry
> client
> side decorating logic (not validation logic, you have to override a
> different function for that):
>
>
> tapestry.form.validation.handleMissingField=function(field, profile) {
>/// Do whatever you want, the default just applies a CSS class name to
Re: Ajax form question about Tapestry 4.1
Sounds like a possible bug. It makes sense though now..
All the @EventListener would do in this instance is bind to the event
happening, not interfere with "what" happens. Your form submitting probably
just blew away any chance of having the ajax stuff completing :)
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a
good
> way to do this without code duplication.
I'm all for reducing the number of parameters as long as there some other
way to do the same thing. It's just that I couldn't get it to work in any
other way.
But I also think the updateComponents parameter could be very useful. In
some cases it could be a welcome replacement to writing a listener method
with an EventListener annotation.
> As for Forms, you could very easily use @EventListener, targeting a form
+
> event of "onsubmit" to get the same result. (Use ResponseBuilder to
update
> whatever components you want, possibly event the whole form so you see
the
> server side rendered validators.)
Yes, I tried exactly that:
@EventListener(targets="form", events="onsubmit")
public void myListener(IRequestCycle cycle) {
... do something ...
cycle.getResponseBuilder().updateComponent("x");
}
But when I click on a submit button, the entire page is still reloaded. I
tried it with my submit button's action/listener parameter being the same
listener as the EventListener annotation.
From what I could understand from the tests I made, the component "x" (as
in
the above example) gets rendered twice, once for the ajax update and once
more for the page reload.
I think I'm failing somehow to tell the framework that this should be an
ajax-only request. Since you said it should work, it could be something
that
I'm doing wrong, or could be a bug that shows under certain conditions.
Any ideas?
Cheers
Denis Souza
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 2 de agosto de 2006 18:24
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1
I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.
It's probably fair that I at least add them to form/form button based
components though.
As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)
Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.
Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?
If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html -
and
handle the UI part anyway you like.
If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry
client
side decorating logic (not validation logic, you have to override a
different function for that):
tapestry.form.validation.handleMissingField=function(field, profile) {
/// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or
font
element and give it red **'s if you like
}
Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them
(design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.
On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
>
> Yeah I was sort of wondering the same thing, and in particular, how do
> I get validation messages to render via ajax -- that is, i wat the
> form to go through the normal validation routine and I dont want to
> enable client side validation. I actually kind of like the red stars
> and custom decorators the validation classes afford you...
>
> i remember in tacos there was an example of employing the validators
> (ie, led red asterisks appeared via ajax), is this possible in
> tapestry 4.1 without some weird kludge?
>
> I read in the docs that the default is to disable validation when
> using submitForm -- since most of the use cases would make incurring
> the validation lifecycle cumberso
RE: Ajax form question about Tapestry 4.1
> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a good
> way to do this without code duplication.
I'm all for reducing the number of parameters as long as there some other
way to do the same thing. It's just that I couldn't get it to work in any
other way.
But I also think the updateComponents parameter could be very useful. In
some cases it could be a welcome replacement to writing a listener method
with an EventListener annotation.
> As for Forms, you could very easily use @EventListener, targeting a form +
> event of "onsubmit" to get the same result. (Use ResponseBuilder to update
> whatever components you want, possibly event the whole form so you see the
> server side rendered validators.)
Yes, I tried exactly that:
@EventListener(targets="form", events="onsubmit")
public void myListener(IRequestCycle cycle) {
... do something ...
cycle.getResponseBuilder().updateComponent("x");
}
But when I click on a submit button, the entire page is still reloaded. I
tried it with my submit button's action/listener parameter being the same
listener as the EventListener annotation.
>From what I could understand from the tests I made, the component "x" (as in
the above example) gets rendered twice, once for the ajax update and once
more for the page reload.
I think I'm failing somehow to tell the framework that this should be an
ajax-only request. Since you said it should work, it could be something that
I'm doing wrong, or could be a bug that shows under certain conditions.
Any ideas?
Cheers
Denis Souza
-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 2 de agosto de 2006 18:24
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1
I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.
It's probably fair that I at least add them to form/form button based
components though.
As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)
Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.
Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?
If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html - and
handle the UI part anyway you like.
If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry client
side decorating logic (not validation logic, you have to override a
different function for that):
tapestry.form.validation.handleMissingField=function(field, profile) {
/// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or font
element and give it red **'s if you like
}
Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them (design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.
On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
>
> Yeah I was sort of wondering the same thing, and in particular, how do
> I get validation messages to render via ajax -- that is, i wat the
> form to go through the normal validation routine and I dont want to
> enable client side validation. I actually kind of like the red stars
> and custom decorators the validation classes afford you...
>
> i remember in tacos there was an example of employing the validators
> (ie, led red asterisks appeared via ajax), is this possible in
> tapestry 4.1 without some weird kludge?
>
> I read in the docs that the default is to disable validation when
> using submitForm -- since most of the use cases would make incurring
> the validation lifecycle cumbersome to the user. Thats the default,
> which implies it can be toggled... can it, and if so, how? ;-)
>
> Thanks,
>
> Josh
>
> On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> > Hi, I was looking at the new Tapestry 4.1 ajax features.
> > EventListener/ResponseBuilder are really nice! Besides
Re: Ajax form question about Tapestry 4.1
I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.
It's probably fair that I at least add them to form/form button based
components though.
As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)
Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.
Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?
If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html - and
handle the UI part anyway you like.
If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry client
side decorating logic (not validation logic, you have to override a
different function for that):
tapestry.form.validation.handleMissingField=function(field, profile) {
/// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or font
element and give it red **'s if you like
}
Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them (design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.
On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
Yeah I was sort of wondering the same thing, and in particular, how do
I get validation messages to render via ajax -- that is, i wat the
form to go through the normal validation routine and I dont want to
enable client side validation. I actually kind of like the red stars
and custom decorators the validation classes afford you...
i remember in tacos there was an example of employing the validators
(ie, led red asterisks appeared via ajax), is this possible in
tapestry 4.1 without some weird kludge?
I read in the docs that the default is to disable validation when
using submitForm -- since most of the use cases would make incurring
the validation lifecycle cumbersome to the user. Thats the default,
which implies it can be toggled... can it, and if so, how? ;-)
Thanks,
Josh
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> Hi, I was looking at the new Tapestry 4.1 ajax features.
> EventListener/ResponseBuilder are really nice! Besides the new
annotations I
> noticed some components (such as DirectLink) already have the Tacos ajax
> functionality built in which allows you to update a certain part of the
page
> ("updateComponents" parameter), however I didn't find the same
functionality
> for the forms and submit buttons.
>
>
>
> I tried using an EventListener/ResponseBuilder combination (listening
for
> onClick and onSubmit) to try and get the same result but whenever I
click on
> a submit button the form is submitted the traditional way, the entire
page
> is reloaded. I'm guessing this could be solved by replacing the submit
> buttons with regular links and having the form submitted on the
> EventListener, but it just doesn't feel right not to use submit buttons
> where they are needed.
>
>
>
> Is there a new way to do this (maybe using the annotations) or is the
ajax
> form submit functionality just not implemented yet?
>
>
>
> Cheers
>
> Denis Souza
>
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Ajax form question about Tapestry 4.1
Yeah I was sort of wondering the same thing, and in particular, how do
I get validation messages to render via ajax -- that is, i wat the
form to go through the normal validation routine and I dont want to
enable client side validation. I actually kind of like the red stars
and custom decorators the validation classes afford you...
i remember in tacos there was an example of employing the validators
(ie, led red asterisks appeared via ajax), is this possible in
tapestry 4.1 without some weird kludge?
I read in the docs that the default is to disable validation when
using submitForm -- since most of the use cases would make incurring
the validation lifecycle cumbersome to the user. Thats the default,
which implies it can be toggled... can it, and if so, how? ;-)
Thanks,
Josh
On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
Hi, I was looking at the new Tapestry 4.1 ajax features.
EventListener/ResponseBuilder are really nice! Besides the new annotations I
noticed some components (such as DirectLink) already have the Tacos ajax
functionality built in which allows you to update a certain part of the page
("updateComponents" parameter), however I didn't find the same functionality
for the forms and submit buttons.
I tried using an EventListener/ResponseBuilder combination (listening for
onClick and onSubmit) to try and get the same result but whenever I click on
a submit button the form is submitted the traditional way, the entire page
is reloaded. I'm guessing this could be solved by replacing the submit
buttons with regular links and having the form submitted on the
EventListener, but it just doesn't feel right not to use submit buttons
where they are needed.
Is there a new way to do this (maybe using the annotations) or is the ajax
form submit functionality just not implemented yet?
Cheers
Denis Souza
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ajax form question about Tapestry 4.1
Hi, I was looking at the new Tapestry 4.1 ajax features.
EventListener/ResponseBuilder are really nice! Besides the new annotations I
noticed some components (such as DirectLink) already have the Tacos ajax
functionality built in which allows you to update a certain part of the page
("updateComponents" parameter), however I didn't find the same functionality
for the forms and submit buttons.
I tried using an EventListener/ResponseBuilder combination (listening for
onClick and onSubmit) to try and get the same result but whenever I click on
a submit button the form is submitted the traditional way, the entire page
is reloaded. I'm guessing this could be solved by replacing the submit
buttons with regular links and having the form submitted on the
EventListener, but it just doesn't feel right not to use submit buttons
where they are needed.
Is there a new way to do this (maybe using the annotations) or is the ajax
form submit functionality just not implemented yet?
Cheers
Denis Souza
