In-line XSLT templates using XForms instances

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

In-line XSLT templates using XForms instances

smcmurray
I have built an xbl that allows you to bind an xslt template to one or
more XForms instances.
It is as simple as this:

<stylesheet href="path/to/stylesheet" datasource="list;of;instances"/>

The element has a "render" method that can be invoked on demand, or
can act as an event listener.
It is smart enough to stay in sync with outstanding submissions.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

Josef Spillner-4
On Monday 14 May 2007 21:07:24 smcmurray wrote:
> I have built an xbl that allows you to bind an xslt template to one or
> more XForms instances.
> It is as simple as this:
>
> <stylesheet href="path/to/stylesheet" datasource="list;of;instances"/>
>
> The element has a "render" method that can be invoked on demand, or
> can act as an event listener.
> It is smart enough to stay in sync with outstanding submissions.

This sounds interesting. Can you please explain to the non-XBL aware of us
what it does exactly? Will it create the form layout from the instances?

Josef
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by smcmurray
> This sounds interesting. Can you please explain to the non-XBL aware of us
> what it does exactly? Will it create the form layout from the instances?

It will take the contents of the instances contained in @datasource
and feed them into the xsl stylesheet indicated by @href.
Each instance in the list is fed to the stylesheet as a stylesheet
parameter with the same name as the instance.
The result of the xslt transform is placed back into the document as
the contents of the xbl-bound element (in the example above, the
stylesheet element).

You can use the xsl stylesheet to generate whatever content you want
to appear in your document. That could include XForms UI controls.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
In reply to this post by smcmurray
I agree, fascinating.  Did you post the XBL somewhere?  I was tempted to
suggest making this an xf:extension element under xf:output with
xf:output provoding the binding but the datasources being complex types
makes it clear this doesn't fit into the current XForms 1 series form
controls.
Leigh.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
smcmurray
Sent: Monday, May 14, 2007 12:07 PM
To: [hidden email]
Subject: In-line XSLT templates using XForms instances

I have built an xbl that allows you to bind an xslt template to one or
more XForms instances.
It is as simple as this:

<stylesheet href="path/to/stylesheet" datasource="list;of;instances"/>

The element has a "render" method that can be invoked on demand, or
can act as an event listener.
It is smart enough to stay in sync with outstanding submissions.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

Aaron Reed
In reply to this post by smcmurray

Could make it an extension of xf:group.

Klotz, Leigh wrote:

> I agree, fascinating.  Did you post the XBL somewhere?  I was tempted to
> suggest making this an xf:extension element under xf:output with
> xf:output provoding the binding but the datasources being complex types
> makes it clear this doesn't fit into the current XForms 1 series form
> controls.
> Leigh.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> smcmurray
> Sent: Monday, May 14, 2007 12:07 PM
> To: [hidden email]
> Subject: In-line XSLT templates using XForms instances
>
> I have built an xbl that allows you to bind an xslt template to one or
> more XForms instances.
> It is as simple as this:
>
> <stylesheet href="path/to/stylesheet" datasource="list;of;instances"/>
>
> The element has a "render" method that can be invoked on demand, or
> can act as an event listener.
> It is smart enough to stay in sync with outstanding submissions.
>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
As written it only notices submission changes; it would need to monitor
for child node changes, presumably on all modifications.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Reed
Sent: Tuesday, May 15, 2007 1:01 PM
To: [hidden email]
Subject: Re: In-line XSLT templates using XForms instances


Could make it an extension of xf:group.

Klotz, Leigh wrote:
> I agree, fascinating.  Did you post the XBL somewhere?  I was tempted
to
> suggest making this an xf:extension element under xf:output with
> xf:output provoding the binding but the datasources being complex
types
> makes it clear this doesn't fit into the current XForms 1 series form
> controls.
> Leigh.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by Aaron Reed
Not necessarily. It may not be desirable to do the transform on every
child node change.
If that is desirable, the render method can be used as an event
listener.

