> 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
I'm sorry... a bad habit: code first, doc last ;) will add it!
> 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 :-(
Exactly! The sel logicsheet should be almost finished. (there are
some nice things we can add later)
Why do you think so?! The only restriction that you have to be
aware of is the definition of local variables. But this is one
is quite easy to handle... I will provide a patch esql to work
with the sel logicsheet and will have a look into the other
logicsheets as well...
> 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.
I don't care about the tag names... (although I personally don't like to
have a "-" in tag names)
But I then would suggest:
<page-set>
<page>
<default-page>
We have to decide if we are talking about pages or subpages ;)
> In addition documentation or / and an example would be needed.
Sure. I'll add this!
> As soon as that is available I will commit it to C2.1 CVS.
Cool!
> BTW have you tried the filter transformer yet? Of course with XSPs
> such a solution would have the 64K limit.
Yes, I had a look. But if the sel logicsheet is working then
why fireing the unwanted SAXevent and filter them out again?!
I mean... It's up to you... it should work with the transformer
as well. It's not related to the XForm implementation.
> 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.
Well, we will need session most of the time anyway.. scale or not.
But this would mean you have to POST always the WHOLE instance
data! I'm not quite sure if this is really better! ok for a
simple form - but not nice for comlex ones! Especially you have
to take into account that we might also want to support WML.
Unfortunately this way the POST data may exceed easily the
maximal POST size of the device. And at 9600 baud I'll make
definetly a difference!
> 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.
Well, as said we could use our own format. And transfer it
into xform when needed. But maybe we should make this clear
by using a different - maybe a second namespace (e.g. intermediate
xform -ixform)
<xform:textbox name="something">
<ixform:value>bla</ixform:value>
</xform:textbox>
This also how we could define the errors or validation
constrains...
..or create completely new format that can be processed
more easily and have a stylesheet that will make xform
out of 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?
This builds the XForm instance.
> > - 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.
Could you explain?
What I could think of is to look at the sel:page elements
inside the XForm descriptor. But this gives another expense
of parsing and searching inside the XFormAction.
> > - the XForm instances are saved inside the session
>
> Requiring sessions is not very popular.
...but very common - I don't think it's that bad.
Where else do you hold your authentification information e.g.
> > - 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?
Yes. Should already work...
> > 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.
Don't get this explanation... Anyway you should have a least one instance
per document, shouldn't you?
> > 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.
Give it a shot and tell us what you have in mind..
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
