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]>

Reply via email to