[stringtemplate-interest] On Pragmatism Violating Purity For The Win

[Zenaan Harkness]

On Mon, Oct 19, 2009 at 08:54:50PM -0700, Joseph Grace wrote:
> *Zenaan Harkness* wrote on *Mon Oct 19 19:27:25 PDT 2009:*
...
> > [and later]  2) And I can say that native.* looks horribly slippery.
> 
> Ack to both. No disagreement here. However, this slippery slope already
> exists in the form of formatters, correct? And people use it from time to
> time for just this purpose, e.g., for "Truncate string" in java:
> 
> http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001954.html

String processing to massage it into a format suitable for output.
Eg line wrapping.
Had to handle this myself.
Wrote a formatter/ renderer which did the processing as I required.

I agree there is an argument for more comprehensive ST formatting
facilities.

On the other hand, if that 'data [format] processing' capability can be
used to process data, as opposed to data format, then people will
process data.

Template engines that can process data are plentiful. Velocity is one
I've used just a little, for example. In fact, just about every other
template engine out there provides for this :)

I've been away from my programming + ST, for most of this year, so
I'm sorry I can't provide more concrete examples right now.

Perhaps if it is limited to String munging of various sorts, then
we don't go into "data processing" (DP) territory.


Thank you for referring to the emails.
I shall speak to the two other emails you raise:

> http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001921.html

Here, although the author speaks of 'slight compromise', the proposal
put - 'expression handler' - is anything but slight. It would indeed
turn ST into a DP language, for those who want that. We want to keep ST
from being a DP language. For example, the 'when really needed', is
never. If DP is really needed, a separate layer will need to be
implemented. The complexities of arbitrary DP is ultimately "a
programming language".
That's a different problem than ST solves.


> http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001939.html

Thanks for referring to the email where Ter answers the questions
raised.

And at the last point (""This zoo contains $zebras.Count$
$if(rest(zebras))$ zebras $else$  zebra $endif$ I’m wondering if even
simple logic like this doesn’t belong in the  view""), Ter points out
again the slippery slope of working in a template with values (numbers)
as opposed to the list processing of 'rest' 'first' etc.

> These issues would be perfect candidates for "model.*" hook customization.
> If a "model.*" hook existed, users could develop such features as needed,
> and then migrate them into common ST usage only after being proven (or
> never). Pressure to change ST would be relieved, so core ST could remain

There's actually no significant pressure to change ST to become a DP
language. Although the question arises on occasion, in most (all?) cases
of an actual problem presented, a relatively straightforward solution
has been presented. Perhaps most telling, we see reports on the list
here and there of gratitude and "ahah" from time to time.

Strict separation of concerns really does make systems easier.

> true to its purity roots. Yet ST would generously accept any discernible
> input [Robustness Principle] and become a genuinely good citizen even for
> legacy or complex models.

This statement unfortunately implies that ST is not a good citizen in
such situations.

I have to cry straw-man on this one. Examples, brother. Examples :)


> IMO, ST needs to be a good citizen

It is.

> and handle glue issues

It does, to a degree.

> even if they're
> not strictly ST's problem. I believe ST perenially loses converts due to the
> purist "Do it in the model!" attitude. By adopting a more accomodating
> attitude of
> 
> "Do it in model.*!"

You might enjoy a couple of emails regarding MVC-recursion, 2009-07-23.

For full flexibility, say an intertwining of view with custom data
processing stuff, you may want to separate out the DP stuff into a
View-Model (as opposed to Data-Model class, eg).

best
zen

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.