One more for the evening. There is a DOM API hiding in Spring already. So, the big problem here is how Spring conceptualized the placeholders. In the Spring model, placeholders resolve against \values/, not against XML. You could get your bean definition from a property file, or via carrier pigeons, and still expand placeholders. Essentially, what we end up looking for here is our own XML placeholder mechanism. Would it be a good thing for it to use the same syntax as Spring? In any case, we'd need our own class to walk a DOM and perform substitutions, and we'd have to be clear on the semantics.
On Sun, Sep 14, 2008 at 8:49 PM, Benson Margulies <[EMAIL PROTECTED]> wrote: > I'm not entirely making sense here. For this to work, we'd need our > own parallel implementation of the placeholder class to do all the > substitutions in the DOM tree after reading in and before validating + > defining the beans. > > On Sun, Sep 14, 2008 at 8:45 PM, Benson Margulies <[EMAIL PROTECTED]> wrote: >> I see the path. Instead of XmlBeanDefinitionReader from Spring, we'd >> need our own that could start from DOM. >> >> We could parse, then use the Xerces Validator against a DOMSource, >> then load up them beans using a DOMBeanDefinitionReader. >> >> Anyone suffering from terminal prospective nausea? >> >> On Sun, Sep 14, 2008 at 6:23 PM, Christian Schneider >> <[EMAIL PROTECTED]> wrote: >>> Benson Margulies schrieb: >>>> >>>> Ideally, IMHO, this discussion should be happening on a Spring >>>> discussion board: could Spring defer validation to post-parse? >>>> >>> >>> I have opened a thread on the spring forum to ask about this: >>> http://forum.springframework.org/showthread.php?p=201595#post201595 >>> >>> Let´s see if we get some advice there. >>> >>> Greetings >>> >>> Christian >>> >>> >>> -- >>> >>> Christian Schneider >>> --- >>> http://www.liquid-reality.de >>> >>> >> >
