dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

I want to do the following:

Based on a given value in a table row, set the background color. I want to compare that value to the current day and, if it's after today, set it to green, otherwise set it to red.

I want to do this in the template itself, so I thought I would use the Date plugin. Now, I'm not a master of the date modules, but Date::Calc::Object looks like it will do what I want with its overloaded operators, but I cannot seem to find a way of having the Date plugin to TT use it.

Date::Calc doesn't have a date comparison operator and Date::Manip doesn't look like it does.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Replies are listed 'Best First'.
Re: Template Toolkit and Date plugin
by adrianh (Chancellor) on Apr 30, 2004 at 16:06 UTC
Re: Template Toolkit and Date plugin
by perrin (Chancellor) on Apr 30, 2004 at 17:26 UTC
    Two things:

    • You can pass any object to TT and call methods on it, so nothing is stopping you from passing in a Date::Calc::Object instance.
    • Calculating in the template is a bad design, in my opinion. I would calculate it in the perl code and pass in a boolean to the template called "date_is_future" that you use for setting the color.
      I wanted to avoid the H::T syndrome of passing in a bazillion booleans, so that's why I'm looking for an alternative to the date_is_future param.

      The second thing is that I wanted to keep all display-related logic in the template. Passing in the Date::Calc::Object instance into the template for each row is a good idea, but I wanted to have the template compare it to Today() and do the logic there.

      The basic reason is that, eventually, I want to have a $preferences object that I pass in to the template and the template figures out all the display concerns.

      Essentially, I view MVC as thus - the language that deals with the displaying (TT, in this case) should handle all logic that can be seen as display-related. Does that make sense?

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        the language that deals with the displaying (TT, in this case) should handle all logic that can be seen as display-related. Does that make sense?

        Yes, but I think you're confusing the issue. Finding out whether or not a date is after today is NOT display-related. A display-related issue would be formatting a date, or splitting an array into two columns.

        "Is this date in the future?" is something you should be able to ask your data model. If adding a boolean feels too artificial to you, and the date object you've chosen has no "is_future" sort of method, then I'd suggest making a wrapper object you can use in your application that extends the date object to answer this question. Then just call it from TT.