Re: Handling the fileuploadexception
Hi again, apologies for multiple posts.
I would actually really be interested in a file type validator as I am
currently doing this on the server too - in the onValidateFromX, which
fires after the upload has happened.
I'll wait for some feedback on this one before creating a file type
validator, but I will do that too (taking into account any notes on
this one).
Perhaps these two together could be added to Tapestry-Uploads or as a
separate dependency. I would think that any site which has upload
functionality wants to have something to stop massive files being
uploaded, and I would also expect that clearing the form is
problematic for most of those sites, so i'm still a bit surprised this
hasn't been an issue for anyone else.
Thanks,
Steve
On 11 June 2015 at 21:51, Stephen Nutbrown steves...@gmail.com wrote:
Hello!
I am back, and with a working solution. Before using this solution for
any of your own projects, please take the following into
consideration:
- I am not an experienced javascript developer, i've done my best to
hack something together based on tapestrys own validation.js and the
stackoverflow post which was linked to.
- I haven't tested it on all browsers, but it should be supported on
all modern browsers (as per the other article I linked to), and I have
set the clientside validation to accept it if the required support
isn't there - the server side validation will catch it but it's more
efficient to catch it client side.
- I have absolutely no clue how to package this up into a .jar file to
make it easier to distribute, ideally it would be nice if this is
taken as a proof of concept and added to tapestry-upload, or if it was
made into a .jar which was distributed on maven - unfortunately this
would be a bit of a learning curve for me and i'm so busy it's
unbelievable. Of course if you have the time to take my code and do
that with it, please do and share it - do with it whatever you want.
One day I would like to be a Tapestry contributor, but it'll take me a
while to be ready.
That said, here it is (I'm sure Thiago or someone else will probably
correct some parts if it's wrong):
- maxfilesize.js (attached) belongs in src/main/resources/META-INF/modules
- MaxUploadSize.java belongs where you want to place it, I put it in a
validators package, so for me it is
src/main/java/com/football/news/validators, but for you it will be
src/main/java/your/project/package
- I added the following line to my app.properties
(src/main/webapp/WEB-INF/app.properties), perhaps there is a better
properties file for this:
data-validate-filesize=The file size is too big.
- I contributed the validator in my AppModule, like this:
public static void
contributeFieldValidatorSource(MappedConfigurationString, Validator
configuration, final JavaScriptSupport javaScriptSupport) {
configuration.add(fileSizeValidator, new
MaxUploadSize(Integer.class, UploadedFile.class,
data-validate-filesize, javaScriptSupport));
}
I'm trying to help others by uploading this, but please take my
solution with a pinch of salt, some parts of tapestry are still some
unknown magic to me.
Any feedback is really appreciated, it will help people seeing this in
future and will also help me to update my local version. I would think
a filetype validator similar to this one would also be possible.
Thanks,
Steve
On 10 June 2015 at 08:52, Stephen Nutbrown steves...@gmail.com wrote:
Hi,
Yes, copying and adapting one for the validators is exactly what I did
in the end using the twitter library they have. However, I found it a
bit difficult to do because the current validator seems to use a
coffee script (Something i'm not familiar with, I struggle with JS as
it is!). So I ended up getting the validator.js from running my T5
program and downloading it (I'm sure there is a better way, but I
couldn't find this .js file otherwise), and then I had to figure out
how to use require.js properly as I wasn't used to it. I'm sure now I
know how to do it, it'll be easy enough, but when I did the twitter
one it actually took me a fair bit of time to figure out how to do it
- but I got there in the end.
Perhaps when I make this i'll note down some steps and I can post them
somewhere to make it easier for other people. It might be a few days
until I get the time, but i'll certainly do that.
Thanks,
Steve
On 10 June 2015 at 01:38, Thiago H de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, 09 Jun 2015 19:01:33 -0300, Stephen Nutbrown steves...@gmail.com
wrote:
Hi,
Hi!
I saw some posts on StackOverflow about validating files using
JavaScript's
files api (it looks fairly new so may not be suitable for projects which
need to support old browsers):
Re: Handling the fileuploadexception
Hi, Yes, copying and adapting one for the validators is exactly what I did in the end using the twitter library they have. However, I found it a bit difficult to do because the current validator seems to use a coffee script (Something i'm not familiar with, I struggle with JS as it is!). So I ended up getting the validator.js from running my T5 program and downloading it (I'm sure there is a better way, but I couldn't find this .js file otherwise), and then I had to figure out how to use require.js properly as I wasn't used to it. I'm sure now I know how to do it, it'll be easy enough, but when I did the twitter one it actually took me a fair bit of time to figure out how to do it - but I got there in the end. Perhaps when I make this i'll note down some steps and I can post them somewhere to make it easier for other people. It might be a few days until I get the time, but i'll certainly do that. Thanks, Steve On 10 June 2015 at 01:38, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 09 Jun 2015 19:01:33 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi, Hi! I saw some posts on StackOverflow about validating files using JavaScript's files api (it looks fairly new so may not be suitable for projects which need to support old browsers): https://www.google.co.uk/url?sa=tsource=webrct=jei=omB3Vb_MKKi07QbRvoDYBQurl=http://stackoverflow.com/questions/3717793/javascript-file-upload-size-validationved=0CB0QFjAAusg=AFQjCNGck_7qB8b7VzFExHQM72vzF6JxZAsig2=XgAbDcP-E8-daXfAyP0tEg Interesting! Thanks! I learned something new today . . . Some time ago I implemented a client side twitter validator to check the length of text field values (it gets a bit complicated because links count as fewer characters etc). Twitter has a JS library that does this character counting, so it's just a matter of copying and adapting the MaxLength validator from Tapestry. I can have a go at doing the same for the fileuploader and can put whatever I make up on github somewhere. Don't forget to post an announcement here. :) It won't work on old browsers as per: https://www.google.co.uk/url?sa=tsource=webrct=jei=Y2F3Vbf0IIet7AarkoLgBAurl=http://caniuse.com/fileapived=0CB0QFjAAusg=AFQjCNEufMjex_NEpHKkWV7k-pakFWDNJQsig2=-hTtFzGroBPZc9w0v1bGIA I'm a bit surprised that this doesn't exist, What's this? :) I thought it would and so I expected that I was doing something horribly wrong. I'll come back when I have it working as it may help others. Thanks, Steve On 9 Jun 2015 20:06, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 09 Jun 2015 14:39:54 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi Thiago, Hi! That's interesting. Perhaps the documentation wants updating. It says: Note the importance of return this;. A void event handler method, or one that returns null, will result in the FileUploadException being reported to the user as an uncaught runtime exception. https://tapestry.apache.org/uploading-files.html Not returning this isn't just for uploading exceptions: it's for all event handler methods, so I don't think it makes sense to put this warning in uploading-files.html. In your original code, returning this, if you annotated your field with @Persist(PersistenceConstants.FLASH), the message would appear. In this very case, it appears to be the right thing to do (return this), as otherwise Tapestry still considers the event as not handled and the generic exception handling is used. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - 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
Handling the fileuploadexception
Hi,
I have a page with a form on, one field is a FileUpload. It takes a
while for the user to fill out this form. The validation is set to
limit the upload to 500kb, I have done this by adding this to the
AppModule:
configuration.add(UploadSymbols.FILESIZE_MAX, 50);
When the file is too large, an exception is thrown and a page event is
triggered which looks a bit like this:
Object onUploadException(FileUploadException ex) {
message = The file is too large, please resize it to be less than 500kb.;
return this;
}
I'm following the information in the documentation
here:https://tapestry.apache.org/uploading-files.html
My two problems/questions are:
1- If I record an error on the form using something like:
createForm.recordError(Your file is too big);
This does not show. I have worked around this by adding a message
property which is checked and if it's not null, we show it on the
page. It is persisted with the Flash strategy, this seems to work, but
isn't ideal as it would be nice to have all the validation done in the
same way.
2- It then clears the form. Unfortunately the other parts of the form
are not persisted. Perhaps this is because T5 cut stopped the client
finishing the POST request (maybe a good thing), I am not sure. Is
there anything that can be done to persist the rest of the data so the
user doesn't then need to do everything again?
I think ideally (what I envisage) is some client side validation of
the file size which means the request is never sent, so we don't need
to worry about persistance, and perhaps we can show the error on the
field itself (just like how validate works on other fields, like
validate=required, but for this perhaps validate=50.
Is this possible? I would think this is a fairly normal requirement,
so i'd be surprised if it's not already somehow done.
Thanks,
Steve
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Handling the fileuploadexception
On Tue, 09 Jun 2015 14:42:44 -0300, Stephen Nutbrown steves...@gmail.com
wrote:
Hi,
Hi!
If there is no client side validation for the fileupload, is it
possible (and not too difficult) for me to create one for the file
upload component?
Check the org.apache.tapestry5.validator.Required sources for an example
of a validator which does both server- and client-side validation. You
need to contribute your validation implementation to FeildValidatorSource
in a Tapestry-IoC module class such as AppModule:
public static void
contributeFieldValidatorSource(MappedConfigurationString, Validator
configuration)
{
configuration.add(required, new Required());
}
What I don't have an answer to you is how to check the file size in
JavaScript. If you find a solution, please post it here.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Handling the fileuploadexception
On Tue, 09 Jun 2015 14:39:54 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi Thiago, Hi! That's interesting. Perhaps the documentation wants updating. It says: Note the importance of return this;. A void event handler method, or one that returns null, will result in the FileUploadException being reported to the user as an uncaught runtime exception. https://tapestry.apache.org/uploading-files.html Not returning this isn't just for uploading exceptions: it's for all event handler methods, so I don't think it makes sense to put this warning in uploading-files.html. In your original code, returning this, if you annotated your field with @Persist(PersistenceConstants.FLASH), the message would appear. In this very case, it appears to be the right thing to do (return this), as otherwise Tapestry still considers the event as not handled and the generic exception handling is used. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Handling the fileuploadexception
Hi,
If I change it to void I get an uncaught exception and I end up going
to my custom exception page (This just says something went wrong, logs
the exception and returns the user to the homepage).
If there is no client side validation for the fileupload, is it
possible (and not too difficult) for me to create one for the file
upload component?
Thanks,
Steve
On 9 June 2015 at 18:39, Stephen Nutbrown steves...@gmail.com wrote:
Hi Thiago,
That's interesting. Perhaps the documentation wants updating. It says:
Note the importance of return this;. A void event handler method, or
one that returns null, will result in the FileUploadException being
reported to the user as an uncaught runtime exception.
https://tapestry.apache.org/uploading-files.html
Perhaps if I change it to void it may keep my values, i'll give it a try.
Thanks,
Steve
On 9 June 2015 at 18:25, Thiago H de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, 09 Jun 2015 14:05:49 -0300, Stephen Nutbrown steves...@gmail.com
wrote:
Hi,
Hi!
Object onUploadException(FileUploadException ex) {
message = The file is too large, please resize it to be less than
500kb.;
return this;
}
Never return this in an event handler unless you want to force a
redirection. Return null or void.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
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: Handling the fileuploadexception
On Tue, 09 Jun 2015 14:05:49 -0300, Stephen Nutbrown steves...@gmail.com
wrote:
Hi,
Hi!
Object onUploadException(FileUploadException ex) {
message = The file is too large, please resize it to be less than
500kb.;
return this;
}
Never return this in an event handler unless you want to force a
redirection. Return null or void.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Handling the fileuploadexception
Hi Thiago,
That's interesting. Perhaps the documentation wants updating. It says:
Note the importance of return this;. A void event handler method, or
one that returns null, will result in the FileUploadException being
reported to the user as an uncaught runtime exception.
https://tapestry.apache.org/uploading-files.html
Perhaps if I change it to void it may keep my values, i'll give it a try.
Thanks,
Steve
On 9 June 2015 at 18:25, Thiago H de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, 09 Jun 2015 14:05:49 -0300, Stephen Nutbrown steves...@gmail.com
wrote:
Hi,
Hi!
Object onUploadException(FileUploadException ex) {
message = The file is too large, please resize it to be less than
500kb.;
return this;
}
Never return this in an event handler unless you want to force a
redirection. Return null or void.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
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: Handling the fileuploadexception
Hi, I saw some posts on StackOverflow about validating files using JavaScript's files api (it looks fairly new so may not be suitable for projects which need to support old browsers): https://www.google.co.uk/url?sa=tsource=webrct=jei=omB3Vb_MKKi07QbRvoDYBQurl=http://stackoverflow.com/questions/3717793/javascript-file-upload-size-validationved=0CB0QFjAAusg=AFQjCNGck_7qB8b7VzFExHQM72vzF6JxZAsig2=XgAbDcP-E8-daXfAyP0tEg Some time ago I implemented a client side twitter validator to check the length of text field values (it gets a bit complicated because links count as fewer characters etc). I can have a go at doing the same for the fileuploader and can put whatever I make up on github somewhere. It won't work on old browsers as per: https://www.google.co.uk/url?sa=tsource=webrct=jei=Y2F3Vbf0IIet7AarkoLgBAurl=http://caniuse.com/fileapived=0CB0QFjAAusg=AFQjCNEufMjex_NEpHKkWV7k-pakFWDNJQsig2=-hTtFzGroBPZc9w0v1bGIA I'm a bit surprised that this doesn't exist, I thought it would and so I expected that I was doing something horribly wrong. I'll come back when I have it working as it may help others. Thanks, Steve On 9 Jun 2015 20:06, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 09 Jun 2015 14:39:54 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi Thiago, Hi! That's interesting. Perhaps the documentation wants updating. It says: Note the importance of return this;. A void event handler method, or one that returns null, will result in the FileUploadException being reported to the user as an uncaught runtime exception. https://tapestry.apache.org/uploading-files.html Not returning this isn't just for uploading exceptions: it's for all event handler methods, so I don't think it makes sense to put this warning in uploading-files.html. In your original code, returning this, if you annotated your field with @Persist(PersistenceConstants.FLASH), the message would appear. In this very case, it appears to be the right thing to do (return this), as otherwise Tapestry still considers the event as not handled and the generic exception handling is used. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Handling the fileuploadexception
On Tue, 09 Jun 2015 19:01:33 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi, Hi! I saw some posts on StackOverflow about validating files using JavaScript's files api (it looks fairly new so may not be suitable for projects which need to support old browsers): https://www.google.co.uk/url?sa=tsource=webrct=jei=omB3Vb_MKKi07QbRvoDYBQurl=http://stackoverflow.com/questions/3717793/javascript-file-upload-size-validationved=0CB0QFjAAusg=AFQjCNGck_7qB8b7VzFExHQM72vzF6JxZAsig2=XgAbDcP-E8-daXfAyP0tEg Interesting! Thanks! I learned something new today . . . Some time ago I implemented a client side twitter validator to check the length of text field values (it gets a bit complicated because links count as fewer characters etc). Twitter has a JS library that does this character counting, so it's just a matter of copying and adapting the MaxLength validator from Tapestry. I can have a go at doing the same for the fileuploader and can put whatever I make up on github somewhere. Don't forget to post an announcement here. :) It won't work on old browsers as per: https://www.google.co.uk/url?sa=tsource=webrct=jei=Y2F3Vbf0IIet7AarkoLgBAurl=http://caniuse.com/fileapived=0CB0QFjAAusg=AFQjCNEufMjex_NEpHKkWV7k-pakFWDNJQsig2=-hTtFzGroBPZc9w0v1bGIA I'm a bit surprised that this doesn't exist, What's this? :) I thought it would and so I expected that I was doing something horribly wrong. I'll come back when I have it working as it may help others. Thanks, Steve On 9 Jun 2015 20:06, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: On Tue, 09 Jun 2015 14:39:54 -0300, Stephen Nutbrown steves...@gmail.com wrote: Hi Thiago, Hi! That's interesting. Perhaps the documentation wants updating. It says: Note the importance of return this;. A void event handler method, or one that returns null, will result in the FileUploadException being reported to the user as an uncaught runtime exception. https://tapestry.apache.org/uploading-files.html Not returning this isn't just for uploading exceptions: it's for all event handler methods, so I don't think it makes sense to put this warning in uploading-files.html. In your original code, returning this, if you annotated your field with @Persist(PersistenceConstants.FLASH), the message would appear. In this very case, it appears to be the right thing to do (return this), as otherwise Tapestry still considers the event as not handled and the generic exception handling is used. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
