Torsten,
I'm sorry that I haven't kept up to your speed. Anyway, I have had a
look at your first post and a short glimpse at this one. BTW you make
it easier for me if you would include any comments in your code
sel.xsl
This one looks almost finished and is what I had in mind with my
comment. We need to check if splitting output to several methods
breaks other taglibs i.e. esql. I'm not sure about it, but after some
thought I think this is not compatible with it :-(
If I'm wrong about esql I would like to suggest to rename the tags
(selector -> page-set, case -> subpage, otherwise -> default-page) and
to convert all illegal characters in subpage @name e.g. to "_" so that
spaces and hyphens would not cause compiler exceptions.
In addition documentation or / and an example would be needed.
As soon as that is available I will commit it to C2.1 CVS.
BTW have you tried the filter transformer yet? Of course with XSPs
such a solution would have the 64K limit.
xform.xsl
I'm not sure if it is necessary to require a session for
forms. I think sessions should be avoided if possible since they
require server storage and don't scale well.
BTW I did some digging on xalan-dev on "evaluate()". As I have
expected in a reply to Peter, "evaluate()" is a rather expensive
operation and it would be worthwile to think about a way araound using
it.
On 24.Jul.2001 -- 05:57 PM, Torsten Curdt wrote:
> here is where we are at:
>
> - on the first view the XSP page passes the SAX events
> to a new DOMObject. This holds the instance data of
> the XForm.
How could this be used?
> - all XForm elements are registerd inside a PostRegistry
> (this circumvents the checkbox problem)
> FIXME: the PostRegistry is declared ThreadSafe. I haven't
> checked that so far..
Could be done by looking at the schema data / validator information.
> - the XForm instances are saved inside the session
Requiring sessions is not very popular.
> - the XForm instance data are inserted into the XSP page via XMLFragment interface
> - getValue( String XPath ) returns a text node's string representation
> FIXME: right now the XPath must end on /text() since this is the full XPath.
> Should this be changed?
> - setValue( String XPath ) set a the value of a text node (see getValue)
> FIXME: same as above and needs to insert a text node if there is none
> already. (happens on immediat close of tags: <firstname/>)
> - DOMObject is now an interface AbstractDOMObject is the implementation
> - now we have a DOMObjectOutputWrapper that opens
> the door for backend mapping like beans or whatever.
> - FIXME: the DOMObject interface has to be extended. Only "setValue" and
> "getValue" cannot handle multiple values of a "selectMany"
> - the first (raw) version of the XFormAction is working. Post values
> already find their way back into the instance
Excellent. Have you thought about multiple forms on a document?
> I was thinking about the validation constraints issue.. Why is the
> validation in the XForm spec bound to the XForm elements and not
> to the xform:instance?! Just a thought...
Perhaps because you may have none(?) to multiple instances in a
document.
> Should we put the validation constrains and the error handling into
> another namespace not to break XForm compatibiliy? (And contact the
> XForm group...)
Actually, the more I think about this, I feel more and more that
XForms is a client side spec and I start to feel that everything else
that we would like to have needs to be layered on top of it. Thus it
would probably lead to a different API for XSP Forms than
XForms. Forms on XML pages would of course use XForms. Still there are
many concerns that both would share and components that would be of
use in either case.
> I also need an interface to pass some information to mapped backends.
> E.g. we need to be able to tell a bean - process this order now!
>
> Well, anyway to keep you guys up-to-date...
> Here are the current files...
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]
