cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@dff.st>
Subject RE: [RT] forms
Date Fri, 20 Jul 2001 16:02:57 GMT
> > > > 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message