> From: Edward Sumerfield [mailto:esumerfd@xxxxxxxxxxx]
> Agreed, but in this situation we are looking at modeling
> across languages so
> we have the choice between duplication or bugs.
I think the code generation is great, but the problem it solves is the
duplication of constants across languages and really doesn't address the
fundamental question "Should we use constants or not". In fact, I
thought Jim Cook was saying that the constant wasn't duplicated because
he generated the javascript constant from the value of the Java constant
(and if he wasn't saying that, it should be a fairly easy thing to do).
The problem is not the duplication of the constant across the language
boundary (which is easily solved), but the duplicate of the calculation
logic across the languages.
One possible solution is to write a translator that translates the java
formula to java script. My guess is that the complexity of the solution
would outweigh the benefits of OAOO[1].
Or, you could write a web service that calculates the answer (using your
java code) and then call that service from javascript. I think that's
what the XHtmlRequest stuff is for, but I've never done it myself.
The key is that by providing a javascript object with behavior (e.g.
calculate this formula) rather than a structure of data values (e.g.
rates and hours), you decouple the rest of the code from your decisions
about local implementation, code generation, or web services.
--
-- Jim Weirich / Compuware
-- Strategic Infrastructure Development
[1] OAOO = Once and Only Once ... the battle cry of XP developers
everywhere. Also known as DRY[2].
[2] DRY = Don't Repeat Yourself.
|