Uploaded image for project: 'Commons JXPath'
  1. Commons JXPath
  2. JXPATH-11

Handling setValue for Collections and arrays

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 1.0 Final
    • None
    • None
    • Operating System: All
      Platform: All

    • 8848

    Description

      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
      > >
      >
      >

      Attachments

        Activity

          People

            Unassigned Unassigned
            ivelin@iname.com Ivelin Ivanov
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: