This thread on users list was about implementing the setValue() method
on the upload widget. The use case is - as the subject says - editing
existing list of uploads. The complete thread can be found at
http://thread.gmane.org/gmane.text.xml.cocoon.user/38910. What has been
the reason for not implementing the method besides a missing use case?
No security reason came to my mind. What about implementing it the most
simple way:
public void setValue(Object object) {
if (!(object instanceof Part)) {
throw new RuntimeException("not a part");
}
this.part = (Part) object;
}
Joerg
On 02.07.2004 12:56, g[R]eK wrote:
JH> Ah, the @required is the problem. The form does not know that there was
JH> already uploaded a file and so the user is forced to upload one.
Yes, and form layout is not adapted to handling uploads stored somewhere else.
JH> Yeah, that's really nasty. Even using two repeaters is not that nice. It
JH> might work when doing it the same way the stylesheet does it: offering a
JH> button if something has been uploaded. The union widget might help here.
JH> Let it depend on a case widget, where the status "upload exists" or not
JH> is set. You show either a button or an upload widget. The button
JH> switches the status.
I don't know union widget very well, and I think it's overload solving such
common issue using "big cannon" as union.
JH> setValue() might help but you would need to provide a
JH> org.apache.cocoon.servlet.multipart.Part to it.
DB interface is providing java.sql.Blob, then it's providing InputStream and we
can create org.apache.cocoon.servlet.multipart.PartInMemory using this
InputStream. Quite easy.
Ohh, and something else... If problem with upload somehow is solved, we will
have another with handling form submit. If we want do something more than
simple binding, and we want read files we have to read it from form (newly
uploaded) and from db (existing before).
JH> Don't understand.
I meant problem is solved without using setValue. Then we have for example two
files in db 'file1' and 'file2', using form 'file3' and 'file4' are added. We
want to do something with ALL files that should be in the form (but they don't,
we have only some info about 'file1' and 'file2' in the form). So instead of
simply reading what we need from form, we have to read newly uploaded files
('file3' and 'file4') from form, and 'file1', 'file2' from db! Let's add
removing operations, and we have chaos ;-)
What a mess, isn't it? :-)
JH> Yes. But the above is at least a valid use case for Upload.setValue().
JH> It might be interesting to know why it was not allowed, maybe I'm
JH> missing some security reasons at the moment.
I would be appreciated. IMHO setValue is only one good solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
