-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel Rall <[EMAIL PROTECTED]> writes:
<snip>
> If this is a true concern, I suggest using wrappers/adaptors that
> present an API that you're more comfortable. That thin layer of code
> I would check into CVS, but then you have to maintain it if any of
> your generated APIs change. Personally, I have not found this to be
> an issue.
<snip>
I speak from experience on this issue. We were using Castor with Jetspeed.
With later revisions of Castor it was adding more and more methods that we did
*not* want to expose. It was to the point where it was even a security problem
(Portlets should not be able to destroy the web application or damage other
Portlets).
The Castor code was too thick and not well designed/organized. This isn't a
slight at the developers but it is still true. They were under a time
constraint to get it out the door and fighting against a constantly changing XML
Schema spec.
I took the bridge/proxy/adapter/ approach within Jetspeed but this was taking
more time than core Jetspeed development because the generated APIs are too
bad.
The XJay project uses an XSLT based approach. You write your object markup and
API in XMLSchema and then a stylesheet produces your packages/classes/methods.
If you want to add a few lines of code or a licensing agreement you just update
the LICENSE section or correct Javadoc (it is all fairly obvious if you know an
XML file format) and it will make the change without doing anything crazy to
your generator. This allows you to only check in the XSLT file to provide your
customizations and then produce your .java files when you deploy
I think it is the perfect solution but I haven't needed an XML or API generator
for a while so I haven't released 1.0.
<snip>
>
> > These questions were rhetorical. My point in the original e-mail was that
> > code generators can be "non-ideal". I wasn't making a logical argument against
> > them just that there was enough evidence to consider using the small parser we
> > already have. Considering the above issues (which don't exist currently) it IMO
> > isn't worth switching.
>
> I disagree. Most of your points are supported by an argument which
> apparently stems from having either little control over an inflexible
> generator or using less than ideal development practices (i.e. local
> edits).
... regardless... they are sometimes necessary. :( I wish they were'nt but I am
very pragmatic on this subject.
> Please don't take this as an attack, but I just don't see the
> how the "evidence" applies if a more flexible generator is used in
> conjunction with good practices. :)
I hope my above explanation helps. I agree with the more flexible generator
philosophy which is why I created XJay. I doubt that Antlr is as flexible
though. :)
Kevin
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
The secret to creativity is knowing how to hide your sources.
-Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE65fthAwM6xb2dfE0RAvqWAKDKZAiaSOHdRjEa8o58i9tkDGwy8wCgpdKU
XJUSkBebEP3KyQhuA76wOAI=
=9boM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
