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
| [reply] |
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.
| [reply] |