On May 15, 2:24 pm, "Klotz, Leigh" <[hidden email]> wrote:

> As written it only notices submission changes; it would need to monitor
> for child node changes, presumably on all modifications.
>
> -----Original Message-----
> From: [hidden email]
>
> [mailto:[hidden email]] On Behalf Of Aaron
> Reed
> Sent: Tuesday, May 15, 2007 1:01 PM
> To: [hidden email]
> Subject: Re: In-line XSLT templates using XForms instances
>
> Could make it an extension of xf:group.
>
> Klotz, Leigh wrote:
> > I agree, fascinating.  Did you post the XBL somewhere?  I was tempted
> to
> > suggest making this an xf:extension element under xf:output with
> > xf:output provoding the binding but the datasources being complex
> types
> > makes it clear this doesn't fit into the current XForms 1 series form
> > controls.
> > Leigh.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by Aaron Reed
Is there an XForms convention for binding to multiple instances?

On May 15, 1:01 pm, Aaron Reed <[hidden email]> wrote:
> Could make it an extension of xf:group.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
In reply to this post by smcmurray
As an xf:extension element attached to xf:group, it should follow the
same MVC rules that other XForms controls do.
I agree as its own element it can do what it wants to.
Leigh.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
smcmurray
Sent: Tuesday, May 15, 2007 2:32 PM
To: [hidden email]
Subject: Re: In-line XSLT templates using XForms instances

Not necessarily. It may not be desirable to do the transform on every
child node change.
If that is desirable, the render method can be used as an event
listener.

On May 15, 2:24 pm, "Klotz, Leigh" <[hidden email]> wrote:
> As written it only notices submission changes; it would need to
monitor

> for child node changes, presumably on all modifications.
>
> -----Original Message-----
> From: [hidden email]
>
> [mailto:[hidden email]] On Behalf Of Aaron
> Reed
> Sent: Tuesday, May 15, 2007 1:01 PM
> To: [hidden email]
> Subject: Re: In-line XSLT templates using XForms instances
>
> Could make it an extension of xf:group.
>
> Klotz, Leigh wrote:
> > I agree, fascinating.  Did you post the XBL somewhere?  I was
tempted
> to
> > suggest making this an xf:extension element under xf:output with
> > xf:output provoding the binding but the datasources being complex
> types
> > makes it clear this doesn't fit into the current XForms 1 series
form
> > controls.
> > Leigh.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
In reply to this post by smcmurray
There is only one place I know of that that bind to an instance:
<submission replace='instance' instance='foo' />
Everwhere else uses XPath expressions to be more general, and the
instance('x') function at the start of the path.  
Submission/@instance doesn't do this, presumably because it is a binding
to a complexType, and is in fact just about the only one in XForms.
Everything else either binds to a simpleType node or binds to a nodeset,
which is then iteratively applied to as a list of simileTypes.

Your thing needs to bind to multiple complex structures.  

Here are a couple of random ideas, no more than twiddles on what you
have:

Normally list types in attributes are space separated.  I suspect you
can change datasource="list;of;instances" to datasource="list of
instances" without a problem.  

Are the instances within the XSLT accessed by name?  I looked briefly at
the XBL and didn't see how to refer to them from within my
transformation.

If you want control over when the XSLT is rendered, it might make sense
to have the control obey xforms-refresh in some way, or have some event
that can be targeted at the control (by its id) to cause it to refresh.
Most XForms authors are going to expect the controls to be always in
sync with the model; one option for you might be to have the control
always update, but when you want to prevent its update, listen for and
cancel xforms-refresh; you can then put a dispatch of your own event on
xforms-submit-done to then dispatch the custom event to your control to
have it update only then. I know this is partly baked and cumbersome
sounding, but I'm trying to reconcile the MVC architecture with your
design goal, which seems an exception to it.

