On 20.Jul.2001 -- 04:47 PM, Torsten Curdt wrote:
> > > 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.
> > 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.
> > 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.
> > > > > * 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.
> > 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.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
