You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Nicola Tucci <ny...@gmail.com> on 2010/02/03 18:04:55 UTC

Where is the full client filename during FileUpload?

Hi all,
I'm using a FIleUpload form component in order to save the full client
filename (path + filename, i.e.
/home/jdoe/myfiles/MyUploadableDocument.pdf), but for what I can see, I can
retrieve only the filename using FileItem.getName().
I've tried to deeply debug wicket code to find the full path, but I only
find client filename, server temp name, content-type, size.

Someone on this forum states that browsers often send only the filename, not
the full path (security reason??), but how can servers bind the source file
without the full name? It must be somewhere, maybe in the servlet request...

Besides, there is a smarter way to retrieve the full name (the one that
appears in the input component!) without perform the upload? My use case
oblige me to use FileUpload form component because the user use browser's
popup search dialog.

Thanks to all,
BYE!

Re: Where is the full client filename during FileUpload?

Posted by Andrew Lombardi <an...@mysticcoders.com>.
FileUploadField takes a "FileUpload" model object which has a method called: getClientFileName

and as far as the path is concerned, it is saved to a temp file in a temp directory

On Feb 3, 2010, at 9:04 AM, Nicola Tucci wrote:

> Hi all,
> I'm using a FIleUpload form component in order to save the full client
> filename (path + filename, i.e.
> /home/jdoe/myfiles/MyUploadableDocument.pdf), but for what I can see, I can
> retrieve only the filename using FileItem.getName().
> I've tried to deeply debug wicket code to find the full path, but I only
> find client filename, server temp name, content-type, size.
> 
> Someone on this forum states that browsers often send only the filename, not
> the full path (security reason??), but how can servers bind the source file
> without the full name? It must be somewhere, maybe in the servlet request...
> 
> Besides, there is a smarter way to retrieve the full name (the one that
> appears in the input component!) without perform the upload? My use case
> oblige me to use FileUpload form component because the user use browser's
> popup search dialog.
> 
> Thanks to all,
> BYE!


To our success!

Mystic Coders, LLC | Code Magic | www.mysticcoders.com

ANDREW LOMBARDI | andrew@mysticcoders.com
2321 E 4th St. Ste C-128, Santa Ana CA 92705
ofc: 714-816-4488
fax: 714-782-6024
cell: 714-697-8046
linked-in: http://www.linkedin.com/in/andrewlombardi
twitter: http://www.twitter.com/kinabalu

Eco-Tip: Printing e-mails is usually a waste.

========================================================
This message is for the named person's use only. You must not, directly or indirectly, use,
 disclose, distribute, print, or copy any part of this message if you are not the intended recipient.
========================================================


Re: Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by David Chang <da...@yahoo.com>.
Martijn,

It is so nice of you to reply to my questions. One question I have about your book:

The bottom of Page xxi says: .. from Terracotta for giving Wicket a vaiable scaling strategy.

What do you exactly mean by that? Do you mean Terracotta makes the stateful programming model less of a concern in terms of memory consumption?

Regards,
David


--- On Fri, 2/5/10, Martijn Dashorst <ma...@gmail.com> wrote:

> From: Martijn Dashorst <ma...@gmail.com>
> Subject: Re: Fix super(new CompoundPropertyModel(this)) error in the WIA book
> To: users@wicket.apache.org
> Date: Friday, February 5, 2010, 7:09 AM
> On Fri, Feb 5, 2010 at 10:16 AM,
> Wilhelmsen Tor Iver <To...@arrive.no>
> wrote:
> >>   super(new CompoundPropertyModel(this));
> >
> > This seems wrong: A call to super() cannot reference
> "this" directly or indirectly:
> >
> > JLS §8.8.7 says:
> > "It is a compile-time error for a constructor to
> directly or indirectly invoke itself through a series of one
> or more explicit constructor invocations involving this."
> 
> Yup, this is a bug in the book's example code. Has nothing
> to do with
> 1.3 or 1.4.
> 
> And yes, the book is still valid apart from the model
> changes. My
> guess is that 1.5 will invalidate a bit more, but not too
> much. Mostly
> the part about page mounting and nice URLs will change. The
> internal
> request processing implementation is completely rewritten,
> but that
> should be transparent to the most of us (and was not
> covered in the
> book). The same goes for Wicket Ajax: completely
> rewritten,
> transparent for most users.
> 
> Martijn
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by Riyad Kalla <rk...@gmail.com>.
As someone working his way through WIA as well, will there be another wiki
entry showing differences between book and 1.5? (I'm fairly interested in
page mounting and nice URLs as well).

