On 25.Jul.2001 -- 02:36 PM, Torsten Curdt wrote:
> > 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!
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.
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.
>
> > 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.
> > 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.
>
> > 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.
> > 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.
> 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?
BTW have you had a look at WriteDOMTransformer & ReadDOMTransformer?
They might come in handy with your design.
> > 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.
> 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.
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.
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.
> > > - 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".
> > > - 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?
> > 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 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.
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]
