On Thu, Sep 3, 2009 at 01:53, Jess Holle<je...@ptc.com> wrote:
>
> You don't embed this sort of thing. You use getResourceAsStream() and a
> separate file along with MessageFormat or such to perform substitutions
> of live data if need be.
>
> Plain and simple.
Yup. Good idea. So you've now maximally separated definition from
usage, so that when editing one you lose the context of the other. For
even better effect, use a maven project layout and have your .sql file
buried under src/main/resouces while the java code that loads it,
substitutes in variables and calls the data base is in src/main/java.
For extra masochism you could embed your SQL fragments in a nest of
angle brackets.
Sorry, that was harsh, but there is a trade-off being made here which
should be considered.
*waaaaay* back in the day, I rewrote a tool to generate Java classes
specific to our business object framework from UML diagrams in
Rational Rose (which had a truly demented almost-clone of VBA
embedded).
The original tool was a hideous sprawl of mile-long print statements
containing a heady mixture of literal string fragments and (mostly
global) variables. It was unreadable.
The first thing I did was write a *very simple* templating system, so
I could put the java code fragments into templates containing named
"substitution points" (i.e. variables, think "${classname}"). Then the
code generator would load up the template by name, perform
substitutions on it by providing name/value pairs and then finally
output the result.
I quickly found that this was tedious, because the code was referring
to names (of substitution points and templates) that I wasn't seeing
while coding. I finally ended just embedding the templates in the
program as comments. (The first thing the script did when starting up,
was load the templates by reading through its own source. Sick, but it
worked well.) That way they were declared close to their point of use
and one could easily refer back and forth while developing and
modifying the program.
Though unconventional, this solution turned out to be a
maintainability win, almost entirely due to the fact that I was able
to keep use and declaration close to each other.
> This also allows the IDE to do easily appropriate things for a .sql file
> or the like.
>
> [In the XML sphere I'm all for sticking SVG, XSL FO, etc, directly
> inside an XHTML document -- but this whole approach seems to be dying on
> the vine there, even though the grammar is the same throughout all of
> these.]
Yea, you'd think that the XML vocabularies out there would be a
natural fit for some kind of literate programming approach, like an
XHTML document which both explains and embeds an XSD along with
tooling to generate human-readable XHTML and machine-readable XSD from
the combined doc.
But, sadly, not so much of that going on.
// Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
