TYPO3.Fluid

Hi,
glad both of you found the time to have a look; Bastian, the concrete use case is, hopefully, described in the Fluid snippet above; I'll try to break it down. The sample reads

1<f:if condition="{model.date} < {f:format.date(date: 'now', asObject: 'true')}">
2The date is due.
3</f:if>

model.date is itself of type \DateTime, as usual. f:format.date could take 'now' as date, resulting to the current timestamp. With my "patch idea" applied, the ViewHelper will return \DateTime representing now. With the above example than, you're able to in-line check whether a date is in the past, for example. Because PHP is capable of comparing two \DateTime objects just with the < or > operator (also see link above).

So, that's the use case. Those months ago, Sebastian generally liked the idea (see http://www.rvantwisk.nl/flow3-irc-log/2012/january/11.html 12:03 ff, the Internet doesn't forget ;-) but I also are not absolutely comfortable because of the Flag argument style...

Adrian Föder wrote:

Bastian, the concrete use case is, hopefully, described in the Fluid snippet above; [...]

Sorry, missed that one.
IMO the nicest way to get around this in your very case would be an additional getter in the model like

1public function isDue() {
2    return $this->date < new \DateTime();
3}

And then you could write

1<f:if condition="{model.due}">
2The date is due.
3</f:if>

• less domain logic in the view
• more domain logic in the model

That way, if you need to change the way a due date is calculated (for example if [model] is due as long as it's on the same day) you only need to adjust it at one place.

If you can't change the model for some reason, I would still prefer to set the due date in the controller:

1$this->view->assign('dueDate', new \DateTime());

So, that's the use case. Those months ago, Sebastian generally liked the idea [...]

Sometimes even Sebastian is wrong. Just kidding ;) Let me know if you are not satisfied by the above solution or come accross another use case!

Hi Bastian,
I just checked my actual use case, and it's actually just one occurrence where extending the model would be sufficient and fine.

The question is: in my opinion, PHP's possibility to compare dates against each other just with the comparison operator AND the fact that this is directly usable with the IfViewHelper, really begs to be used.
My use case isn't the question here, the question is if it's imaginable to be used in many other cases.

That's just meant as an additional trigger to gamble around with the idea a bit; I'm absolutely fine and won't be latched ;-) if we decide to literally abandon it.

Adrian Föder wrote:

Hi Adrian,

I just checked my actual use case, and it's actually just one
occurrence where extending the model would be sufficient and fine.

Thats great!

The question is: in my opinion, PHP's possibility to compare dates against each other
just with the comparison operator AND the fact that this is directly usable with
the IfViewHelper, really begs to be used.

Right, but that's the case isn't it?

1 <f:if condition="{model.date} < {dueDate}">

works, if {dueDate} is a \DateTime, too.

My use case isn't the question here

I don't think so. In order to avoid a "YAGNI mess" we should back up every new feature with a realistic use case.
I'm not saying that there is none for this feature - but as long as we don't know it we shouldn't introduce the feature in my opinion.

I'm absolutely fine and won't be latched ;-)

Ok, great. Thanks for this ;)
I would now go ahead and abandon the change. We'll be able to restore it anytime if we come accross a real need!