> > 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)
> > > > When a subpage is chosen to be viewed an intance of
> > > > an DOMObject referring to the xform id needs to be
> > > > looked up. If there is none, one needs to be created
> > > > and registered. (Just like the Components in the ComponentManager)
> > > > Creation means also passing the SAX events from the
> > > > xform:instance data to the DOMObject. Now the DOMObject
> > > > holds the expected XForm structure.
> > >
> > > I don't quite get what you're at. If this object contains the instance
> > > data -- which is likely to be different for every invocation as partly
> > > filled in forms return -- why should an instance get looked up?
> >
> > I want to save the DOMObject instances inside the session.
> > Simplified:
> >
> > xform = (DOMObject)session.get("formid");
> > if(xform == null){
> > xform = new DOMObject();
> > xform.setLexicalHandler(lexicalhandler);
> > xform.setContentHandler(contenthandler);
> > }
>
> OK.
>
> > Some kind of manager would be probably better?!
>
> No idea.
We'll see...
> > > If that's the caching concern again, I strongly believe that that is a
> > > different concern and should be handled otherwise. E.g. if it's a XSP
> > > that generates the form, it's up to cocoon to cache this request and
> > > deliver a cached copy.
> >
> > Now I'm wondering where you are up to... ;)
>
> Caching should be done locally only if we know a lot better how to do
> it than cocoon. Otherwise we should rely on cocoon to do the caching.
Yepp!
> > > > * Selection of the subpage based on the validation results
> > >
> > > See other reply.
> >
> > Could you please outline how you would want to do this?
> > I don't really see the problem about this one.
>
> I think we agree that this is independant of forms. I would suggest an
> action that knows how many subpages exists (through a session
> attribute or a parameter?). So the sitemap would read like
>
> if validation == OK
> if 0 < requestedPage < lastPage
> showPage ( requestedPage )
> else
> showPage ( currentPage )
> fi
> else
> showPage(currentPage)
> fi
>
> Where showPage(subpage) is a call to generate.
Well, yeah..
> BTW something similar could be achieved with the
> FilterTransformer. Output all subpages and the FilterTransformer
> filters all but the current one from the output.
Hm.. I haven't found this little treasure yet ;)
> > > > Then I would propose a XFormTransformer that will
> > > > extract the selected subpage fragment and add the
> > > > value to the xform elements. Here is an example of
> > > > what should come out of the transformer:
> > >
> > > What would that be exactly? Fill in the blanks in a form with values
> > > from the instance data, like the SQLTransformer?
> >
> > yes
>
> I hope a stylesheet would do, but I don't know for sure. Of course if
> you intent to do calculations and look up you'd need your own
> transformer. But that I fear would be quite application specific. Or
> at least I wouldn't see it at the core of a forms package.
>
> 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 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.
> > > With XSP as well.
> > > > * taglib would mean to but multiple (sub)pages into
> > > > one XSP page - I'm always afraid of the 64k limitation
> > > > of XSP pages
> > >
> > > AFAIK this limitation is a per method limit. So putting each sub page
> > > in a different method would circumvent it.
> >
> > Hm.. got me. I must admit I feel just more flexible and
> > safer not to run into compile time / run time problems.
> > Why would you want to go for a logicsheet?
>
> I think it's the most flexible way to do. But I'm not religious on
> that.
Me neither :)
> > > Again this is not compliant. But it is a problem to conform to it
> > > here. What about different error conditions? Currently
> > > FormValidatorAction offers a number of constraints that each may be
> > > invalid. XForms specs only one arbitrary complex constraint returning
> > > a boolean.
> >
> > What's the compliant method? I must have missed it in the spec.
>
> 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)
> > > > * DBMS comboboxes
>
> > > I still think it's not a form issue. If you're not happy with your
> > > DBMS caching the data, well, create an alternative way to contact the
> > > DBMS and do the caching in that component like the descriptor caching
> > > is done. After all, this might come in handy with other issues as
> > > well.
> >
> > But still there is the output problem then!
>
> What output problem? Is this again, that I think XSP and you think
> transformer? It would be no very nice to have to employ a dozen
> specialized transformers... but then cocoon2 is all about putting
> pieces together. That's what I like so much about it. Like shell
> programming in UNIX ;-)
No it's not - I meant the problem dicussed in the following paragraph...
> > > > * 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.
> > > > * subpage navigation
>
> > > Name the submit button as you like.
> >
> > No. There is a difference! Submitting
> > a subpage is different from submitting
> > the xform!! Submitting the xform means
> > "placing the order" while submitting
> > a subpage is a navigation inside the
> > xform.
>
> 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...
> > What about putting the whole multipage
> > navigation thing into it's own namespace?
> > Like:
>
> > So we would have both topics separated.
>
> Agreed.
Ok
> > But we need a way to report the result
> > of the form submission (success/failed)
> > to the sitemap. Also a failed submit
> > need to show the last page again.
>
> Sure. We'll see.
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
