> From: Jim Cook [mailto:jimcook@xxxxxxxxxxxxx]
> XMLHttpRequest works nicely for heavy weight calculations and data
> retrieval, but for simple calculations, the overhead doesn't
> seem worth it.
> Do we really want a round trip to the server to do a simple
> multiplication?
No. I was assuming the calculation was volatile enough to make it worth
applying the DRY/OAOO principle. If the calculation is dirt simple and
not likely to change, then no. A DP solution is adequate. If the
calculation is not simple, or is likely to change often, then applying
engineering resources to removing duplication will give payback. Here a
behavioral OO solution begins to give payback.
> But for a simple calculation <input value> * <constant> what does a
> javascript object provide buy us over the simple calculation?
It buys us decoupling. Again, it is an engineering choice of waying the
benefits and costs. If the complexity of decoupling doesn't payback,
then don't do it.
> I did think about the model object spitting out the
> javascript code that I would imbed in the html page, but
> it seems like I am starting to put view logic in my model.
Actually, its looks to me as if you have model logic in your view. The
reason is there is because the architecture of the web makes round
tripping to the model too expensive. More engineering cost/benefit
decisions here.
> So the lesser of two evils seems to me that I use the
> constant as the constant has a greater probability of being
> changed whereas the simple calculation doesn't.
Excellent. You weighed the costs and came to a conclusion. That's
exactly what we as developers must do.
--
-- Jim Weirich / Compuware
-- Strategic Infrastructure Development
-- http://fwp-st.fmr.com/sid
|