commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8848] New: - Handling setValue for Collections and arrays
Date Tue, 07 May 2002 02:56:03 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8848>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8848

Handling setValue for Collections and arrays 

           Summary: Handling setValue for Collections and arrays
           Product: Commons
           Version: 1.0 Beta 1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: JXPath
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: ivelin@iname.com


As requested, I'm logging the recent email on this topic:

Looks like I'll need to add conversion from arbitrary arrays to collection
types.  For consistency I will implement the opposite conversion as well.

BTW, could you record this requirement as well as all other issues you
discover in JXPath in Bugzilla?  I already have quite a sizable list of bug
reports from various people and want track them.

Thanks,

- Dmitri

----- Original Message -----
From: "Ivelin Ivanov" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
Cc: "Dmitri Plotnikov" <dmitri@apache.org>
Sent: Monday, May 06, 2002 9:46 PM
Subject: Re: [Announcement] XMLForm 0.81 available in Scratchpad


>
> Michael,
>
> Good work.
>
> Do you have CVS access. If not, just submit the patches to the list, or
> directly to me and will apply them.
> If you don't use the CVS patch options, don't worry, just send me a zipped
> bundle with the java files.
>
> see below... ( I hope Dmitri can provide some feedback as well )
>
> ----- Original Message -----
> From: <mratliff@collegenet.com>
> To: <cocoon-dev@xml.apache.org>
> Sent: Monday, May 06, 2002 6:09 PM
> Subject: Re: [Announcement] XMLForm 0.81 available in Scratchpad
>
>
> >
> > Ivelin,
> >
> > <disclaimer>
> >       I'm new to java, so there are probably better ways to do this.
> >       I'm not using CVS (yet!) so I can't supply a simple diff file.
> > </disclaimer>
> >
> > SUMMARY:
> > *******************************************************
> > 1) Added accessor methods for a Collection (ArrayList) variable to the
> data
> > model.  Is there a better choice?
> > 2) Filled in the stubs for handling <xf:selectMany> already in
> > XMLFormTransformer.java.  This created the <xf:selectMany> tag, but it
had
> only
> > one <xf:value> child.
> > 3) Changed StartTransformingElement function to detect an instance of
> Collection
> > in the value_ returned from form.getValue() and iterated through the
> Collection
> > to create the necessary multiple <xf:value> tags.
>
> Cool. That's what I was thinking to do as well.
>
> > 4) Added a template to xmlform2html .xsl to process the xf:selectMany
tag
> and
> > generate either a checkbox set or multiple-select list (based on
> <xf:selectMany
> > @hint="checkbox">).  Now I had the output I was looking for, but when I
> tried to
> > submit the form I kept getting errors from jxpath.
>
> Can you send me the stack traces.
> BTW, the most recent version of JXPath should be able to correctly handle
> setValue( Collection or String[] ).
> Dmitri added this after we discussed its potential for request parameters
> with multiple values.
>
> > 5) Changed the convert function in Types.java to recognize String arrays
> coming
> > from the request (it seems to convert only String scalars) and to
convert
> them
> > to ArrayList type.
>
> Interesting. There already was code in Form to handle request parameters
> with multiple values.
> Apparantly badly implemented:
> Can you point me to the problem ?
>
>
>   public void setValue(String path, Object[] values)
>   {
>     Pointer pointer = jxcontext_.locateValue( path );
>     Object property = pointer.getValue();
>     if ( property == null )
>     {
>       throw new RuntimeException( "Property for " + path + " is nul.
Cannot
> determine type." );
>     }
>     // if the property is a collection, set value as array
>     if ( property instanceof Collection || property.getClass ().isArray
() )
>     {
>       Object newValue = convertType( values, property.getClass () );
>       pointer.setValue( newValue );
>     }
>     // otherwise set the value of the first element
>     // (there shouldn't be other)
>     // in the values array
>     else setValue( pointer, values[0] );
>   }
>
>
>
> > 6) Extended WizardAction (for other reasons), and modified the reset
> function to
> > set data model to empty ArrayList before population.
> >
> > There are (at least) several fishy things here: 1) Don't know what
happens
> when
> > DOM nodes are used for multiple-select.  (Don't really understand the
> > purpose/use of DOM nodes in data model for that matter)
>
> I guess preparing of the DOM node can either happen in the reset() method,
> when request
> scope is used for the form. Otherwise, with session scope, no special
> handling needs to take place.
> Although I have not tested this.
> I have not personally used DOM for any of the web apps I've worked on, but
> Torsten and other folks do it quite a bit. You can look at the recent form
> discussions in the list.
>
> 2) Types stuff is just
> > a working hack.  No provision for converting anything but an ArrayList,
> and not
> > sure if I'm even doing this the right way.
>
> I've also added a couple hacks to the Types class, some of which made it
in
> the JXPath core.
> Yours might too, if we can't find a better solution.
>
> > 3) I very much prefer your idea of
> > using "selectUIType" attribute instead of "hint" attribute.  I'll work
on
> these
> > things when I get time.
>
> This was an excerpt from the XForms spec.
>
> >
> > Also, I'm struggling a bit with the best way to handle "presentation" of
> > multiple-select lists rendered as checkbox set.  All other form widgets,
> item
> > captions render only one way (e.g. options in select list).  But with
> checkbox
> > sets, item captions may be rendered to right of checkbox, to left of
> checkbox,
> > above checkbox, below checkbox, etc.  For now, my template just places
> them to
> > right of checkbox, but this needs to be more flexible.
>
> Konstantin can probably help here.
> As long as there is a way to extend and override the default rendering of
> multi select checkboxes,
> then your implementation should be cool. Is it an isolated template with a
> name like ("selectManyCheckbox" or similar).
>
> >
> > DETAILS:
> > *******************************************************
> >
> > 1) In XMLFormTransformer.java
> > Filled in stub for selectMany tag in  StartTransformingElement():
> >       else if (TAG_SELECTMANY.equals(name))
> >             {
> >             //NYI - Not Yet Implemented
> >                   //throw new SAXException("tag selectMany Not Yet
> > Implemented");
> >              startElementSimpleField( uri, name, raw, attributes,
> currentForm );
> >             }
>
> Looks good.
>
> >
> > and EndTransformingElement():
> >       else if (TAG_SELECTMANY.equals(name))
> >             {
> >                   super.endElement(uri, name, raw);
> >             }
>
> Looks good.
>
> >
> > and inserted code for handling Collections:
> >
> >       // render the value subelement(s)
> >       if (value_ instanceof Collection)
> >       {
> >             Iterator i=((Collection) value_).iterator();
> >             while (i.hasNext())
> >             {
> >                   super.startElement(uri, "value", NS_PREFIX + ":" +
> "value",
> > NOATTR);
> >                     if (value_ != null)
> >                     {
> >                         String v = String.valueOf( i.next() );
> >                         super.characters(v.toCharArray(),0,v.length());
> >                     }
> >                     super.endElement( uri, "value", NS_PREFIX + ":" +
> "value" );
> >             }
> >       }
> >       else
> >       {
> >               super.startElement(uri, "value", NS_PREFIX + ":" +
"value",
> > NOATTR);
> >               if (value_ != null)
> >               {
> >                   String v = String.valueOf( value_ );
> >                   super.characters(v.toCharArray(),0,v.length());
> >               }
> >               super.endElement( uri, "value", NS_PREFIX + ":" +
"value" );
> >         }
>
> Looks good.
>
>
> >
> > 2) In Types.java the convert function has a block of code for converting
> request
> > parameter Strings to various Object types, but no similar block for
> request
> > parameter String[].  Maybe they are supposed to "drop through" and be
> processed
> > below, don't entirely understand this.  Anyway this caused all sorts of
> jxpath
> > errors when I tried to use form.setValue(path, values), so I used "brute
> force"
> > and hacked in the following:
> >             else if (object instanceof String[]){
> >                   /* WARNING: THIS IS A REAL HACK!
> >                    * Inserted to handle conversion of string array from
> request
> > into ArrayList.
> >                    * Should write "converters" from String[] to other
> types of
> > Java objects
> >                    * Not sure this belongs here at all, should look at
> > hasConversionConstructor
> >                    * stuff below, but this works for now...
> >                    */
> >                   if (toType == ArrayList.class){
>
> If you can extend this implementation to be able to handle Collections or
> array of primitives,
> it deserves to be part of the core JXPath code. I would encourage you to
> look at the most recent
> JXPath source, because from Dmitri's description, I believe this is
already
> there.
>
>
> >                         String[] tempString = (String[]) object;
> >                         ArrayList newArrayList = new ArrayList();
> >                         for (int n=0;n<tempString.length;n++){
> >                               newArrayList.add(tempString[n]);
> >                         }
> >                         return newArrayList;
> >                   }
> >             }
>
>
> Excelent.
>
> Keep the good stuff coming.
>
>
> Ivelin
>
> >
> > Cheers,
> > --Michael
> >
> >
> >
> >
> >
> >                       "Ivelin Ivanov"
> >                       <ivelin@apache.or        To:
> <cocoon-dev@xml.apache.org>
> >                       g>                       cc:
> >                                                Subject:  Re:
> [Announcement] XMLForm 0.81 available in
> >                       05/06/02 06:33 AM         Scratchpad
> >                       Please respond to
> >                       cocoon-dev
> >
> >
> >
> >
> >
> >
> > Sure feel free to patch.
> >
> > Actually, thanks for patching ;)
> >
> > I'd be curious to see the diff.
> >
> > Can you descripe in short what behaviour you added to implement
selectMany
> ?
> >
> > Ivelin
> >
> > ----- Original Message -----
> > From: <mratliff@collegenet.com>
> > To: <cocoon-dev@xml.apache.org>
> > Sent: Saturday, May 04, 2002 11:43 PM
> > Subject: Re: [Announcement] XMLForm 0.81 available in Scratchpad
> >
> >
> > > Ivelin,
> > >
> > > I found the places in XMLFormTransformer.java that needed filling in
and
> > hacked
> > > a patch into Types.java.  I now have xf:selectMany working well enough
> for
> > > testing purposes.  Let me know if you have any general advice about
> > patching
> > > these files...
> > >
> > > Thanks,
> > > --Michael
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message