You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/07/03 13:59:34 UTC
Re: [cforms] Editing existing list of uploads
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.
Re: [cforms] Editing existing list of uploads
Posted by Sylvain Wallez <sy...@apache.org>.
Bruno Dumon wrote:
>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.
>
>
Do we really need a new abstraction, that furthermore depends on Part
which it tries to hide? We could simply add isNew() to Part, and create
some additional implementations, e.g. SourcePart whose isNew() would
return false by default.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.07.2004 12:58, Bruno Dumon wrote:
> 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.
Yes, that's a bit strange, but for the moment it works. I have committed
it that way.
> 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.
Good idea.
Joerg
Re: [cforms] Editing existing list of uploads
Posted by Bruno Dumon <br...@outerthought.org>.
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
Re: [cforms] Editing existing list of uploads
Posted by Sylvain Wallez <sy...@apache.org>.
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.07.2004 16:22, g[R]eK wrote:
> JH> This thread on users list was about implementing the setValue() method
> JH> on the upload widget. The use case is - as the subject says - editing
> JH> existing list of uploads. The complete thread can be found at
> JH> http://thread.gmane.org/gmane.text.xml.cocoon.user/38910. What has been
> JH> the reason for not implementing the method besides a missing use case?
> JH> No security reason came to my mind. What about implementing it the most
> JH> simple way:
>
> JH> public void setValue(Object object) {
> JH> if (!(object instanceof Part)) {
> JH> throw new RuntimeException("not a part");
> JH> }
> JH> this.part = (Part) object;
> JH> }
>
> Big thanks for this! I was little confused why setValue is not implemented.
> When it'll be on cvs?
I only asked for reactions on the dev list at the moment. Will see what
happens ...
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re[2]: [cforms] Editing existing list of uploads
Posted by "g[R]eK" <gR...@warsztat.pac.pl>.
<. Hi Joerg! .>
Saturday, July 3, 2004, 1:59:34 PM, you wrote:
JH> This thread on users list was about implementing the setValue() method
JH> on the upload widget. The use case is - as the subject says - editing
JH> existing list of uploads. The complete thread can be found at
JH> http://thread.gmane.org/gmane.text.xml.cocoon.user/38910. What has been
JH> the reason for not implementing the method besides a missing use case?
JH> No security reason came to my mind. What about implementing it the most
JH> simple way:
JH> public void setValue(Object object) {
JH> if (!(object instanceof Part)) {
JH> throw new RuntimeException("not a part");
JH> }
JH> this.part = (Part) object;
JH> }
Big thanks for this! I was little confused why setValue is not implemented.
When it'll be on cvs?
--
Best regards
<. g[R]eK mailto:gReK@warsztat.pac.pl .>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org