You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "g[R]eK" <gR...@warsztat.pac.pl> on 2004/06/30 16:04:28 UTC
[cforms] Editing existing list of uploads
<. Hi users! .>
Quick description:
In db there are some records that include file (blob) and some info about it.
I want to build form that will make possible editing info about each file, and
if it's needed upload new binary data and of course adding/deleting records.
It's good job for form with repeater, but there is a problem: upload widget
doesn't have setValue.
Question is:
Why upload widget doesn't have setValue method, and if it's justified how can
I solve my problem?
--
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
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
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
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 Joerg Heinicke <jo...@gmx.de>.
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: 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! .>
Friday, July 2, 2004, 11:55:50 AM, you wrote:
JH> On 02.07.2004 02:52, 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.
--
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
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.07.2004 02:52, g[R]eK wrote:
> I think clear example will explain everythink:
> we have repater like
>
> <fd:repeater id="uploads">
> <fd:widgets>
> <fd:field id="name" required="true"/>
> <fd:field id="description" required="true"/>
> <fd:upload id="file" mime-types="text/plain" required="true"/>
> </fd:widgets>
> </fd:repeater>
>
> For the first time it will work perfectly, when user hit submit, some binding
> will collect data from form and store it in db.
> Let's see what is going on when we want to edit stored data.
> At the begining binding is carryed out. First problem: we can't bind BLOB ->
> upload widget, but as you said it makes no sense, so let's go ahead.
> We have some rows filled in with data in the repeater, each row has upload
> empty upload widget that suggesting to a user that he has to upload some data.
> If he was smart, he did what he want and hit submit button. Then we have some
> mess, upload widget is required so it will raise validating errors.
Ah, the @required is the problem. The form does not know that there was
already uploaded a file and so the user is forced to upload one.
> Another try...
> Editing form is different from adding form. It has two repaters:
>
> <fd:repeater id="existing_uploads">
> <fd:label>Existing uploads</fd:label>
> <fd:widgets>
> <fd:field id="name" required="true"/>
> <fd:field id="description" required="true"/>
> </fd:widgets>
> </fd:repeater>
> <fd:repeater id="uploads">
> <fd:label>Uploads</fd:label>
> <fd:widgets>
> <fd:field id="name" required="true"/>
> <fd:field id="description" required="true"/>
> <fd:upload id="file" mime-types="text/plain" required="true"/>
> </fd:widgets>
> </fd:repeater>
>
> The second one is for adding new files, the first one is for deleting existing,
> but how upload new data to existing file? :-)
Yeah, that's really nasty. Even using two repeaters is not that nice. It
might work when doing it the same way the stylesheet does it: offering a
button if something has been uploaded. The union widget might help here.
Let it depend on a case widget, where the status "upload exists" or not
is set. You show either a button or an upload widget. The button
switches the status.
setValue() might help but you would need to provide a
org.apache.cocoon.servlet.multipart.Part to it.
> 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).
Don't understand.
> What a mess, isn't it? :-)
Yes. But the above is at least a valid use case for Upload.setValue().
It might be interesting to know why it was not allowed, maybe I'm
missing some security reasons at the moment.
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! .>
Friday, July 2, 2004, 12:09:22 AM, you wrote:
>> I mean state of all widgets (including uploads).
JH> But as I said IMO for uploads this makes no sense.
>> It's quite simple because form
>> behaves almost it's used for the first time for uploading. Upload widgets show
>> files upload, there is button (looks like [..]) that enables user to do new
>> upload. When user hit submit, all I have to do is just map widgets from repater
>> to database (including data from upload widget).
>> But lack of setValue method breaks down my dream :-(
JH> Hmm, okay, ayou can raise this issue of course on the developers list
JH> (or tomorrow in IRC, it's First Friday, and many people will be there).
JH> Maybe other people think of it as an useful addition too.
I think clear example will explain everythink:
we have repater like
<fd:repeater id="uploads">
<fd:label>Uploads</fd:label>
<fd:widgets>
<fd:field id="name" required="true">
<fd:label>File name</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="description" required="true">
<fd:label>Description</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:upload id="file" mime-types="text/plain" required="true">
<fd:label>File</fd:label>
</fd:upload>
</fd:widgets>
</fd:repeater>
For the first time it will work perfectly, when user hit submit, some binding
will collect data from form and store it in db.
Let's see what is going on when we want to edit stored data.
At the begining binding is carryed out. First problem: we can't bind BLOB ->
upload widget, but as you said it makes no sense, so let's go ahead.
We have some rows filled in with data in the repeater, each row has upload
empty upload widget that suggesting to a user that he has to upload some data.
If he was smart, he did what he want and hit submit button. Then we have some
mess, upload widget is required so it will raise validating errors.
Another try...
Editing form is different from adding form. It has two repaters:
<fd:repeater id="existing_uploads">
<fd:label>Existing uploads</fd:label>
<fd:widgets>
<fd:field id="name" required="true">
<fd:label>File name</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="description" required="true">
<fd:label>Description</fd:label>
<fd:datatype base="string"/>
</fd:field>
</fd:widgets>
</fd:repeater>
<fd:repeater id="uploads">
<fd:label>Uploads</fd:label>
<fd:widgets>
<fd:field id="name" required="true">
<fd:label>File name</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:field id="description" required="true">
<fd:label>Description</fd:label>
<fd:datatype base="string"/>
</fd:field>
<fd:upload id="file" mime-types="text/plain" required="true">
<fd:label>File</fd:label>
</fd:upload>
</fd:widgets>
</fd:repeater>
The second one is for adding new files, the first one is for deleting existing,
but how upload new data to existing file? :-)
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).
What a mess, isn't it? :-)
--
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
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.07.2004 09:05, g[R]eK wrote:
>>> Question is:
>>> Why upload widget doesn't have setValue method, and if it's justified how can
>>> I solve my problem?
>
> JH> What for do you need setValue()? IMO it makes no sense, where do you
> JH> want to know from server side at what place the file is stored client
> JH> side? But maybe I'm missing only a piece.
>
> The best solution would be load state of form that was before user submited it.
Of course.
> I mean state of all widgets (including uploads).
But as I said IMO for uploads this makes no sense.
> It's quite simple because form
> behaves almost it's used for the first time for uploading. Upload widgets show
> files upload, there is button (looks like [..]) that enables user to do new
> upload. When user hit submit, all I have to do is just map widgets from repater
> to database (including data from upload widget).
> But lack of setValue method breaks down my dream :-(
Hmm, okay, ayou can raise this issue of course on the developers list
(or tomorrow in IRC, it's First Friday, and many people will be there).
Maybe other people think of it as an useful addition too.
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! .>
Thursday, July 1, 2004, 12:17:16 AM, you wrote:
>> Question is:
>> Why upload widget doesn't have setValue method, and if it's justified how can
>> I solve my problem?
JH> What for do you need setValue()? IMO it makes no sense, where do you
JH> want to know from server side at what place the file is stored client
JH> side? But maybe I'm missing only a piece.
The best solution would be load state of form that was before user submited it.
I mean state of all widgets (including uploads). It's quite simple because form
behaves almost it's used for the first time for uploading. Upload widgets show
files upload, there is button (looks like [..]) that enables user to do new
upload. When user hit submit, all I have to do is just map widgets from repater
to database (including data from upload widget).
But lack of setValue method breaks down my dream :-(
--
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
Re: [cforms] Editing existing list of uploads
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.06.2004 16:04, g[R]eK wrote:
> <. Hi users! .>
>
> Quick description:
> In db there are some records that include file (blob) and some info about it.
> I want to build form that will make possible editing info about each file, and
> if it's needed upload new binary data and of course adding/deleting records.
> It's good job for form with repeater, but there is a problem: upload widget
> doesn't have setValue.
Yes, repeater is the way to go.
> Question is:
> Why upload widget doesn't have setValue method, and if it's justified how can
> I solve my problem?
What for do you need setValue()? IMO it makes no sense, where do you
want to know from server side at what place the file is stored client
side? But maybe I'm missing only a piece.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org