You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2002/05/07 04:56:03 UTC
DO NOT REPLY [Bug 8848] New: -
Handling setValue for Collections and arrays
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" <iv...@apache.org>
To: <co...@xml.apache.org>
Cc: "Dmitri Plotnikov" <dm...@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: <mr...@collegenet.com>
> To: <co...@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:
> <co...@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: <mr...@collegenet.com>
> > To: <co...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>