> > > > What do you mean by "get back"? What I was thinking of was:
> > >
> > > I was refering to the form in which the posted form parameters are
> > > represented for further processing. Currently, every form element
> > > corresponds to a request parameter. XForms require each entire form to
> > > correspond to one request parameter. If the suggested names for
> > > elements are used, they're like
> > > "formName/elementName/subElementName". From this one DOM object can be
> > > constructed to hold all parameters of a form, just like XForms
> > > expects. That would enable to delegate validation to xerces but is a
> > > bit more costly.
> >
> > You want to save more than just their values?? This would
> > make us cache the whole xform descriptor. Hm.. doesn't sound
> > desireable... (in this case)
>
> No, I think a DOM representation is sufficient, a textual
> representation would not be necessary. And if it were, the DOM
> representation can easily be transformed to a textual one.
You got me wrong. The question was what is supposed to be
inside the tree:
<order>
<firstname>Torsten</firstname>
...
The additional validation information or even the whole
descriptor?
> > > Your concern here is how to integrate with forms. Well, you could do
> > > <form>
> > > <instance>
> > > <name><replace-me with="my.bo.method"/></name>
> > > </instance>
> > > </form>
> > >
> > > And replace with a transformer.
> >
> > This would only give a mapping when instancing the
> > the DOMObject. BTW: Where would you create the instance
> > in the XSP page / Transformer or within the action?
>
> I'd prefer to do this on a XSP. The example above was meant as a way
> to do without XSP and with a transformer alone. So the acutal data
> would be provided by a bean or something. If the data was filled in by
> XSP logic, such a transformer would be pointless.
>
> > I wonder if for an action the descriptor needs to be
> > static (e.g. no esql) or is it also possible to grab
> > something from an internal pipeline via cocoon protocol?
> > This would also provide caching for the descriptor.
>
> Actions that inherit from AbstractComplimentaryConfigurableAction
> cache the descriptor. They do check if it has changed (this is
> configurable) and reload it if needed. I'm not enough into URLSource
> class to say whether an internal URL may provide the descriptor.
But I guess that would be the way to use it... we could make it
so. So the action does not even have to care about caching. Cool!
> > > That's the problem, there isn't one. XForms does not talk about error
> > > messages :-(
> >
> > So I guess when there is nothing about it in the spec we need to add
> > something by ourselfs! (We can't wait for spec to come along)
>
> Unfortunately. This one goes hand in hand with our validation
> model. If we want XForms validation, there's not much point in error
> messages. If we stick with current validation, we'd need to use the
> <on-error/> tags from current validation taglib.
Sorry, but I don't even like to use this one. Let's say
I have 20 form elemtens on a page an on-error "event" model
is a full overkill. There will be more possible and redundant
error messages in the form than anything else! I think using
error codes and then translate them dictionary is the way to go.
> > > > > > * output definition
> > > > > > I think what is not quite clear (at least for me)
> > > > > > from the XForms spec is what "output" means
> > > > > > on selections aka choices. Is it the value
> > > > > > or the text? Both is needed! So how do you specify
> > > > >
> > > > > I think as with HTML it's the value. If you'd need the text, add that
> > > > > to the value as well.
> > > >
> > > > Arrrgh... NO! This becoming a real ugly hack then!!
> > > > (not talking about weak browser implementation that
> > > > might be swamped with long i18n text as values - just
> > > > a fear)
> > >
> > > I see. Shoping cart &c. List of purchased items, not nice to look up
> > > their description more than once. But there's not much we could do
> > > about it. If the HTML reads
> > > <option value="123456">Some really long description of item</option>
> > > The browser will return "123456" only. What could a forms package do
> > > to this?
> >
> > Well, it should do something about it! Or we are back at PHP
> > level. We have had the information and we throw it away
> > an execute a sql statement per field go get back what you
> > threw away half a second before!?
> > When creating a form these are the things I don't want
> > to care about anymore.
> > When you create complex forms this is what takes time -
> > not a simple single line textbox.
>
> OTOH you should *never* trust anything that originates from the
> client. So if there's a shopping list of item numbers and descriptions
> the customer might deselect, you'd better keep the data on the server
> and compare it with the returned data and find out yourself, which
> items are missing. That's what session attributes are for.
Of course the data needs to be kept by the server! But I don't want
to care about storing stuff like the value-text mapping of comboboxes
in the session. This is a too common need - it should happen automacically.
> > > Right. But if we think about this in terms of HTML it boils down to
> > > name the submit button a long the lines of "continue..." or "subpage 2
> > > caption". If the device were XForms compliant, we wouldn't have to
> > > deal with sub pages at all. Ah, that's probably a plus for a
> > > FilterTransformer based solution.
> >
> > Why not? All our designer want to decide what to show on
> > which page. XForm will not make this go away...
>
> No, but a XForms compliant device choses a presentation for subpages
> itself. This might be a "notebook" or a "stack" or it might even
> decide to show all pages at once, whatever suits the device best. The
> server can do nothing about it.
Well, I don't see this beeing adopted as long there are designers out
there ;)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
