Thursday, June 03, 2004
Xindice / JavaScript bean binding
There's been a bit of a drought here, so I thought I would post. Ran into a bit of a roadblock design-wise -- I needed to settle on a way to do persistence of data. Hacking together Xindice update scripts / parse scripts for each and every bit of info you want to store is definitely not cool.
So what I ended up writing was a polymorphism-aware Javascript/XML binding serializer/deserializer. I can now just write Serializer.store(jsBean, "clients/123") to save data and jsBean = Deserialize.get("clients/123") to retrieve the data as an object of the correct type. No more ugly XUpdate/JXTemplateTransformed kludges. It generates XML that is *very* human readable/XPath-able, but is not a perfect rendition of the input data. For example, sparse arrays are not supported, so I need to treat arrays a bit more like vectors than arrays.
Pretty spiffy.
I'm really enjoying the quality of the SSJS integration with *everything* in Cocoon.
Also, the British Columbia Land Title Office handily replied to me saying, "Well, gee, yes, we *do* expect you to use Adobe Acrobat 6.0 and our own form templates." On the bright side, this is easy for me to do -- Adobe's FDF Toolkit has servlet integration, but how stupid is it that what should be a public service is committing to one vendor's proprietary, expensive standards?
Weooweoo. Anyway, off to fix the things that broke in the serializer changeover!
So what I ended up writing was a polymorphism-aware Javascript/XML binding serializer/deserializer. I can now just write Serializer.store(jsBean, "clients/123") to save data and jsBean = Deserialize.get("clients/123") to retrieve the data as an object of the correct type. No more ugly XUpdate/JXTemplateTransformed kludges. It generates XML that is *very* human readable/XPath-able, but is not a perfect rendition of the input data. For example, sparse arrays are not supported, so I need to treat arrays a bit more like vectors than arrays.
Pretty spiffy.
I'm really enjoying the quality of the SSJS integration with *everything* in Cocoon.
Also, the British Columbia Land Title Office handily replied to me saying, "Well, gee, yes, we *do* expect you to use Adobe Acrobat 6.0 and our own form templates." On the bright side, this is easy for me to do -- Adobe's FDF Toolkit has servlet integration, but how stupid is it that what should be a public service is committing to one vendor's proprietary, expensive standards?
Weooweoo. Anyway, off to fix the things that broke in the serializer changeover!
