kein Betreff
Hello,
i have some problems with the submit component and the parameter t:image.
The following works fine with T5.1.0.5
form t:type=form t:id=myform
input type=submit t:type=submit t:id=viewselection title=View/
/form
and as expected the following methods are called
@OnEvent(component=viewselection, value = EventConstants.SELECTED)
void someMethodName() {
logger.debug(With EventConstants);
}
void onSelectedFromViewselection() {
logger.debug(With onSelectedFromId);
}
@OnEvent(value = selected, component = viewselection)
void someOtherMethodName() {
logger.debug(With @OnEvent);
}
but if i want to use an image for the submit none of those methods are called
(the image will be rendered correctly).
I've used each of the following
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
t:submit t:id=viewselection title=view t:image=context:images/view.png/
Whats wrong?
TIA,
Oliver
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
T5.1.0.5 Submit with image (was Re: kein Betreff)
Sorry for the missing subject
Hello,
i have some problems with the submit component and the parameter t:image.
The following works fine with T5.1.0.5
form t:type=form t:id=myform
input type=submit t:type=submit t:id=viewselection title=View/
/form
and as expected the following methods are called
@OnEvent(component=viewselection, value = EventConstants.SELECTED)
void someMethodName() {
logger.debug(With EventConstants);
}
void onSelectedFromViewselection() {
logger.debug(With onSelectedFromId);
}
@OnEvent(value = selected, component = viewselection)
void someOtherMethodName() {
logger.debug(With @OnEvent);
}
but if i want to use an image for the submit none of those methods are called
(the image will be rendered correctly).
I've used each of the following
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
t:submit t:id=viewselection title=view
t:image=context:images/view.png/
Whats wrong?
TIA,
Oliver
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
__
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1.0.5 Submit with image (was Re: kein Betreff)
https://issues.apache.org/jira/browse/TAP5-711
On 01.09.2009 09:27 schrieb Oliver Bauer:
Sorry for the missing subject
Hello,
i have some problems with the submit component and the parameter t:image.
The following works fine with T5.1.0.5
form t:type=form t:id=myform
input type=submit t:type=submit t:id=viewselection title=View/
/form
and as expected the following methods are called
@OnEvent(component=viewselection, value = EventConstants.SELECTED)
void someMethodName() {
logger.debug(With EventConstants);
}
void onSelectedFromViewselection() {
logger.debug(With onSelectedFromId);
}
@OnEvent(value = selected, component = viewselection)
void someOtherMethodName() {
logger.debug(With @OnEvent);
}
but if i want to use an image for the submit none of those methods are called
(the image will be rendered correctly).
I've used each of the following
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
input type=submit t:type=submit t:id=viewselection title=View
t:image=context:images/view.png/
t:submit t:id=viewselection title=view t:image=context:images/view.png/
Whats wrong?
TIA,
Oliver
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
__
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Testify and Tapestry 5.0.18
Szemere Szemere szemereszem...@googlemail.com wrote on 27/08/2009 16:14:16: Excuse my ignorance, does Testify work with Tapestry 5.0.18? The current version of Testify seems to require Tapestry 5.1.05. Is there a version that works with 5.0.18 Sorry - Testify uses some features of the Tapestry 5.1 IOC container to disable certain parts of the usual component/page bytecode generation and replace them with its own. Paul --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: Multiple images
Tapestry 4. Thank you. Howard Lewis Ship wrote: Tapestry 4 or Tapestry 5? On Sun, Aug 30, 2009 at 6:59 PM, chitraaachitral...@gmail.com wrote: Hi, Did you manage to find a solution to this? I am also trying to render multiple chart images into the same page. However, the service renders the same image (the last one). Thanks. Olexandr Yuzikov wrote: Hi, everyone. I have a problem to represent a couple of images stored in database. The page has a property of type List with beans that keeps images in byte arrays. I need to render those images in the iterator on the same page. It seems may be like in tapestry Workbench tutorial with a dynamic chart but with more than one image. I did like in tutorial but service always renders the same image (generally the last in the list). Does anybody have any experience to render more than one image on the page? Thanks for answering. -- View this message in context: http://www.nabble.com/Multiple-images-tp387585p25217486.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- View this message in context: http://www.nabble.com/Multiple-images-tp387585p25238644.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Multiple images
check the urls to the images... is it possible they're all the same? On Tue, Sep 1, 2009 at 2:28 PM, chitraaachitral...@gmail.com wrote: Tapestry 4. Thank you. Howard Lewis Ship wrote: Tapestry 4 or Tapestry 5? On Sun, Aug 30, 2009 at 6:59 PM, chitraaachitral...@gmail.com wrote: Hi, Did you manage to find a solution to this? I am also trying to render multiple chart images into the same page. However, the service renders the same image (the last one). Thanks. Olexandr Yuzikov wrote: Hi, everyone. I have a problem to represent a couple of images stored in database. The page has a property of type List with beans that keeps images in byte arrays. I need to render those images in the iterator on the same page. It seems may be like in tapestry Workbench tutorial with a dynamic chart but with more than one image. I did like in tutorial but service always renders the same image (generally the last in the list). Does anybody have any experience to render more than one image on the page? Thanks for answering. -- View this message in context: http://www.nabble.com/Multiple-images-tp387585p25217486.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- View this message in context: http://www.nabble.com/Multiple-images-tp387585p25238644.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: FCKEditor Ajax Form Submit
newtonik schrieb:
Hey,
Has anyone been able to figure out a way to use the FCKEditor in a ajax form
submission. It seems like the data in the editor doesn't get assigned during
a ajax submit. This prevents me using formzone when I have fckeditors
textarea. Has anyone worked around this issue? Thanks.
Newton
There is event provided by fckeditor to ensure that the editor value is
synchronized with the input field.
Here is a jquery snippet
$j(form.evaluateForm).bind('form-pre-serialize', function() {
var e = FCKeditorAPI.GetInstance('comment') ;
e.UpdateLinkedField();
});
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: FCKEditor Ajax Form Submit
Em Tue, 01 Sep 2009 11:43:45 -0300, newtonik newto...@gmail.com escreveu:
Hey,
Hi!
Has anyone been able to figure out a way to use the FCKEditor in a ajax
form submission. It seems like the data in the editor doesn't get
assigned during a ajax submit. This prevents me using formzone when I
have fckeditors
textarea. Has anyone worked around this issue? Thanks.
The solution I've found was to add the following JavaScript snippet:
Event.observe('form', 'submit', function() {
FCKeditorAPI.Instances['editor'].UpdateLinkedField(); });
Replace editor with your field id.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: FCKEditor Ajax Form Submit
Thanks Guys,
Works very well!
Newton
Thiago H. de Paula Figueiredo wrote:
Em Tue, 01 Sep 2009 11:43:45 -0300, newtonik newto...@gmail.com
escreveu:
Hey,
Hi!
Has anyone been able to figure out a way to use the FCKEditor in a ajax
form submission. It seems like the data in the editor doesn't get
assigned during a ajax submit. This prevents me using formzone when I
have fckeditors
textarea. Has anyone worked around this issue? Thanks.
The solution I've found was to add the following JavaScript snippet:
Event.observe('form', 'submit', function() {
FCKeditorAPI.Instances['editor'].UpdateLinkedField(); });
Replace editor with your field id.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
View this message in context:
http://www.nabble.com/FCKEditor-Ajax-Form-Submit-tp25241614p25242223.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Testify and Injecting Services from IOC Registry
Mark W. Shead mwsh...@fas.harvard.edu wrote on 28/08/2009 21:36:55:
Hm it appears to give me a copy of the registry, but not the same
instance that was used for testing the pages.
I'm not too sure what you mean by not the same instance that was used for
testing the pages but I'm going to guess that you are running some unit
tests as well as some Selenium tests in the same process (test run).
If that's true, then my code will create a TapestryTester for all the
selenium tests but you may already have a TapestryTester that is shared
for all your unit tests. The TapestryTester contains a complete IOC so
you'll have two IOCs at the same time (which may or may not be a problem).
There are two approaches to solving the problem.
The first is to point to point the selenium tests at the TapestryTester
that you already have. So, instead of this from my code:
public abstract class MyAbstractIntegrationTest extends
AbstractIntegrationTestSuite {
protected static final TapestryTester tester =
new TapestryTester(com.myapp.tapestry5, app,
PageTester.DEFAULT_CONTEXT_PATH);
Use something like this instead:
public abstract class MyAbstractIntegrationTest extends
AbstractIntegrationTestSuite {
protected static final TapestryTester tester = AbstractMyUnitTest.
SHARED_TESTER;
This has the advantage of creating just one IOC and sharing it - which is
fine if you genuinely want the same IOC in both contexts.
The second option is to use TestNG's lifecycle annotations to control the
scope of each of the IOCs. I suspect organising the selenium and the unit
tests as two separate tests in TestNG and using the @BeforeTest and
@AfterTest annotations might be the right thing:
@BeforeTest(alwaysRun=true)
public void startup() {
tester = new TapestryTester(...);
}
@AfterTest(alwaysRun=true)
public void shutdown() {
tester.shutdown();
}
You'll need one set of the two methods for your Selenium tests and another
set for your unit tests. However, I'm not a TestNG expert so I might be on
the wrong track with this suggestion.
- Paul
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional
EU corporate and regulatory disclosures.
Re: Ajax and Validation
Hi Geoffrey (and others), Did you ever figure out a workaround for this issue? I have: t:zone t:id=wizard t:update=show id=wizard ... t:block t:id=enterEmail t:form t:id=inputs t:zone=wizard h3Enter E-mail Address/h3 div t:type=Errors/ And when I record e-mail address problems in the form, the t:errors never renders (unless I reload the page as you said). At this point, I'll either have to add my own error message presentation or give up on zones since they don't show the validation errors. Thanks, mrg On Wed, Apr 22, 2009 at 4:38 PM, Geoffrey Wisemangeoffrey.wise...@gmail.com wrote: I wasn't sure if Tapestry did any magic under the covers to work with server-side validation and ajax form submits. I did a quick experiment and it doesn't seem to: - Create a form, give it a zone to do ajax submit. - Create an onValidateForm method, throw a ValidationException from it. - Load up the application. Submit the form. - The zone gets updated, no validation messages appear. No big surprises so far -- this is Ajax form submits and the fact that validation isn't meant to work with it, near as I can tell. The next part, however, worries me a little: - Refresh the page, or go the same URL. - The page renders as if you'd just submitted the form. The field is populated an there's a visible error block. - I don't have any Persist annotations here or anything, so I'm a little disturbed that it's retaining a form value and validation state despite that. Am I missing something, or is this some kind of ugly edge case around ajax and form validation? Now you could argue that ajax form submits and validation don't belong together, which I might agree with. I'd have to understand how Tapestry handles graceful degradation in order to argue the point. On a side note, I'd love to be able to throw a t:errors outside of a form in a block and point it /to/ the form to use that to display validation errors. (e.g. t:block t:id=errorst:errors t:form=save //t:block) - Geoffrey -- Geoffrey Wiseman http://www.geoffreywiseman.ca/ - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Hello, the intended validation method for cross field validation is onValidateForm The onSuccess is probable the latest point to do validation. I would only place business logic related validation in there You may do field validation in the onValidateForm as well but it is normally simpler, faster and cleaner to do this using annotations. If you want to do field validation in the onValidateForm I would not follow the approach of newtonic and write if then statements but to create a simple builder (see Effective Java). Sample without reflection inside of the builder Validator userVal = ValidatorBuilder.required().minLenth(3).maxLength(60).build(); usage in onValidateForm userVal.validate(user.getName); You could leverage this using reflection -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de Benny Law schrieb: Hi Onno, I am all for clean and maintainable code, and that's why I think ValidateForm can be cleaner if I didn't need to check for field errors first. On the main Tapestry 5.1 page, the Login example calls the authenticator in onValidateForm, but the same example in the User Guide under Input Validation does that in onSuccess. I think the latter is correct; the former won't work properly because it acts on the properties bound to the fields which may not reflect the current field contents if there are field validation errors. To fix the first example, some code needs to be added to onValidateForm to check if the fields have passed field-level validations before invoking the authenticator. I hope this clarifies what I am thinking. Thanks. Benny On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl wrote: Thanks for your response. Could you explain what you mean by keeping my validation in the correct callback? I think it's about writing clean and maintainable code. For other developers reading back your code it makes more sense if you add your validation errors in the ValidateForm event and to perform some (database?) action in the success handler. The ValidateForm event is where validation errors are added and some of them are automatically taken care of for you by the Tapestry validator mechanism. If you don't want to add more than one error-message, you can easily check if the field is in error already. Sometimes it also makes sense to add mutiple errors per field since you're telling the user immediately what (s)he's doing wrong instead of having them re-submit again only to find yet another validation error on the same field. regards, Onno - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Thanks Sebastian. I agree that only business logic related validation should go into onSuccess, and I would leave basic field validations to validators as much as possible. My problem with onValidateForm is still the amount of code I need to write to check for existing errors before I can do cross field validation. Let me give a quick example: Suppose I have two date fields, Start Date and End Date. I would use the built-in validators to check for missing values and invalid dates. However, in order to cross-validate these dates (to ensure Start Date is not later than End Date) in onValidateForm, I would need to inject the two fields, get the tracker from the form, and call inError() to find out if any of the dates are invalid (missing or bad syntax). If there are no errors, then I can compare the date properties bound to the fields. Do you see what I am getting at? Doing this in onSuccess is a lot easier since I won't need to check for existing errors, and I know that the date properties bound to the fields have been updated. Ideally, I would love to have another version of ValidateForm event which is fired before Success and only if there are no errors. Benny On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder use...@laliluna.dewrote: Hello, the intended validation method for cross field validation is onValidateForm The onSuccess is probable the latest point to do validation. I would only place business logic related validation in there You may do field validation in the onValidateForm as well but it is normally simpler, faster and cleaner to do this using annotations. If you want to do field validation in the onValidateForm I would not follow the approach of newtonic and write if then statements but to create a simple builder (see Effective Java). Sample without reflection inside of the builder Validator userVal = ValidatorBuilder.required().minLenth(3).maxLength(60).build(); usage in onValidateForm userVal.validate(user.getName); You could leverage this using reflection -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de Benny Law schrieb: Hi Onno, I am all for clean and maintainable code, and that's why I think ValidateForm can be cleaner if I didn't need to check for field errors first. On the main Tapestry 5.1 page, the Login example calls the authenticator in onValidateForm, but the same example in the User Guide under Input Validation does that in onSuccess. I think the latter is correct; the former won't work properly because it acts on the properties bound to the fields which may not reflect the current field contents if there are field validation errors. To fix the first example, some code needs to be added to onValidateForm to check if the fields have passed field-level validations before invoking the authenticator. I hope this clarifies what I am thinking. Thanks. Benny On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl wrote: Thanks for your response. Could you explain what you mean by keeping my validation in the correct callback? I think it's about writing clean and maintainable code. For other developers reading back your code it makes more sense if you add your validation errors in the ValidateForm event and to perform some (database?) action in the success handler. The ValidateForm event is where validation errors are added and some of them are automatically taken care of for you by the Tapestry validator mechanism. If you don't want to add more than one error-message, you can easily check if the field is in error already. Sometimes it also makes sense to add mutiple errors per field since you're telling the user immediately what (s)he's doing wrong instead of having them re-submit again only to find yet another validation error on the same field. regards, Onno - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Multiple images
In a nutshell, the way I did it was to implement IAsset for each
dynamic chart which then gets fetched by component id in the
IEngineService and asked to render itself to the given WebResponse.
Or put another way...
I have 2 dynamic chart images In my Foo.html page definition:
img class=statGraph width=235 height=135 jwcid=@Image
image=ognl:clientStats title= alt= /
img class=statGraph width=235 height=135 jwcid=@Image
image=ognl:sessionStats title= alt= /
I've defined
public abstract class ImageAsset implements IAsset
{
public void renderImage(OutputStream os) throws IOException ;
}
In Foo.java page class:
public ImageAsset getClientStats() { return new ClientStatsAsset(); }
public ImageAsset getSessionStats() { return new SessionStatsAsset(); }
Finally, in my ImageService (implements IEngineService):
public void service(IRequestCycle cycle) throws IOException
{
String pageName = cycle.getParameter(ServiceConstants.PAGE);
String idPath = cycle.getParameter(ServiceConstants.COMPONENT);
String option = cycle.getParameter(ImageAsset.OPTION);
IPage page = cycle.getPage(pageName);
IComponent component = page.getNestedComponent(idPath);
WebResponse response = cycle.getInfrastructure().getResponse();
try {
((ImageProvider) component).generateImage(response, new Object[]
{option});
}
catch (ClassCastException ex) {
exceptionReporter.reportRequestException(Fatal Error
0xa8, ex);
}
catch (Throwable ex) {
exceptionReporter.reportRequestException(Fatal Error
0x32, ex);
}
}
On Sep 1, 2009, at 6:28 AM, chitraa wrote:
Tapestry 4.
Thank you.
Howard Lewis Ship wrote:
Tapestry 4 or Tapestry 5?
On Sun, Aug 30, 2009 at 6:59 PM, chitraaachitral...@gmail.com
wrote:
Hi,
Did you manage to find a solution to this? I am also trying to
render
multiple chart images into the same page. However, the service
renders
the
same image (the last one).
Thanks.
Olexandr Yuzikov wrote:
Hi, everyone.
I have a problem to represent a couple of images stored in
database. The
page has a property of type List with beans that keeps images in
byte
arrays. I need to render those images in the iterator on the same
page.
It
seems may be like in tapestry Workbench tutorial with a dynamic
chart
but
with more than one image. I did like in tutorial but service always
renders
the same image (generally the last in the list). Does anybody
have any
experience to render more than one image on the page?
Thanks for answering.
--
View this message in context:
http://www.nabble.com/Multiple-images-tp387585p25217486.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me
to
learn how I can get you up and productive in Tapestry fast!
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
View this message in context:
http://www.nabble.com/Multiple-images-tp387585p25238644.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Beware, there's a long-standing problem with recording errors in onSuccess(). https://issues.apache.org/jira/browse/TAPESTRY-1972 Geoff On 02/09/2009, at 7:59 AM, Benny Law wrote: Thanks Sebastian. I agree that only business logic related validation should go into onSuccess, and I would leave basic field validations to validators as much as possible. My problem with onValidateForm is still the amount of code I need to write to check for existing errors before I can do cross field validation. Let me give a quick example: Suppose I have two date fields, Start Date and End Date. I would use the built-in validators to check for missing values and invalid dates. However, in order to cross-validate these dates (to ensure Start Date is not later than End Date) in onValidateForm, I would need to inject the two fields, get the tracker from the form, and call inError() to find out if any of the dates are invalid (missing or bad syntax). If there are no errors, then I can compare the date properties bound to the fields. Do you see what I am getting at? Doing this in onSuccess is a lot easier since I won't need to check for existing errors, and I know that the date properties bound to the fields have been updated. Ideally, I would love to have another version of ValidateForm event which is fired before Success and only if there are no errors. Benny On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder use...@laliluna.dewrote: Hello, the intended validation method for cross field validation is onValidateForm The onSuccess is probable the latest point to do validation. I would only place business logic related validation in there You may do field validation in the onValidateForm as well but it is normally simpler, faster and cleaner to do this using annotations. If you want to do field validation in the onValidateForm I would not follow the approach of newtonic and write if then statements but to create a simple builder (see Effective Java). Sample without reflection inside of the builder Validator userVal = ValidatorBuilder.required().minLenth(3).maxLength(60).build(); usage in onValidateForm userVal.validate(user.getName); You could leverage this using reflection -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de Benny Law schrieb: Hi Onno, I am all for clean and maintainable code, and that's why I think ValidateForm can be cleaner if I didn't need to check for field errors first. On the main Tapestry 5.1 page, the Login example calls the authenticator in onValidateForm, but the same example in the User Guide under Input Validation does that in onSuccess. I think the latter is correct; the former won't work properly because it acts on the properties bound to the fields which may not reflect the current field contents if there are field validation errors. To fix the first example, some code needs to be added to onValidateForm to check if the fields have passed field-level validations before invoking the authenticator. I hope this clarifies what I am thinking. Thanks. Benny On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl wrote: Thanks for your response. Could you explain what you mean by keeping my validation in the correct callback? I think it's about writing clean and maintainable code. For other developers reading back your code it makes more sense if you add your validation errors in the ValidateForm event and to perform some (database?) action in the success handler. The ValidateForm event is where validation errors are added and some of them are automatically taken care of for you by the Tapestry validator mechanism. If you don't want to add more than one error-message, you can easily check if the field is in error already. Sometimes it also makes sense to add mutiple errors per field since you're telling the user immediately what (s)he's doing wrong instead of having them re-submit again only to find yet another validation error on the same field. regards, Onno - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Thanks for alerting me, Geoff. But even the input validation example in the User Guide shows recording error in onSuccess()! I must say I'm a bit alarmed by these quirks. I hope I don't find too many more surprises when I get deeper into Tapestry 5.1. I am working on a critical application under a tight deadline, and I am counting on Tapestry to help me deliver. I used Tapestry 3 before and loved it, but 5 is a totally new framework. Benny On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender geoff.callender.jumpst...@gmail.com wrote: Beware, there's a long-standing problem with recording errors in onSuccess(). https://issues.apache.org/jira/browse/TAPESTRY-1972 Geoff On 02/09/2009, at 7:59 AM, Benny Law wrote: Thanks Sebastian. I agree that only business logic related validation should go into onSuccess, and I would leave basic field validations to validators as much as possible. My problem with onValidateForm is still the amount of code I need to write to check for existing errors before I can do cross field validation. Let me give a quick example: Suppose I have two date fields, Start Date and End Date. I would use the built-in validators to check for missing values and invalid dates. However, in order to cross-validate these dates (to ensure Start Date is not later than End Date) in onValidateForm, I would need to inject the two fields, get the tracker from the form, and call inError() to find out if any of the dates are invalid (missing or bad syntax). If there are no errors, then I can compare the date properties bound to the fields. Do you see what I am getting at? Doing this in onSuccess is a lot easier since I won't need to check for existing errors, and I know that the date properties bound to the fields have been updated. Ideally, I would love to have another version of ValidateForm event which is fired before Success and only if there are no errors. Benny On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder use...@laliluna.dewrote: Hello, the intended validation method for cross field validation is onValidateForm The onSuccess is probable the latest point to do validation. I would only place business logic related validation in there You may do field validation in the onValidateForm as well but it is normally simpler, faster and cleaner to do this using annotations. If you want to do field validation in the onValidateForm I would not follow the approach of newtonic and write if then statements but to create a simple builder (see Effective Java). Sample without reflection inside of the builder Validator userVal = ValidatorBuilder.required().minLenth(3).maxLength(60).build(); usage in onValidateForm userVal.validate(user.getName); You could leverage this using reflection -- Best Regards / Viele Grüße Sebastian Hennebrueder - Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de Benny Law schrieb: Hi Onno, I am all for clean and maintainable code, and that's why I think ValidateForm can be cleaner if I didn't need to check for field errors first. On the main Tapestry 5.1 page, the Login example calls the authenticator in onValidateForm, but the same example in the User Guide under Input Validation does that in onSuccess. I think the latter is correct; the former won't work properly because it acts on the properties bound to the fields which may not reflect the current field contents if there are field validation errors. To fix the first example, some code needs to be added to onValidateForm to check if the fields have passed field-level validations before invoking the authenticator. I hope this clarifies what I am thinking. Thanks. Benny On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl wrote: Thanks for your response. Could you explain what you mean by keeping my validation in the correct callback? I think it's about writing clean and maintainable code. For other developers reading back your code it makes more sense if you add your validation errors in the ValidateForm event and to perform some (database?) action in the success handler. The ValidateForm event is where validation errors are added and some of them are automatically taken care of for you by the Tapestry validator mechanism. If you don't want to add more than one error-message, you can easily check if the field is in error already. Sometimes it also makes sense to add mutiple errors per field since you're telling the user immediately what (s)he's doing wrong instead of having them re-submit again only to find yet another validation error on the same field. regards, Onno - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANN] JumpStart 4.4 released
Hi Kalle, Good question. Yes, it does still seem to me to be best practice and no, I don't see it breaking the back button. Can you give an example? Regards, Geoff On 01/09/2009, at 8:37 AM, Kalle Korhonen wrote: Hey Geoff, I recall reading at some point that you had recommended not using onActivate() for all initialization purposes, and sure enough, I dug it up and at http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/navigation/onactivateandonpassivate/3 you say It can be tempting to put lots of setup code into onActivate(...). However, if the stuff you are setting up is not needed for component event requests, consider putting it elsewhere, such as setupRender() or getter methods. Does that still reflect your current understanding of the best practices? The caveat with using setupRender() (or anything else except for onActivate()) is that even for non-ajax applications, it breaks the back button, i.e. if a user goes back in history and say re-submits a form (for one reason or another) the objects required by the page/form are not initialized. Obviously it depends on the case what the application should do, but you loose half the benefits of redirect-after-post if your require a refresh before a page is usable again. Do you simple prefer rendering an an error in the back button/direct form submit case or do you generally do all initialization in onActivate()? Kalle On Tue, Aug 4, 2009 at 7:59 PM, Geoff Callendergeoff.callender.jumpst...@gmail.com wrote: Hi all, JumpStart 4.4 is now available. It's a tidying up release: the structure's a bit neater and it uses the latest OpenEJB, ie. 3.1.1. Use it live: http://jumpstart.doublenegative.com.au:8080/jumpstart/ or download it: http://jumpstart.doublenegative.com.au And if someone can figure how to get Jetty/OpenEJB in Eclipse to use the libs and classes in the WAR instead of having to be spoon-fed a classpath, then please let me know. I suspect it's a class-loading issue that might soon be solved by http://code.google.com/p/embed-openejb-in-eclipse/. Cheers, Geoff - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ValidateForm Event
Yes, let's hope the doco is updated soon!
https://issues.apache.org/jira/browse/TAP5-812
As for your conundrum, is there a reason you're not happy to do the
following? It's only a few lines and its intention seems very clear.
@Component(id = searchForm)
private Form _form;
void onValidateForm() {
if (_form.getHasErrors()) {
return;
}
...
Geoff
http://jumpstart.doublenegative.com.au:8080/jumpstart/
On 02/09/2009, at 12:20 PM, Benny Law wrote:
Thanks for alerting me, Geoff. But even the input validation example
in the
User Guide shows recording error in onSuccess()! I must say I'm a bit
alarmed by these quirks. I hope I don't find too many more
surprises when
I get deeper into Tapestry 5.1. I am working on a critical
application under
a tight deadline, and I am counting on Tapestry to help me deliver.
I used
Tapestry 3 before and loved it, but 5 is a totally new framework.
Benny
On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
Beware, there's a long-standing problem with recording errors in
onSuccess().
https://issues.apache.org/jira/browse/TAPESTRY-1972
Geoff
On 02/09/2009, at 7:59 AM, Benny Law wrote:
Thanks Sebastian. I agree that only business logic related validation
should
go into onSuccess, and I would leave basic field validations to
validators
as much as possible. My problem with onValidateForm is still the
amount of
code I need to write to check for existing errors before I can do
cross
field validation. Let me give a quick example:
Suppose I have two date fields, Start Date and End Date. I would
use the
built-in validators to check for missing values and invalid dates.
However,
in order to cross-validate these dates (to ensure Start Date is
not later
than End Date) in onValidateForm, I would need to inject the two
fields,
get
the tracker from the form, and call inError() to find out if any
of the
dates are invalid (missing or bad syntax). If there are no errors,
then I
can compare the date properties bound to the fields. Do you see
what I am
getting at?
Doing this in onSuccess is a lot easier since I won't need to
check for
existing errors, and I know that the date properties bound to the
fields
have been updated. Ideally, I would love to have another version of
ValidateForm event which is fired before Success and only if there
are no
errors.
Benny
On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
use...@laliluna.dewrote:
Hello,
the intended validation method for cross field validation is
onValidateForm
The onSuccess is probable the latest point to do validation. I
would only
place business logic related validation in there
You may do field validation in the onValidateForm as well but it is
normally simpler, faster and cleaner to do this using annotations.
If you want to do field validation in the onValidateForm I would
not
follow
the approach of newtonic and write if then statements
but to create a simple builder (see Effective Java).
Sample without reflection inside of the builder
Validator userVal =
ValidatorBuilder.required().minLenth(3).maxLength(60).build();
usage in onValidateForm
userVal.validate(user.getName);
You could leverage this using reflection
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
Benny Law schrieb:
Hi Onno,
I am all for clean and maintainable code, and that's why I think
ValidateForm can be cleaner if I didn't need to check for field
errors
first.
On the main Tapestry 5.1 page, the Login example calls the
authenticator
in
onValidateForm, but the same example in the User Guide under Input
Validation does that in onSuccess. I think the latter is
correct; the
former
won't work properly because it acts on the properties bound to the
fields
which may not reflect the current field contents if there are
field
validation errors. To fix the first example, some code needs to
be added
to
onValidateForm to check if the fields have passed field-level
validations
before invoking the authenticator.
I hope this clarifies what I am thinking. Thanks.
Benny
On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl
wrote:
Thanks for your response. Could you explain what you mean by
keeping my
validation in the correct callback?
I think it's about writing clean and maintainable code.
For other developers reading back your code it makes more sense
if you
add
your validation errors in the ValidateForm event and to perform
some
(database?) action in the success handler.
The ValidateForm event is where validation errors are added and
some of
them
are automatically taken care of for you by the Tapestry validator
mechanism.
If you don't want to add more than one error-message, you can
easily
check
if the field
Re: ValidateForm Event
That looks very reasonable. I think I will adopt this approach. Thanks
Geoff.
Benny
On Wed, Sep 2, 2009 at 1:02 AM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
Yes, let's hope the doco is updated soon!
https://issues.apache.org/jira/browse/TAP5-812
As for your conundrum, is there a reason you're not happy to do the
following? It's only a few lines and its intention seems very clear.
@Component(id = searchForm)
private Form _form;
void onValidateForm() {
if (_form.getHasErrors()) {
return;
}
...
Geoff
http://jumpstart.doublenegative.com.au:8080/jumpstart/
On 02/09/2009, at 12:20 PM, Benny Law wrote:
Thanks for alerting me, Geoff. But even the input validation example in
the
User Guide shows recording error in onSuccess()! I must say I'm a bit
alarmed by these quirks. I hope I don't find too many more surprises
when
I get deeper into Tapestry 5.1. I am working on a critical application
under
a tight deadline, and I am counting on Tapestry to help me deliver. I used
Tapestry 3 before and loved it, but 5 is a totally new framework.
Benny
On Tue, Sep 1, 2009 at 9:46 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
Beware, there's a long-standing problem with recording errors in
onSuccess().
https://issues.apache.org/jira/browse/TAPESTRY-1972
Geoff
On 02/09/2009, at 7:59 AM, Benny Law wrote:
Thanks Sebastian. I agree that only business logic related validation
should
go into onSuccess, and I would leave basic field validations to
validators
as much as possible. My problem with onValidateForm is still the amount
of
code I need to write to check for existing errors before I can do cross
field validation. Let me give a quick example:
Suppose I have two date fields, Start Date and End Date. I would use the
built-in validators to check for missing values and invalid dates.
However,
in order to cross-validate these dates (to ensure Start Date is not
later
than End Date) in onValidateForm, I would need to inject the two fields,
get
the tracker from the form, and call inError() to find out if any of the
dates are invalid (missing or bad syntax). If there are no errors, then
I
can compare the date properties bound to the fields. Do you see what I
am
getting at?
Doing this in onSuccess is a lot easier since I won't need to check for
existing errors, and I know that the date properties bound to the fields
have been updated. Ideally, I would love to have another version of
ValidateForm event which is fired before Success and only if there are
no
errors.
Benny
On Tue, Sep 1, 2009 at 3:39 PM, Sebastian Hennebrueder
use...@laliluna.dewrote:
Hello,
the intended validation method for cross field validation is
onValidateForm
The onSuccess is probable the latest point to do validation. I would
only
place business logic related validation in there
You may do field validation in the onValidateForm as well but it is
normally simpler, faster and cleaner to do this using annotations.
If you want to do field validation in the onValidateForm I would not
follow
the approach of newtonic and write if then statements
but to create a simple builder (see Effective Java).
Sample without reflection inside of the builder
Validator userVal =
ValidatorBuilder.required().minLenth(3).maxLength(60).build();
usage in onValidateForm
userVal.validate(user.getName);
You could leverage this using reflection
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
Benny Law schrieb:
Hi Onno,
I am all for clean and maintainable code, and that's why I think
ValidateForm can be cleaner if I didn't need to check for field errors
first.
On the main Tapestry 5.1 page, the Login example calls the
authenticator
in
onValidateForm, but the same example in the User Guide under Input
Validation does that in onSuccess. I think the latter is correct; the
former
won't work properly because it acts on the properties bound to the
fields
which may not reflect the current field contents if there are field
validation errors. To fix the first example, some code needs to be
added
to
onValidateForm to check if the fields have passed field-level
validations
before invoking the authenticator.
I hope this clarifies what I am thinking. Thanks.
Benny
On Mon, Aug 31, 2009 at 4:57 AM, Onno Scheffers o...@piraya.nl
wrote:
Thanks for your response. Could you explain what you mean by keeping
my
validation in the correct callback?
I think it's about writing clean and maintainable code.
For other developers reading back your code it makes more sense if
you
add
your validation errors in the ValidateForm event and to perform some
(database?) action in the success handler.
The ValidateForm event is where