Leigh.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
smcmurray
Sent: Tuesday, May 15, 2007 2:34 PM
To: [hidden email]
Subject: Re: In-line XSLT templates using XForms instances

Is there an XForms convention for binding to multiple instances?

On May 15, 1:01 pm, Aaron Reed <[hidden email]> wrote:
> Could make it an extension of xf:group.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by smcmurray
> Your thing needs to bind to multiple complex structures.
>
> Normally list types in attributes are space separated.  I suspect you
> can change datasource="list;of;instances" to datasource="list of
> instances" without a problem.

yeah. that's easy. (I originally has it separate on \b.)

> Are the instances within the XSLT accessed by name?  I looked briefly at
> the XBL and didn't see how to refer to them from within my
> transformation.

Each instance is sent to the stylesheet as a stylesheet parameter
using the name of the instance.
So you catch it in the stylesheet with <xsl:param
name="myInstanceName"/>

> If you want control over when the XSLT is rendered, it might make sense
> to have the control obey xforms-refresh in some way, or have some event
> that can be targeted at the control (by its id) to cause it to refresh.
> Most XForms authors are going to expect the controls to be always in
> sync with the model; one option for you might be to have the control
> always update, but when you want to prevent its update, listen for and
> cancel xforms-refresh; you can then put a dispatch of your own event on
> xforms-submit-done to then dispatch the custom event to your control to
> have it update only then. I know this is partly baked and cumbersome
> sounding, but I'm trying to reconcile the MVC architecture with your
> design goal, which seems an exception to it.

I used to have my own fairly lame datasource binding. I ripped that
out in favor of XForms instances. However I am very green at Xforms,
and am learning as I go.
That explains why this binding has a really strange accent.
I agree that to conform with XForms expectations, the template should
stay in sync with the model.
There is a caveat there, though:

Because this binding spans multiple instances (and potentially
multiple models), it will need to stay in sync with all of them.
Naturally, instances are asynchronous. So if a template (T) depends on
multiple instances, say (A, B, and C), you end up with choreography
like this.
A gets updated, causing a cascade to B. T begins a transform as soon
as A refreshes, but before B refreshes. Meanwhile, the user updates C,
causing another transform on T. T finishes the A-spawned transform
just in time for the C-spawned transform. The C-spawned transform is
still in process when B triggers another transform. And so forth...

Also, if I alter the instance via js, I may need to change two or more
nodes before I have the instance data where I want it for the next
transform.

Now, that isn't really a show stopper, but it does take some careful
choreography. And it also makes it very desirable to have an easy
mechanism for batching transforms.

I think that your suggestion above actually covers my concerns fairly
well, so maybe I'm just being noisy. But the transforms can take long
enough that it is not uncommon for them to collide with each other.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by smcmurray
I now have it listen for xforms-value-changed on each of the instances
to which it is bound.
I also added a disabled property, which when true causes it to ignore
all rendering requests.
It still allows only one render at a time. All rendering requests are
ignored when a render is in process.
Also, each rendering request will wait for any submissions that are
outstanding at the time of the request and will ignore the results of
any subsequent submissions.

Is xforms-value-changed enough? Or does it need to respond to other
events as well? As I read it, the xforms-refresh event should dispatch
xforms-value-changed if necessary.

> If you want control over when the XSLT is rendered, it might make sense
> to have the control obey xforms-refresh in some way, or have some event
> that can be targeted at the control (by its id) to cause it to refresh.
> Most XForms authors are going to expect the controls to be always in
> sync with the model; one option for you might be to have the control
> always update, but when you want to prevent its update, listen for and
> cancel xforms-refresh; you can then put a dispatch of your own event on
> xforms-submit-done to then dispatch the custom event to your control to
> have it update only then.
> Leigh.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by smcmurray
> Normally list types in attributes are space separated.  I suspect you
> can change datasource="list;of;instances" to datasource="list of
> instances" without a problem.

Done.

