cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [Announcement] XMLForm 0.81 available in Scratchpad
Date Tue, 07 May 2002 02:57:53 GMT

bug submitted.

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

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


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

What do you mean by "opposite conversion"?

>
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message