This paragraph grabbed my attention:
"The current-op attribute is nothing short of freaky, since you can read from it, and get a XML nodeset copy of the current operation document. But you can actually set it, and change the current event document on the fly. I am still wrapping my head around how to use this, but it is very freaky!"
Yes, indeed. It's freaky. But it also opens new perspectives. Let me explain...
As a developer I really really hate to write policies: it's slow in terms of development speed (click-hell in Designer), verbose (if you leave Designer and write policies in the XML editor), difficult to remember the tag names... Other people I talk with, share the same opinion: it would be a lot easier if one could just simply implement a Java Class and use that as a policy (the main drawback I see is non-trivial deployment: installing JARs).
XML Policies vs. (theoretical) Java Policies (these are my opinions and perhaps do not reflect other people's experiences :-))
- [+] It's a domain language. Anyone working with IdM understands it
- [+] No need for compiling, installing JARs
- [-] Slow development
- [-] Verbose (even for doing the simplest things)
- [-] Less flexible: restricted number of nouns/verbs
But now getting to the point of my comments:
As a rather newbie Novell IdM Developer I recently got my hands dirty on ECMAScript and (for me) it is a lot more convenient to work with. E.g. complex validation & transformation of attributes etc...
That one paragraph takes my ideas to a whole new level: why not simply write the whole policy in ECMAScript?
With ECMAScript you could get the best of the two worlds (Java and Policies):
- People with a developer background can get stuff done quick
- Much less verbose
- No need for compiling
- Easier testing (?)
- Less readable for non-developers (but imho non-technical people should keep their hands off policies)
- A Policy Rule that transforms the NDS Document to a String
- An ECMAScript call within a Policy Rule with the String as an argument for the function call. This script would then perform the following actions:
- Transform the serialized XML to JSON (BadgerFish convention , implementation: ruchirawageesha.blogspot.com/.../xml-to-badgerfish-converter-in.html)
- Call an ECMA function containing the policy logic
- Transform JSON back to serialized XML
- Return the serialized XML
- A Policy Rule that replaces the current operation with the returned (serialized) XML. This is what you were talking about, I think
Good or bad idea? Am I missing something? Other comments?