-- also I realize the cost to constantly maintain book diffs by the authors
is high, but just wanted to ask incase there were plans for it.

-R

On Fri, Feb 5, 2010 at 5:09 AM, Martijn Dashorst <martijn.dashorst@gmail.com
> wrote:

> On Fri, Feb 5, 2010 at 10:16 AM, Wilhelmsen Tor Iver <To...@arrive.no>
> wrote:
> >>   super(new CompoundPropertyModel(this));
> >
> > This seems wrong: A call to super() cannot reference "this" directly or
> indirectly:
> >
> > JLS §8.8.7 says:
> > "It is a compile-time error for a constructor to directly or indirectly
> invoke itself through a series of one or more explicit constructor
> invocations involving this."
>
> Yup, this is a bug in the book's example code. Has nothing to do with
> 1.3 or 1.4.
>
> And yes, the book is still valid apart from the model changes. My
> guess is that 1.5 will invalidate a bit more, but not too much. Mostly
> the part about page mounting and nice URLs will change. The internal
> request processing implementation is completely rewritten, but that
> should be transparent to the most of us (and was not covered in the
> book). The same goes for Wicket Ajax: completely rewritten,
> transparent for most users.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by Martijn Dashorst <ma...@gmail.com>.
On Fri, Feb 5, 2010 at 10:16 AM, Wilhelmsen Tor Iver <To...@arrive.no> wrote:
>>   super(new CompoundPropertyModel(this));
>
> This seems wrong: A call to super() cannot reference "this" directly or indirectly:
>
> JLS §8.8.7 says:
> "It is a compile-time error for a constructor to directly or indirectly invoke itself through a series of one or more explicit constructor invocations involving this."

Yup, this is a bug in the book's example code. Has nothing to do with
1.3 or 1.4.

And yes, the book is still valid apart from the model changes. My
guess is that 1.5 will invalidate a bit more, but not too much. Mostly
the part about page mounting and nice URLs will change. The internal
request processing implementation is completely rewritten, but that
should be transparent to the most of us (and was not covered in the
book). The same goes for Wicket Ajax: completely rewritten,
transparent for most users.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


SV: Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by Wilhelmsen Tor Iver <To...@arrive.no>.
>   super(new CompoundPropertyModel(this));

This seems wrong: A call to super() cannot reference "this" directly or indirectly:

JLS §8.8.7 says:
"It is a compile-time error for a constructor to directly or indirectly invoke itself through a series of one or more explicit constructor invocations involving this."

- Tor Iver

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by Andrew Lombardi <an...@mysticcoders.com>.
WiA covers 1.3, there's a wiki page that covers the differences here: http://cwiki.apache.org/WICKET/migrating-to-wicket-14.html

95% of WiA is going to work just fine though, aside from the changes mentioned in the migration link above

On Feb 4, 2010, at 7:51 PM, David Chang wrote:

> Hello, I am learning Wicket by reading <<Wicket in Action>>. I am using Wicket 1.4.5 and Java 6. 
> 
> On page 244, the sample code is as follows:
> 
> private int counter = 0;
> public MyPage() {
>  super(new CompoundPropertyModel(this));
>  final Label counterLabel = new Label("counter");
>  add(counterLabel);
>  counterLabel.setOutputMarkupId(true);
>  add(new AjaxLink("counterLabelLink")
>    @Override
>    public void onClick(AjaxRequestTarget target) {
>    counter++;
> target.addComponent(counterLabel);
> }
> });
> }
> 
> The line has super(new CompoundPropertyModel(this)); gives a compiler error. I replaced it with the following:
> 
> super();
> setDefaultModel(new CompoundPropertyModel(this));
> 
> and it works. 
> 
> My question is: 
> 
> 1. Am I doing the right thing?
> 2. Any better or more elegant way?
> 3. How much of WIA remains true as far as Wicket 1.4.5 concerned?
> 
> Thanks!
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 


To our success!

Mystic Coders, LLC | Code Magic | www.mysticcoders.com

ANDREW LOMBARDI | andrew@mysticcoders.com
2321 E 4th St. Ste C-128, Santa Ana CA 92705
ofc: 714-816-4488
fax: 714-782-6024
cell: 714-697-8046
linked-in: http://www.linkedin.com/in/andrewlombardi
twitter: http://www.twitter.com/kinabalu