> If you want control over when the XSLT is rendered, it might make sense
> to have the control obey xforms-refresh in some way, or have some event
> that can be targeted at the control (by its id) to cause it to refresh.

I made it listen for xforms-value-changed on each instance it is bound
to.

> Most XForms authors are going to expect the controls to be always in
> sync with the model; one option for you might be to have the control
> always update, but when you want to prevent its update, listen for and
> cancel xforms-refresh; you can then put a dispatch of your own event on
> xforms-submit-done to then dispatch the custom event to your control to
> have it update only then.

I added a disabled property. When disabled, it ignores all requests to
render.

It ignores all render requests when a render is in process.

Also, a render waits for submissions that are pending at the time of
the render request. Results of submissions that occur after the render
request will be ignored by the render.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

Aaron Reed
In reply to this post by smcmurray
I suggested it as an extension to group since group doesn't have the
restriction of only being bindable to simple content.

--Aaron

Klotz, Leigh wrote:

> As an xf:extension element attached to xf:group, it should follow the
> same MVC rules that other XForms controls do.
> I agree as its own element it can do what it wants to.
> Leigh.
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> smcmurray
> Sent: Tuesday, May 15, 2007 2:32 PM
> To: [hidden email]
> Subject: Re: In-line XSLT templates using XForms instances
>
> Not necessarily. It may not be desirable to do the transform on every
> child node change.
> If that is desirable, the render method can be used as an event
> listener.
>
> On May 15, 2:24 pm, "Klotz, Leigh" <[hidden email]> wrote:
>> As written it only notices submission changes; it would need to
> monitor
>> for child node changes, presumably on all modifications.
>>
>> -----Original Message-----
>> From: [hidden email]
>>
>> [mailto:[hidden email]] On Behalf Of Aaron
>> Reed
>> Sent: Tuesday, May 15, 2007 1:01 PM
>> To: [hidden email]
>> Subject: Re: In-line XSLT templates using XForms instances
>>
>> Could make it an extension of xf:group.
>>
>> Klotz, Leigh wrote:
>>> I agree, fascinating.  Did you post the XBL somewhere?  I was
> tempted
>> to
>>> suggest making this an xf:extension element under xf:output with
>>> xf:output provoding the binding but the datasources being complex
>> types
>>> makes it clear this doesn't fit into the current XForms 1 series
> form
>>> controls.
>>> Leigh.
>
> _______________________________________________
> dev-tech-xforms mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

Aaron Reed
In reply to this post by smcmurray

One issue you'll have is that xforms-value-changed is targeted at the
control who is bound to the changed instance node.  It doesn't go to the
instance document.  xforms-rebuild, -refresh, -recalculate and
-revalidate go to the model that contains the instance document.  But be
aware that they could have been triggered due to changes in another
instance in the model and not the instance that you are interested in.
You could always listen for mutation events on the instance document,
but those are pretty expensive.

--Aaron

smcmurray wrote:

> I now have it listen for xforms-value-changed on each of the instances
> to which it is bound.
> I also added a disabled property, which when true causes it to ignore
> all rendering requests.
> It still allows only one render at a time. All rendering requests are
> ignored when a render is in process.
> Also, each rendering request will wait for any submissions that are
> outstanding at the time of the request and will ignore the results of
> any subsequent submissions.
>
> Is xforms-value-changed enough? Or does it need to respond to other
> events as well? As I read it, the xforms-refresh event should dispatch
> xforms-value-changed if necessary.
>
>> If you want control over when the XSLT is rendered, it might make sense
>> to have the control obey xforms-refresh in some way, or have some event
>> that can be targeted at the control (by its id) to cause it to refresh.
>> Most XForms authors are going to expect the controls to be always in
>> sync with the model; one option for you might be to have the control
>> always update, but when you want to prevent its update, listen for and
>> cancel xforms-refresh; you can then put a dispatch of your own event on
>> xforms-submit-done to then dispatch the custom event to your control to
>> have it update only then.
>> Leigh.
>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
It doesn't seem that mutation events are possible.
So, I could force each instance into its own model and listen for
xforms-refresh.
But such a restriction would severely limit the value of the
extension.

