-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Sanders <[EMAIL PROTECTED]> writes:
<snip>
> I have written something close to what Torque does over in Turbine land, except
> that it generates SQL schema, Java objects, and the webapp to access said
> objects. I can tell you that it *is* complicated, but it is maintainable. The
> minute I catch myself editing the output, I ask myself 'Why?', and then modify
> the generator. The only valid use case for modifying the generated code is to
> test something before you put it back into the generator.
This only applies to a small minority of users (a better name would be
developers).
The real problem comes in when you need to modify something that is project
specific. This can't be folded back into the generator :(
> >>> if you put them in CVS then every time you change the API generator you get
> >>> redundant CVS commit messages
> >> Putting generated code in CVS is never anything more than a stop gap
> >> measure. The only time that I have ever done this was before the
> >> generator was integrated into the build system (as soon as that was
> >> done, bye bye generated code).
> > There can be a log of situations where you don't want it in CVS. If you need
> > to
> > make any changes though, remove methods, etc you have to commit this to CVS.
>
> Modify the generator. If you created it, and you have the source, you can
> modify it, no?
Technically but it isn't realistic to expect everyone to modify their code
generators. I don't have the bandwidth to hack on every tool I use. :(
<snip>
<snip>
> There is generally a lot more context than just 'something'. Generated JavaDoc
> can be just fine as opposed to no JavaDoc.
seems kind of redundant though.
JXR would take the XML Schema annotation and use that for Javadoc :)
> > BTW. 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.
>
> The only thing that I see here is that Jeff has the itch, and I say let him
> scratch. If he ends up with something better, faster, more extensible, so be
> it. If not, he gets the education for trying. It is as simple as that.
<snip>
Yeah. +1. I hope it didn't seem like discouragement. I don't think my
original e-mail implied that at all.
I think that the best solution for the JXR2 stuff, since I wrote the JXR1 stuff
and have a decent perspective, is to keep the current parser (it is simple,
clean, small) and just have it generate SAX events. This way we can have the
best of both worlds. A small fast HTML output engine and a more robuts and open
XML output so that we can do XSLT (not that the latter will be slower).
Kevin
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Cell: 408-910-6145 URL: http://relativity.yi.org ICQ: 73488596
Build a better mouse trap... and you'll be sued by someone who patented mouse
trapping devices in 1993.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE65fdhAwM6xb2dfE0RAl2bAKCnaRvtinbygpF2jCxMUMyrWeOXQACeJeRd
RDIZsHE9lNk1JFIM0G82R6Q=
=t1lB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
