> On 06.Aug.2001 -- 07:30 PM, Torsten Curdt wrote:
> > So we are back to the transformer ;) We should really decide which way to go!
> > So what are your PROs for the transformer now?
>
> Unfortunately, yes. Reason is that evalute is even slower (and xalan
> specific, well, DTM would be as well). Plus scoped binding requires to
> keep track of all parent elements's binding. That would have been more
> difficult with xslt, I think. So for any form control its binding is
> relative to its parent control's binding, which in turn depends on its
> parent's etc.
Well, not easy - but possible. Should work already in my current
implementation (except for the "id()" syntax). Although it's giving
us hell of stylesheet! (Not in a good sense)
> Of course, if this degenerated xforms syntax is already present on the
> page, it would be better. So this is more like an option for those
> that like to stay as close to the WD as possible. Frankly, I quite
> like the idea of separating instance data from the representation.
>
> So this is just a piece of the whole but it's not a required piece, I
> think.
Well, I don't see a reason not to use a intermediate format.
As long as the syntax of the source stays the same. So we are
able to use standard XForm tools later on and people see only
XForm syntax when creating the forms. Only knowing about the
intermediat syntax would be the xform2*.xsl designer - but I
guess that's fine.
> > Not for the submitInfo and the model. But you don't wanna POST the
> > instance all the time, don't you? Where do you wanna hold the instance
> > data?
>
> I think both views on this are valid indeed. With an application that
> uses sessions anyway, your claim is perfectly true and very
> reasonable. There need to be something that keeps track of all
> data. For other, lightweight applications this is plain overkill.
I only see this overkill for one-page forms.
> > Do we agree on holding the instance as DOM in the session?
>
> I feel like we need to offer both. Question is, how could this choice
> be designed so that it is an obvious and simple one? Have the
> transformer decide whether a session exists?
>
> > > Caching is done only during the lifetime of a transformer instance as
> > > I have no idea how to decide easily if a cached form declaration &
> > > instance data is still valid. Ideas?
> >
> > Well, I decided that the structure of the xform instance may not change
>
> Right. Works fine as long as you're not actively developing on your
> application :-| Wait a moment - C2 keeps track of the last
> modification time of the generator (xsp, xml) so if we were able to
> access that, we'd know if the model may have changed or not. (feasible??)
>
> > but the values. So what already works for me is the following:
>
> [snip]
>
> > <deliveryaddress id="00200000000000000843">
>
> [snip]
>
> So this is your application wide unique instance id? Does it change
> everytime the instance data is updated or is this akin to a session
> id?
no this is the id of the deliveryaddress (database id) ;)
> > Right now I'm trying to update the instance data directly
> > via SAX events. But this gave me some headaches in the last few days...
>
> So you walk you DOM according to the events and change values &
> attributes? Would be interesting if it's really cheaper than just
> rebuilding it.
I hope (and think) it is cheaper. Just because rebuilding isn't enough.
We cannot throw away our form data an start with a new instance on each
POST. We need to merge the changes into the DOM to keep the old values.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
