On Tue, 4 Dec 2001 06:31, Paul Hammant wrote: > An idea... ...snip... That is very close to our original design - originally XML was meant to be only one option (and something that is used only rarely).
However pure xml files have several advantages. The essential one being that you don't have to construct a classloader and resolve all the classes to just read the infos. It would also be cumbersome to represent things like XSchema in .java files (when we eventually get around to implementing config validation). Besides it makes for a faster dev cycle based on experience with BeanInfos (what this spec was originally based upon) and articles like that declative vs procedural one. > The though is that as XML blocks go, the xinfo is fairly mundane. If > these were Java classes, they could be more visible to those perusing > the Java source of a thing. Half of our Phoenix newbie issues are > because people are not keeping their xinfo files in step with their > assembly.xml files. With advanced IDEs like Intellij it will hopefully > ripple changes through to this BlockDef class as people iteratively > rename their chosen demo/pdk starting point to become their server app. That is a problem. There was a few things we can do to alleviate this issue. We could allow some sort of automagic creation of .xinfo files from javadocs of specified blocks. This would help keep cost of maaintaining them down a bit. We could also (finally) create ant tasks to run the verifier over .sars before they are deployed. This should give a good indication whether the format is valid. We could also create DTDs for the different formats as appropriate and interpret the files with that mind. I could also write a "Block File Archive Verifier" that verified the format of all the Blocks info files, and the relationship beteen services inside the jar, the manifest entrtys and so forth. Thoughts? -- Cheers, Pete -------------------------------------------------- Logic: The art of being wrong with confidence... -------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>