Tim,

oh my god - the "right MVC pattern" - thing is back! :) I don't
want to bring up that discussion again (I am sure you don't want
to either :). My short comment: I cannot imagine that coping with
*Numbers* is a bad design. BTW, it was agreed (including Geir)
that the number support should be there.

But I don't want to dig into particular problems/features and
things, but I want to see the project alive again. If the
first thing that will be done is number support ("for me" :) or
whitespace handling ("for you" :) or none of them ("for the mvc
purists":) doesn't matter.

Peter



> -----Original Message-----
> From: Tim Colson [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 03, 2003 9:07 PM
> To: 'Velocity Developers List'
> Subject: RE: Running total (more on: Is there a need for 
> further development) - or not
> 
> 
> > I think the following thread (which is currently happening
> > on the user list) demonstrates that there are some _basic_ 
> > things missing. 
> I disagree. I think this _particular_ thread demonstrates a 
> potentially bad design decision and can be handled without a 
> core change to Velocity.
> 
> ---
> The discussion usually goes round and round on this. I think 
> most of us have seen/participated in it at some point.
> 
> User says, "Velocity is missing the feature that will let me 
> do [math], I need this:"
>   #set($prior_payment_amt_total = $prior_payment_amt_total + 
> $row.prior_payment_amount)##
> 
> Developer 1 says, "You're RIGHT! We need to add [insert 
> feature here, namely math] to Velocity!"
> 
> Developer 2 says, "Whoa. You're WRONG! This can be done in 
> the backend and keep the template simple, like so:" 
> ctx.put("prior_payment_amt_total", PaymentBean.getTotalPayment() )
> 
> Developer 1 then says, "Oh c'mon! Stop your MVC preaching! 
> There are some things that SHOULD be calculated in the View. 
> Errr, well... maybe not THIS example, cause it's bad, I 
> admit. But surely I can come up with good examples where it's 
> needed. Here is one: a Designer wants to calculate how many 
> pixels for 'foo', THAT should be in the view and would be a float!"
> 
> Developer 2 then says, "Regardless of MVC, my point is that 
> Velocity doesn't NEED to add this feature, as it can be 
> accomplished in other ways. In fact, adding Integer support 
> might have been a BAD idea in the first place, next thing you 
> know Developers will want polynomial factoring and 
> differential equations in the core!"
> 
> My opinion these days is that I'd like to see Velocity REMOVE 
> the number support from the core and put it into a tool. 
> Radical idea, eh? <grin> 
> 
> That would without a doubt prevent what I _personally_ feel 
> are silly things like business calculations in the View layer 
> of our webapps. :-)
> 
> But that would also upset a lot of folks who are used to the 
> functionality and don't share my perhaps goofy opinion. So no 
> problem, I live with existing Velocity, but encourage my 
> designers NOT to use math features. Everybody can be happy. :-)
> 
> ----
> Summary of the Summary: 
> With fairly equal camps of Developer 1 and 2, each believing 
> they are correct, there is no clear mandate for change. So 
> some of the inactivity, I believe, has been because there is 
> no clear mandate from a MAJORITY of the developers who 
> actually use Velocity. 
> 
> But hey, while I'm not for the math stuff... I AM on board 
> with parts of the many whitespace and escaping proposals. 
> Just not sure which parts these days. ;-)
> 
> Just my two cents,
> Timo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to