Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Subject: Re: [cforms] Editing existing list of uploads
From: Bruno Dumon <bruno@outerthought.org>
To: dev@cocoon.apache.org
In-Reply-To: <40E71948.3030605@apache.org>
References: <114697375.20040630160428@warsztat.pac.pl>
	 <40E33BEC.3070205@gmx.de> <1639149921.20040701090506@warsztat.pac.pl>
	 <40E48B92.5050201@gmx.de> <1026779501.20040702025255@warsztat.pac.pl>
	 <40E53126.7060504@gmx.de> <1582916142.20040702125651@warsztat.pac.pl>
	 <40E69FA6.1010502@gmx.de>  <40E71948.3030605@apache.org>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1088938715.16543.19.camel@yum>
Mime-Version: 1.0
Date: Sun, 04 Jul 2004 12:58:35 +0200
Content-Transfer-Encoding: 7bit

On Sat, 2004-07-03 at 22:38, Sylvain Wallez wrote:
> Joerg Heinicke wrote:
> 
> > 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;
> > }
> 
> 
> That makes sense. This allows for example forms that edit some data with 
> binary attachements to display the existing attachments and newly added 
> ones in a uniform way.
> 
> However, as outlined in the discussion, the form binding will have to 
> take care of distinguishing new and existing attachments, and also 
> existing attachments that were deleted. But that's another problem.
> 
> Something I've been thinking about also is a way to make the uploaded 
> parts accessible from the browser. That would allow e.g. to display a 
> preview of uploaded images.
> 
> For low, let's add Upload.setValue() !
> 
> Sylvain

Something that doesn't sit entirely right for me is that one would
'artificially' create a Part. While technically possible, the definition
of a Part is that it is a file parsed from a http post.

How about introducing a new interface for the value of an upload widget,
lets say UploadData:

UploadData {
   /** Return true if it is newly uploaded data */
   boolean isNew();
   /** Returns the part if isNew returns true, otherwise null. */
   Part getPart();
   InputStream getInputStream();
   String getMimeType();
}

This would also allow to distinguish between new and unmodified uploads.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org