> > > 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!
>
> Since I feel responsible for code that I commit I'd like to understand
> it first. That's a bit harder without comments, so it'll take longer
> to review.
>
> In addition, I am too working on forms, so it'll be easier to
> cooperate if I understand what you're doing and where you're heading.
> Speaking of which I am currently investigating a transformation from
> xforms to xforms' with instances copied to referencing elements as
> nested value elements.
I'm adding the comments and hand it to you :)
> Although I said that "evaluate" is too expensive that's what I'm
> currently doing. After I got this binding issue resolved we could
> thing about making this step optional i.e. having value attributes
> again or conform to xforms with a penalty.
Sounds good.
> > > 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...
>
> I remember having tried to split output to different methods before
> and yes, I think the problem where local vars that esql
> needed. Perhaps this is of no importance if a complete esql-block is
> in such a method. But someone will put an esql-connection element
> around all subpages and here we go...
>
> If that could be circumvented, great.
I have had look. This should not be a problem. I'll take care of this.
Was about to add some features to it anyway...
> > > 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 ;)
>
> Thought <page> is already used, but that's just some example
> stylesheets and we have namespaces, so that's not important. Only
> select-case-otherwise doesn't look web designer compatible.
Well, ok, then let's make it:
<subpage-set>
<subpage>
<default-subpage>
Maybe we should use better "sub" than "sel" as namespace prefix...
> > > 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.
>
> Sure. It doesn't hurt to offer this as well. This suggestion was made
> only to have something that sure wouldn't break any other taglib.
Sure.
> > > 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.
>
> For applications, sure. But if you don't care too much about security
> since what it protects is not worth the effort to protect it or if it
> is a single form e.g. subscription to a newsletter or request for
> further information, it would be too much.
Don't know... maybe we can make it optional. But since such
easy things can be addressed really nicely with the current
FormValidatorAction. I would really like to use sessions first
and take care of this optimization later on.
> > 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!
>
> AFAIK you could only affect the data posted back from the client if
> you programmed the submit method yourself in ECMA script or java &c. I
> wouldn't expect that to be possible especially on small devices.
>
> If you were refering to all the other data that's usually stored in a
> session but that's not present in this form, you're right. But how
> does your design make this easier?
Well, without a session the whole instance data has to be posted
for each subpage. When thinking of a 5 pages form this can be a lot
of data... the current design just posts the data of the current
subpage controls. This would be less than 1/5 of the whole instance
data!! BTW: that's the usual way
We only need to know what elements to expect in the XFormAction.
Right now I solved it via the PostRegistryComponent. Using
the xform descriptor might be even better (if cached). But
we would have to look in the desciptor via XPath for the page
declarations...
> BTW have you had a look at WriteDOMTransformer & ReadDOMTransformer?
> They might come in handy with your design.
Yes. I've had a look. But I don't think they are of great help on
this one.
> > > 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>
>
> An intermediate format would be needed. At least I think it would ease
> writing stylesheets xforms2* when instance data is "near". OTOH the
> current situation is quite nice for usage reasons. You might want to
> put the instance data together with model into a different file an
> include it for example.
>
> BTW I think the example xform.xml you provided is incorrect in using
> xform:xform as parent for form controls. AFAIU xform is only used in
> the head portion and contains instance data, model etc. This way
> different forms' controls could be mixed arbitrarily.
I thought it was an alternative to specifiying the xform attribute.
Anyway... Could you correct the xform.xml then please?
So we have correct example to try with...
> > This also how we could define the errors or validation
> > constrains...
>
> One idea could be to use what Pirouman said about error elements in
> the instance data. Messages would be presented by using output
> elements referencing these error instances. If they are empty, no
> error message is presented to the user.
Yes. This might be a good sollution. But where are the error message
specified?! The instance would only hold a copy of them...
> I reckon daily usage would make a taglib necessary, that translates
> some even more abstract input controls to xform input controls. But
> that's probably very application specific.
Could you give an example?
> We could provide a simple example, though.
>
> > ..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:
> > > > - 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.
>
> OK, so that creates a representation of the instance data in
> memory. But that would be used how? Apart from the above reasons why
> sessions are not wanted sometimes.
It holds the instance data in the session. It gives a easy way
of directly SAX in and SAX out. It provides the necessary methods
to modifiy the instance via XFormAction.
> > > > - 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 problem you're refering to is that given a checkbox "foo" on your
> form the browser only posts "foo=value" if selected but wouldn't post
> anything if it isn't, right? So if you knew that on this form there is
> a checkbox "foo" and it's not included in the posted data, it must
> have been disabled.
>
> This information (that there is a checkbox "foo") is contained in the
> information that is needed by the validation process. Otherwise it
> wouldn't be able to check "foo".
Exactly - that's the problem. This information is only available
in the descriptor by selecting via XPath
"//sel:page[@name='page']/(descendant::xform:textbox|descendant::xform:checkbox)"
or via PageRegistry.
The descriptor+XPath way gives us unwanted dependancy of the sel:page element
(and it is a hell of an expression ;) ... but maybe we can cache this
nodelist in our action as well...
Hm... what about this:
<map:match pattern="xform.html">
<map:act type="XFormAction">
<map:parameter name="pageroot" value="//sel:page[@name='$page$']"/>
<map:parameter name="default" value="fillin1"/>
<map:generate type="serverpages" src="docs/samples/xform/xform.xml">
<map:parameter name="page" value="{page}"/>
</map:generate>
</map:act>
<map:transform src="stylesheets/xform2html.xsl"/>
<map:serialize type="html"/>
</map:match>
This would specifiy the path to the root node. We only would
have to replace the $page$ (unfortunately {page} cannot work)
by the page the action receives the data from. Then we have
the root node of the suppage and we can make a select
"descendant::xform:textbox|descendant::xform:checkbox" to get
the expected elements. if we cache the nodelists with the
pageroot expression as key in a Hashtable or somehting we
should really have little expense...
We can also provide the "//sel:page[@name='$page$']" expression
as default value so you only have to change it if you
don't use the sel:logicsheet...
Cool!
> > > > - 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.
>
> How about applications that don't need authentication?
Was just an example...
> > > Excellent. Have you thought about multiple forms on a document?
> >
> > Yes. Should already work...
>
> There's more to it. You need to determine wich form got submitted
> since you can not split it to different HTML forms as they cannot be
> nested or mixed. So a sitemap component has to find out which one is
> the right one and "redirect" to the appropriate URI. "redirect"
> because the request object has to be maintained. What about forms that
> submit to a different site (or a part of the site that's not
> controlled by C2)? (not solvable?)
I don't see the problem could you explain a bit more.
The action already knows about which http form was submitted.
> > > > 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?
>
> I think the schema def in the appendix says any number. But I'm not
> 100% sure. BTW it is bound to the model, not to the form controls. And
> there's exactly one model (child of xform).
>
> > > > 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..
>
> I'm still trying to sort my thoughts out. But I will stay in touch.
>
> I hope to have a stylesheet tomorrow that does the full binding
> stuff. After that I'll look into a multiple forms actor or into
> validation.
Gonna send you the commented sources soon
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
