Part of this new design for HiveMind is a change to implementation factory parameters. These will also be a schema ... basically, each implementation factory will have a kind of implicit configuration extension point to define its parameters.
This is important, because all the module deployment descriptor tags related to setting of properties are going to fade away; if they come back, they will be reimplemented as specific to a implementation factory service.
I'm actually struggling a little bit with the idea of processing the XML of configuration contributions (and factory service parameters). I'll be emulating a subset of W3C schema give-or-take, and dealing with that is a bit of work. Just need a little block of time to think about how to approach it properly, with all the kinds of variations that are possible (in terms of sequences, choices and setting bounds on the number of occurances for an element, choice or sequence). It's a little frustrating because its certainly a problem that has been solved repeatedly by others ... and, I can look at their code, but it may just be eaiser to hash it out myself.
No comments:
Post a Comment
Please note that this is not a support forum for Tapestry. Requests for help will be deleted. Please subscribe to the Tapestry user mailing list if you are in need of support, or contact me directly for professional (for pay) support.
Spammers: Don't bother. I delete your comments and it's a waste of time for both of us. 垃圾邮件发送者：不要打扰。我删除您的评论和它的时间对我们双方的浪费