Re: filter thoughts

yeh my implementation suggestion could use some work, I had thought 
perhaps just a simple <filter> element/action handler as you say so that 
chaining becomes simple to define, extra options are easier to include, 
and readability is maintained.

Its nice to get some support :)
Cheers



mark.birbeck@x-port.net wrote:
> Jason,
> 
> I think this is a great idea, as I'm sure will many who read it.
> 
> I had a slightly different take on how to add it to XForms though.
> 
> There have been some additions to XForms lately to give the author
> access to data at various stages of processing--just before
> submission, after submission errors, and so on. So, the thing to do
> would be to allow an action handler that performs a transformation on
> 
> On 06/11/06, Jason <jeacott@hardlight.com.au> wrote:
>>
>> Hi all,
>>     just a thought, but is there any reason that in a submission element
>> there couldn't be attributes like:
>> outfilter="some-bind-or-embeddedxsltref or url"
>> infilter="some-bind-or-embeddedxsltref or url"
>> ?
>> or even outfilterchain=""!
>>
>> it would make submission processing far more powerful and could provide
>> much simpler ways to reuse the same form for different datasets.
>> Wouldnt it solve a lot of the submission issues related to webservices
>> by enabling a subset of any instance data to be aquired or saved for/to
>> whatever format without re-tailoring an entire form with custom bits of
>> essentially hardcoded data. XSLT can be built smart to dynamically
>> assess the input XML and select its own appropriate output, so that
>> loading data from various different known sources becomes much simpler.
>> Imagine a single Xform that could load and submit from a whole variety
>> of search engines for example (obviously the search engines would need
>> to actually support XML output in order to facilitate loading of their
>> data in our form).
>> I find myself doing this kind of thing serverside all the time in order
>> to support my xforms anyway. I use it to ensure any missing elements and
>> attributes exist for my forms, and to transform data to/from various
>> formats including making nice human readable email submissions! Can
>> anyone else see value in supporting this directly in the form?
>>
>> it doesn't even need to restrict itself to xslt - let the filter itself
>> define its own language, xslt, javascript, anything.
>>
>> perhaps this is already possible with events and xslt in the container
>> doc? not sure about that.
>>
>> any thoughts?
>>
>> Jason.
>>
>>
>>
> 
>

Received on Monday, 6 November 2006 15:29:04 UTC