One of the upcoming features of Aggregate is:
"Upload and use of XSL transforms to Aggregate for generic
transformational publishing of data to downstream services (SOAP,
JSON, etc.)."
Is there an estimate on when this feature will be available? Is there
a vision on how this will be implemented?
Related to this is that I've been looking at adding a webhook feature
to Aggregate but I'm finding it difficult/tedious due to the lack of
unit tests. I think it would be beneficial to add some support classes
from which the community could base tests on.
Aggregate is undergoing a complete re-write for the 1.0 release. We will be
looking at the XSL mechanism once the basic system is stable and integrated
with an authorization implementation. My guess is that the XSL
functionality may be available late in October.
The general idea is to support the upload of an .xsl transform definition.
This would operate on a basic xml rendering of the form, likely with all
nodes rendered, not just the relevant ones with data. The transformed
output would then be published to a downstream server.
Mitch
···
On Wed, Sep 22, 2010 at 2:25 AM, magnusvxu wrote:
One of the upcoming features of Aggregate is:
"Upload and use of XSL transforms to Aggregate for generic
transformational publishing of data to downstream services (SOAP,
JSON, etc.)."
Is there an estimate on when this feature will be available? Is there
a vision on how this will be implemented?
Related to this is that I've been looking at adding a webhook feature
to Aggregate but I'm finding it difficult/tedious due to the lack of
unit tests. I think it would be beneficial to add some support classes
from which the community could base tests on.
The general idea is to support the upload of an .xsl transform definition.
This would operate on a basic xml rendering of the form, likely with all
nodes rendered, not just the relevant ones with data. The transformed
output would then be published to a downstream server.
May I suggest having the option of assigning multiple downstream
servers (perhaps with their own transformations?). One reason for this
is of course to provide a fail-safe if one of the servers are offline,
but another reason is to allow for mass distribution.
That is planned. Basically the idea is to enter an URL and a
transformation and the submission will be sent to each URL using the
proper transformation. We are also considering having a polling
method.
Cheers,
Waylon
···
On Thu, Sep 23, 2010 at 12:38 AM, magnusvxu wrote:
>
>
> On Sep 22, 7:08 pm, Mitch Sundt wrote:
>> Better unit tests are high on my agenda.
>
> Excellent!
>
>> The general idea is to support the upload of an .xsl transform definition.
>> This would operate on a basic xml rendering of the form, likely with all
>> nodes rendered, not just the relevant ones with data. The transformed
>> output would then be published to a downstream server.
>
> May I suggest having the option of assigning multiple downstream
> servers (perhaps with their own transformations?). One reason for this
> is of course to provide a fail-safe if one of the servers are offline,
> but another reason is to allow for mass distribution.
Alas, this feature was dropped. We have JSON and CSV publishers, and
filters that you can define to filter what is sent to those files. But we
do not support generic XSLT processing.
Mitch
···
On Thu, Sep 27, 2012 at 8:54 PM, wrote:
On Thursday, September 23, 2010 9:55:18 AM UTC+2, Waylon wrote:
That is planned. Basically the idea is to enter an URL and a
transformation and the submission will be sent to each URL using the
proper transformation. We are also considering having a polling
method.
The general idea is to support the upload of an .xsl transform
definition.
This would operate on a basic xml rendering of the form, likely with
all
nodes rendered, not just the relevant ones with data. The transformed
output would then be published to a downstream server.
May I suggest having the option of assigning multiple downstream
servers (perhaps with their own transformations?). One reason for this
is of course to provide a fail-safe if one of the servers are offline,
but another reason is to allow for mass distribution.
Hello, everyone. Realizing this is an old thread, I'm curious what became
of this? Is there a URL available for XSL transformations? I'm using a
third-party database tool I've developed and need the stylesheet or URL to
import the xml files. Many thanks in advance! - Michael
Urgh. I mean file exporters. The same functionality could be available in
publishers, but would require some customization.
···
On Thu, Oct 4, 2012 at 1:37 PM, Mitch S wrote:
Alas, this feature was dropped. We have JSON and CSV publishers, and
filters that you can define to filter what is sent to those files. But we
do not support generic XSLT processing.
On Thursday, September 23, 2010 9:55:18 AM UTC+2, Waylon wrote:
That is planned. Basically the idea is to enter an URL and a
transformation and the submission will be sent to each URL using the
proper transformation. We are also considering having a polling
method.
The general idea is to support the upload of an .xsl transform
definition.
This would operate on a basic xml rendering of the form, likely with
all
nodes rendered, not just the relevant ones with data. The
transformed
output would then be published to a downstream server.
May I suggest having the option of assigning multiple downstream
servers (perhaps with their own transformations?). One reason for this
is of course to provide a fail-safe if one of the servers are offline,
but another reason is to allow for mass distribution.
Hello, everyone. Realizing this is an old thread, I'm curious what became
of this? Is there a URL available for XSL transformations? I'm using a
third-party database tool I've developed and need the stylesheet or URL to
import the xml files. Many thanks in advance! - Michael