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]