Another ugly solution would be to store a hash of each instance of
interest and compare it on every xforms-refresh.

Isn't there any more elegant way to know when an instance changes?

On May 16, 9:38 am, Aaron Reed <[hidden email]> wrote:

> One issue you'll have is that xforms-value-changed is targeted at the
> control who is bound to the changed instance node.  It doesn't go to the
> instance document.  xforms-rebuild, -refresh, -recalculate and
> -revalidate go to the model that contains the instance document.  But be
> aware that they could have been triggered due to changes in another
> instance in the model and not the instance that you are interested in.
> You could always listen for mutation events on the instance document,
> but those are pretty expensive.
>
> --Aaron
>
> smcmurray wrote:
> > I now have it listen for xforms-value-changed on each of the instances
> > to which it is bound.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

Aaron Reed
You could try asking on the W3C's mailing list.  There are a lot of
experienced people there who might have ideas.

--Aaron

smcmurray wrote:

> It doesn't seem that mutation events are possible.
> So, I could force each instance into its own model and listen for
> xforms-refresh.
> But such a restriction would severely limit the value of the
> extension.
>
> Another ugly solution would be to store a hash of each instance of
> interest and compare it on every xforms-refresh.
>
> Isn't there any more elegant way to know when an instance changes?
>
> On May 16, 9:38 am, Aaron Reed <[hidden email]> wrote:
>> One issue you'll have is that xforms-value-changed is targeted at the
>> control who is bound to the changed instance node.  It doesn't go to the
>> instance document.  xforms-rebuild, -refresh, -recalculate and
>> -revalidate go to the model that contains the instance document.  But be
>> aware that they could have been triggered due to changes in another
>> instance in the model and not the instance that you are interested in.
>> You could always listen for mutation events on the instance document,
>> but those are pretty expensive.
>>
>> --Aaron
>>
>> smcmurray wrote:
>>> I now have it listen for xforms-value-changed on each of the instances
>>> to which it is bound.
>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
When the topic of repeat listening to changes came up, several
implementors said that listening for mutation or xforms-value-changed
events wasn't efficient enough and they had to have internal
implementation features necessary to make repeat efficient.  This sounds
a lot like that.  The repeat optimizations also include, presumably,
some analysis to determine quickly whether a change to the instance is
going to affect the repeat, and which repeat items it affects.  That
analysis is possible in the case of repeat, but I suspect it's
impossible in the XSLT case without some XSLT meta-evaluation, which is
probably too expensive to do even if the code were to magically appear.

So, I suspect that to do everything smcmurray wants and everything that
XForms would suggest will require some optimizations in Mozilla to batch
up an event when the instance changes, which probably won't be
forthcoming until there's a call for events to be sent on changes to
bindings to complex types.  Given that the XSLT is slow and expensive,
it sounds more like the kind of timing we reserved for rebuild
(dependency graph creation).

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Aaron
Reed
Sent: Thursday, May 17, 2007 8:50 AM
To: [hidden email]
Subject: Re: In-line XSLT templates using XForms instances

You could try asking on the W3C's mailing list.  There are a lot of
experienced people there who might have ideas.

--Aaron

smcmurray wrote:

