Re: [CForm]two question/suggestion about multi-value field
Agree.In some system you can add input in an offline html to modified the value,it is a security problem. Roy Huang - Original Message - From: Bruno Dumon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 3:53 PM Subject: Re: [CForm]two question/suggestion about multi-value field On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote: Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CForm]two question/suggestion about multi-value field
Bruno Dumon wrote: On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote: Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput :-) Vadim
Re: [CForm]two question/suggestion about multi-value field
Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? Joerg
Re: [CForm]two question/suggestion about multi-value field
Joerg Heinicke wrote: Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? How would that work for wd:multivalue field? I guess it would then become wi:output with multiple nested wi:values. But what attribute / element are you suggesting? Vadim
Re: [CForm]two question/suggestion about multi-value field
On Wed, Mar 03, 2004 at 12:47:37PM +, Joerg Heinicke wrote: Vadim Gritsenko vadim at reverycodes.com writes: I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. Aha. Now this makes sense. +1 to multivalueoutput Instead of adding an additional output widget for every type of existing widgets would it not make more sense to add an attribute or additional element to the existing widgets similar to the binding's direction=load? Joerg +5 I never understood why we have an output widget which only serves as an output only version of the field widget, but did not have any support for output versions of the other widgets (repeaters, etc.) Lets fix this the right way like Joerg suggests and deprecate the separate, lonely, output widget. --Tim Larson
Re: [CForm]two question/suggestion about multi-value field
roy huang wrote: 1.In cocoon form multi-value field rendered as listbox or others,but if you want to enter in a text input,the value is single. Can/Should cocoon form provide multi-value field as text input,using separator like , or ; to separate the multi-value? My first reaction: No way! Using separator is totally user un-friendly, from my POV. But what actually should/could happen, is that you can render multiple input boxes. You could even specify count of such boxes using wi:styling 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? If you want to *render* it as text output, you should use wi:styling type=output. Vadim
Re: [CForm]two question/suggestion about multi-value field
On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. If you want to *render* it as text output, you should use wi:styling type=output. Vadim -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CForm]two question/suggestion about multi-value field
Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? Vadim
Re: [CForm]two question/suggestion about multi-value field
On Tue, 2004-03-02 at 22:03, Vadim Gritsenko wrote: Bruno Dumon wrote: On Tue, 2004-03-02 at 14:31, Vadim Gritsenko wrote: snip/ 2.Sometime we need to just display multi-value as text like wd:output,but I only found binding can only bind multivalue-field with multi-value(only in cvs now).Can/Should cocoon form provide multi-value binding to output widget? I think no. Why do you want to bind it to wd:output? I would think for the same reason one would otherwise wd:output instead of wd:field. In this case one would however need a wd:multivalueOutput widget. Yes, but why not type=output? because an output widget doesn't read its value from the request. With a normal (multivalue)field widget, the value can always be modified by adding the appropriate request parameters. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
