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: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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"
> <[EMAIL PROTECTED] To:
<[EMAIL PROTECTED]>
> 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: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
