On Thu, 6 Jan 2005 15:37:18 -0700, Tim Colson <[EMAIL PROTECTED]> wrote:
That's a clever idea for a shortcut.
Agree it's interesting, but I'm unsure it will be easy to agree on what constitutes "true/false" to trigger the #else. Plus, well, the paradigm is a bit wacky. I mean, even perl doesn't have an 'else' clause for a loop construct. <grin>
as for what would trigger the #else, i should think that is obvious. the #else statement is rendered anytime the #foreach doesn't render
its innards for whatever reason. i think we can all very easily agree
on that!
Exactly. The thing is trivial to read and understand - principle of least surprise: the else is evaluated precisely whenever the internals are not. Both the result set being empty or being null will prevent the internals from evaluating.
OK, it would be *nice* to have a trinary:
foreach ... but-if-it-was-null ... but-if-it-was-empty
but there is no *obvious* simple trivial way to do that off the top of my head, and the need to differentiate between "result was null" and "result was empty" is a lot less common than just needing to detect either.
In fact, the problem comes about partly because you HAVE to test both just in order to test emptinees, otherwise you hit a nullpointerexception (IIRC), so this is about simplifying a very common process in several ways down to one that is both simple AND trivially readable.
The rule for true/false smells like business logic... which I personally
What's business logic about it?
May I introduce you to "intelligent" views: they tell you when they were fed invalid data. That's all that's happening here - you're not going to branch off and render a completely different Database in the else (well, not normally :)).
All you're doing is popping up a nice-n-friendly "no results found" message (usually). I think if you had this problem, of the silently vanishing lists that don't even appear as empty lists because HTML silently non-renders empty lists then you would understand a bit better: it is a major problem to have something not appear.
It's OK with tables, where you've got the header row even with 0 results. But it's still much nicer to avoid writing out all the code, several times, in every single template.
The backend can worry about the goofiness of java .length/size/size() and
Only if you believe that every single VTL user should re-invent the same wheel on every project - when it's a wheel that
- we know many of us are going to need - we all want the same algorithm for
no?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