> It doesn't seem that mutation events are possible.
> So, I could force each instance into its own model and listen for
> xforms-refresh.
> But such a restriction would severely limit the value of the
> extension.
>
> Another ugly solution would be to store a hash of each instance of
> interest and compare it on every xforms-refresh.
>
> Isn't there any more elegant way to know when an instance changes?
>
> On May 16, 9:38 am, Aaron Reed <[hidden email]> wrote:
>> One issue you'll have is that xforms-value-changed is targeted at the
>> control who is bound to the changed instance node.  It doesn't go to
the
>> instance document.  xforms-rebuild, -refresh, -recalculate and
>> -revalidate go to the model that contains the instance document.  But
be
>> aware that they could have been triggered due to changes in another
>> instance in the model and not the instance that you are interested
in.
>> You could always listen for mutation events on the instance document,
>> but those are pretty expensive.
>>
>> --Aaron
>>
>> smcmurray wrote:
>>> I now have it listen for xforms-value-changed on each of the
instances
>>> to which it is bound.
>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: In-line XSLT templates using XForms instances

smcmurray
In reply to this post by Aaron Reed
Well, I can't think of a reasonable way to achieve automatic sync
between the instances and the template.
I can't even think of a decent hack, without investing a lot more
thought into it.
The template meets my needs right now, but doesn't really fit natively
into the XForms world.
I had hoped that since I am blatantly mooching off the excellent work
of the XForms community, I could contribute at least some small thing
back, if it could be useful. I don't think I have accomplished that.
Maybe it isn't worth pursuing. But perhaps somebody with more ability
than myself might be able to run with this.

I don't think I can take it much further, though. I think I will just
step back. If somebody with talent sees some value here and wants to
pursue it, I'd love to watch and learn.

On May 17, 3:15 pm, "Klotz, Leigh" <[hidden email]> wrote:
> So, I suspect that to do everything smcmurray wants and everything that
> XForms would suggest will require some optimizations in Mozilla to batch
> up an event when the instance changes, which probably won't be
> forthcoming until there's a call for events to be sent on changes to
> bindings to complex types.  Given that the XSLT is slow and expensive,
> it sounds more like the kind of timing we reserved for rebuild
> (dependency graph creation).

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: In-line XSLT templates using XForms instances

Klotz, Leigh
I'm sorry if I gave you a bad expression.  I think you've done a great
job and I've certainly learned something.  I think you've advanced the
art, exposed some corner cases, and done a great job of integrating your
extension into a standard framework.  XForms 1.0, with its lack of
support for complex types, makes it impossible to do it totally cleanly,
and it's certainly not your fault nor any failure of yours.

The only thing I can suggest in terms of changes to your code at this
point is to think about supporting an event to tell the stylesheet to
re-run if an author wants them run more frequently than after each
submission response.  Here's an example with a made-up event name.
  <trigger>
    <label>Change</label>
    <action ev:event="DOMActivate">
      <setvalue ref="instance('a')/b/c/d" value=". + 1" />
      <dispatch name="stylesheet-transform" target="my-stylesheet-1" />
    </action>
  </trigger>

Leigh.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
smcmurray
Sent: Thursday, May 17, 2007 4:45 PM
To: [hidden email]
Subject: Re: In-line XSLT templates using XForms instances

Well, I can't think of a reasonable way to achieve automatic sync
between the instances and the template.
I can't even think of a decent hack, without investing a lot more
thought into it.
The template meets my needs right now, but doesn't really fit natively
into the XForms world.
I had hoped that since I am blatantly mooching off the excellent work
of the XForms community, I could contribute at least some small thing
back, if it could be useful. I don't think I have accomplished that.
Maybe it isn't worth pursuing. But perhaps somebody with more ability
than myself might be able to run with this.

I don't think I can take it much further, though. I think I will just
step back. If somebody with talent sees some value here and wants to
pursue it, I'd love to watch and learn.

On May 17, 3:15 pm, "Klotz, Leigh" <[hidden email]> wrote:
> So, I suspect that to do everything smcmurray wants and everything
that
> XForms would suggest will require some optimizations in Mozilla to
batch
> up an event when the instance changes, which probably won't be
> forthcoming until there's a call for events to be sent on changes to
> bindings to complex types.  Given that the XSLT is slow and expensive,
> it sounds more like the kind of timing we reserved for rebuild
> (dependency graph creation).

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
12