RE: Standardized tools for date/number formatting etc., was Re: y ou-know-what

[Paul Smith <Pa...@lawlex.com.au>]

> Now that I wrote that, I realized that you can easily have 
> date comparisons
> in Velocity as well using
> 
> #if($date1.compareTo($date2) <any-comparison-operator> 0)

[snip]

Having had to deal with java.util.Date and java.util.Calendar in depth, I
can honestly say that the sanity of the person allowing any non-programmer
to even know that these classes existed should be questioned.  Honestly, as
a free-one to you Freemarker dev-guys (and Velocity as well), stay as far
away from supporting date's as you can.  The people that came up with the
time/date concept all those hundreds of years ago should the first against
the wall....

But again, regardless of that, I would try my very best to never design an
app that had basic data types (such as dates) to make their way into a
templating system.  It's much easier, _*IMHO*_ to provide details of the
model that can be queried by the template.  More work for us Java types,
sure, but that's fine with me, since it's usually us that have to help the
bloomin' template people to fix things in the template.  I'd rather just fix
my own code than you very much.

regards,

Paul Smith

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Standardized tools for date/number formatting etc., was Re: you-know-what

[Terry Steichen <te...@net-frame.com>]

Paul,

I think you're a bit to strong on these views. Just my $0.01 ;-)

Regards,

Terry

----- Original Message -----
From: "Paul Smith" <Pa...@lawlex.com.au>
Sent: Sunday, October 20, 2002 7:17 PM

> Having had to deal with java.util.Date and java.util.Calendar in depth, I
> can honestly say that the sanity of the person allowing any non-programmer
> to even know that these classes existed should be questioned.
==>Forgive my bluntness, but that statement suggests a certain amount of
technical aloofness.  On top of that, the idea of depending on user
ignorance to protect design integrity is sort of naive.  Date/Calendar
functions are complex, to be sure, but that is the way that Java has evolved
to handle this important functionality (so if we're going to use them, we
don't have a lot of choice).

> Honestly, as
> a free-one to you Freemarker dev-guys (and Velocity as well), stay as far
> away from supporting date's as you can.  The people that came up with the
> time/date concept all those hundreds of years ago should the first against
> the wall....
==>Forego date support and you have irrelevant technology - such support is
essential in many/most situations. (And, it is not hundreds of years old -
at least not the Java part.)

> But again, regardless of that, I would try my very best to never design an
> app that had basic data types (such as dates) to make their way into a
> templating system.  It's much easier, _*IMHO*_ to provide details of the
> model that can be queried by the template.  More work for us Java types,
> sure, but that's fine with me, since it's usually us that have to help the
> bloomin' template people to fix things in the template.  I'd rather just
fix
> my own code than you very much.
==>Many of those who have to design a presentation page don't have
readily-available 'Java types' at their beck and call.  They have a job to
do and need the flexibility to do it.  (And, it doesn't really require a
world-class programmer to do it, anyway.)





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Standardized tools for date/number formatting etc., was Re: you-know-what

[Attila Szegedi <sz...@freemail.hu>]

----- Original Message -----
From: "Paul Smith" <Pa...@lawlex.com.au>
To: "'Velocity Users List'" <ve...@jakarta.apache.org>
Sent: 2002. október 21. 1:17
Subject: RE: Standardized tools for date/number formatting etc., was Re:
you-know-what


>
> Having had to deal with java.util.Date and java.util.Calendar in depth, I
> can honestly say that the sanity of the person allowing any non-programmer
> to even know that these classes existed should be questioned.  Honestly,
as
> a free-one to you Freemarker dev-guys (and Velocity as well), stay as far
> away from supporting date's as you can.  The people that came up with the
> time/date concept all those hundreds of years ago should the first against
> the wall....
>

Well, I had my share of Calendar-handling miseries myself (favorite one
being months numbered 0 through 11...). However, in a view component you
mostly only want to *display* a date, and that's fortunately fairly
straightforward thing to implement in Java using the SimpleDateFormat
class...

> But again, regardless of that, I would try my very best to never design an
> app that had basic data types (such as dates) to make their way into a
> templating system.  It's much easier, _*IMHO*_ to provide details of the
> model that can be queried by the template.  More work for us Java types,
> sure, but that's fine with me, since it's usually us that have to help the
> bloomin' template people to fix things in the template.

Your template people are lucky to have such a supportive programmer backend,
but not all people are so fortunate. It's an all too common experience that
the designer gets stuck with its work and has to go to a programmer to beg
for "one more little tool" to be able to continue working. That's why at FM
our philosophy is shifted toward having features for empowering the
designer - we want to make the common functionality designers need readily
available for them, without making them dependant on the programmer. And we
don't think we're bloating the software (altough you're free to think
otherwise).

> I'd rather just fix my own code thank you very much.

Whatever suits you :-)

Cheers,
  Attila.

>
> regards,
>
> Paul Smith
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>