On 19.Jul.2001 -- 07:33 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.
> > > 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.
> > 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.
> > > * 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.
BTW something similar could be achieved with the
FilterTransformer. Output all subpages and the FilterTransformer
filters all but the current one from the output.
> > > 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.
> > 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.
> > 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 :-(
> > > * 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 ;-)
> > > * 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?
> > > * 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.
> What about putting the whole multipage
> navigation thing into it's own namespace?
> Like:
> So we would have both topics separated.
Agreed.
> 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.
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]
