cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [cforms] Editing existing list of uploads
Date Sat, 03 Jul 2004 11:59:34 GMT
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.

Mime
View raw message