This one time, at band camp, Daniel Shriver said:
DS>
DS>
DS>-----Original Message-----
DS>From: tek1 [mailto:[EMAIL PROTECTED]]
DS>Sent: Wednesday, February 05, 2003 3:12 PM
DS>To: [EMAIL PROTECTED]
DS>Subject: Re: [castor-dev] Code for auto-generating CUSTOM castor mapping
DS>files
DS>
DS>1)
DS>>it is possible with xdoclet to generate a mapping with no @tags in the
DS>>source, if you write the module as such.
DS>
DS>Ignorant question: I only found info talking about @tags. How do I setup
DS>xdoclet to work without such tags (I just need some simple examples)?
DS>
DS>2)
DS>>however, with no @tags in the source, there is no way for the generator to
DS>>know which fields should have which attributes (i.e. which fields should be
DS>
DS>>NOT NULL and which can allow nulls)
DS>
DS>As of now, this issue is of no concern to me. I might have some trouble
DS>with it in the future but it is a very small concern compared to what I'm
DS>currently facing.
DS>
DS>3)
DS>>also, without the @tags, there is no way to
DS>>have database table and table field names that are different from the class
DS>
DS>>and class's fields.
DS>
DS>Again, this isn't currently a concern of mine. And again, if and when it
DS>becomes an issue, I see workarounds on it being much less painful than the
DS>current problem.
DS>
DS>4)
DS>>in other words, java itself needs to be able to describe *everything* that
DS>>needs to appear in the mapping.xml file. that is not possible and thus the
DS>
DS>>raison d'etre for xdoclet.
DS>
DS>Now you lost me. I read statement 1) as "What you want to do is currently
DS>possible with xdoclet" and statement 4) as "What you want to do is
DS>impossible". I know Castor itself will generate mappings if you don't
DS>provide them, BUT this solution WILL NOT work for me as Castor utilizes a
DS>rather simple heuristic (which my codebase will grievously break).
DS>
DS>Does xdoclet intelligently parse classes without the use of @tag metadata?
DS>Can it determine the serializable fields, getters and setters for those
DS>fields (again without metadata)?
DS>
DS>Also, one other member (replying to this thread) seemed to indicate xdoclets
DS>castor mapping abilities were "broken". I'd like some more info on what
DS>exactly was "broken" and what version we are talking about.
DS>
DS>FYI: I also submitted a "longshot" RFE to Sun on Java. Basically I'd like
DS>some way of asking the compiler (or something using code common to the
DS>compiler) for details on a class. The way I see it the java compiler is
DS>going to be the "best" solution for parsing .java classes (it already has to
DS>do that, it already needs to know more than anything else, it is also more
DS>used and tested than any other component). Likewise it will have all the
DS>info neatly packed away in datastructures (albeit native ones, but what I
DS>want is a java layer API to this). There are MANY uses for such a
DS>capability (and it could become a powerful feature of the language), not
DS>just aiding in intelligent serialization on the fly.... If you'd like to
DS>see this capability too look in a few weeks for the RFE (if they post it)
DS>and vote for it.
This is *exactlly* what parser generators like JavaCC and ANTLR provide -
the ability to parse a file, recognize pieces of that file based on the
rules you write and act on those recognitions. See the following URLs
for more info:
http://www.webgain.com/products/java_cc/
http://www.antlr.org/
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