Eco-Tip: Printing e-mails is usually a waste.

========================================================
This message is for the named person's use only. You must not, directly or indirectly, use,
 disclose, distribute, print, or copy any part of this message if you are not the intended recipient.
========================================================


Fix super(new CompoundPropertyModel(this)) error in the WIA book

Posted by David Chang <da...@yahoo.com>.
Hello, I am learning Wicket by reading <<Wicket in Action>>. I am using Wicket 1.4.5 and Java 6. 

On page 244, the sample code is as follows:

private int counter = 0;
public MyPage() {
  super(new CompoundPropertyModel(this));
  final Label counterLabel = new Label("counter");
  add(counterLabel);
  counterLabel.setOutputMarkupId(true);
  add(new AjaxLink("counterLabelLink")
    @Override
    public void onClick(AjaxRequestTarget target) {
    counter++;
target.addComponent(counterLabel);
}
});
}

The line has super(new CompoundPropertyModel(this)); gives a compiler error. I replaced it with the following:

super();
setDefaultModel(new CompoundPropertyModel(this));

and it works. 

My question is: 

1. Am I doing the right thing?
2. Any better or more elegant way?
3. How much of WIA remains true as far as Wicket 1.4.5 concerned?

Thanks!






      

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Where is the full client filename during FileUpload?

Posted by nytrus <ny...@gmail.com>.
Yes you are right, file full path file is never send. In fact exploring DOM
I've found no property to fetch it. Thank you! So I use a simple TextField.

@kinabalu
getClinetFilename() does not return the full path, while temp file path is
the path on the server where the file is phisically copied, while I was
lookin for the original path of the file on the clinet filesystem.

Thank you all!



ananthakumaran wrote:
> 
> Technically you cann't get the full path of the file using javascript. you
> are allowed the access the relative name of the file
> only.it is also read only (security reason). otherwise you could upload a
> file without the knowledge of the user.
> 
> see http://www.cs.tut.fi/~jkorpela/forms/file.html for reference
> 
> 2010/2/3 Nicola Tucci <ny...@gmail.com>
> 
>> Hi all,
>> I'm using a FIleUpload form component in order to save the full client
>> filename (path + filename, i.e.
>> /home/jdoe/myfiles/MyUploadableDocument.pdf), but for what I can see, I
>> can
>> retrieve only the filename using FileItem.getName().
>> I've tried to deeply debug wicket code to find the full path, but I only
>> find client filename, server temp name, content-type, size.
>>
>> Someone on this forum states that browsers often send only the filename,
>> not
>> the full path (security reason??), but how can servers bind the source
>> file
>> without the full name? It must be somewhere, maybe in the servlet
>> request...
>>
>> Besides, there is a smarter way to retrieve the full name (the one that
>> appears in the input component!) without perform the upload? My use case
>> oblige me to use FileUpload form component because the user use browser's
>> popup search dialog.
>>
>> Thanks to all,
>> BYE!
>>
> 
> 
> 
> -- 
> ----
> Anantha Kumaran
> 
> 

-- 
View this message in context: http://old.nabble.com/Where-is-the-full-client-filename-during-FileUpload--tp27439835p27456734.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Where is the full client filename during FileUpload?

Posted by Anantha Kumaran <an...@gmail.com>.
Technically you cann't get the full path of the file using javascript. you
are allowed the access the relative name of the file
only.it is also read only (security reason). otherwise you could upload a
file without the knowledge of the user.

see http://www.cs.tut.fi/~jkorpela/forms/file.html for reference

2010/2/3 Nicola Tucci <ny...@gmail.com>

> Hi all,
> I'm using a FIleUpload form component in order to save the full client
> filename (path + filename, i.e.
> /home/jdoe/myfiles/MyUploadableDocument.pdf), but for what I can see, I can
> retrieve only the filename using FileItem.getName().
> I've tried to deeply debug wicket code to find the full path, but I only
> find client filename, server temp name, content-type, size.
>
> Someone on this forum states that browsers often send only the filename,
> not
> the full path (security reason??), but how can servers bind the source file
> without the full name? It must be somewhere, maybe in the servlet
> request...
>
> Besides, there is a smarter way to retrieve the full name (the one that
> appears in the input component!) without perform the upload? My use case
> oblige me to use FileUpload form component because the user use browser's
> popup search dialog.
>
> Thanks to all,
> BYE!
>



-- 
----
Anantha Kumaran