[stringtemplate-interest] ST Half-in or All-in? Pragmatism & Portability.

[Zenaan Harkness]

On Tue, Oct 20, 2009 at 09:25:14AM -0700, Joseph Grace wrote:
> I was just reading Harry's post suggesting a variety of ST operators, and it
> brought the discussion back to basics:  which operators are commonly needed.
>  He lists some useful operators, but it occurred to me that (with
> conditionals) there are any number (combinatoric) of ways to combine them,
> depending on need.  So customization is essential (no surprise).  Custom

Operator customization, is one technique to handle explosion of
operators.

Orthogonal operators, is another.

Most strictly, 'if' is a violation of 'no logic in the view'.
It's a concession of sorts.

Back to orthogonal operators, I'm thinking:
<if(isempty(strip(attribute)))>
<if(exists(attribute))>

It's looking a little lisp like. What I'm thinking is that if any
data processing (DP) is required to reduce the data to a point where
sensible boolean values can be obtained, then that DP should be kept
separate, completely separate, from the conditional test facility.

Functional orthogonality may look more verbose, but conceptually it
is much cleaner.

For the example <if(isempty(strip(attribute)))>, the only indeterminate
now is 'strip'.
   -  'if' must have a boolean value to work at all.
      -  unfortunately this would backwards incompatible,
         but would simplify/ purify ST
      -  for 'if' on a possibly null attribute, implies
         a functional language extension like lisp list processing

   -  isempty is self explanatory

   -  isnull becomes small and self contained complement of isempty

   -  <if(nullorempty(strip(attribute)))> would round out these
      functions


> data handling is a recurring, major issue these operators could address
> using ST across applications, via user hooks for their own custom needs.  ST

DP is a recurring, major issue common-lisp could address across
applications  :)


...
> I realized there's really a second concern intermingled with "custom data",
> and that's the whole issue of keeping ST portable across languages.  ST data
> conversion is not something that is always custom.  Each language may

ST is mandated with _not_ providing for DP/ data-conversion.

> present its own special needs, but many problems will be generic conversion
> problems shaping, converting, tweaking, tagging data for ST.  ST could
> probably use a portable library (a la Zen's questions, above) to handle
> standard data conversions (et al.) into ST.  ("st.*" and "st.<lang>.*").  An

There is certainly room for a complement to ST. Unfortunately given that
this layer would not be ST, it would require either a completely
alternative language like lisp, or an implementation/ library in each
"ST host" language.

> ST standard portable library could help with data conversions, capture
> expertise for reuse, and lend a hand with language portability of ST.  ST

I think what you mean to say is not 'language portability of ST' (ST
works just fine in each host language) but rather 'language-specific
data processing needs would be able to be performed in ST, yes?

> support could also foster more community among users of specific languages
> with ST, through language specific support ("st.<lang>.*").  The idea would
> be to make ST portable to many languages, by treating those languages and
> data with first-class citizenship.

ST treats no language as a second-class citizen. It has been stated
a few times, eg in this discussion, that this is the case, but I'm
pretty sure it's just not the case. Doesn't make sense to me.

> Pragmatism & Portability.  Those are really two separate issues.

Agreed. ST templates are currently highly portable. It's goodness.

> I think the key idea is that data migration into ST can be difficult from
> unorthodox languages or applications.

Actually, it's not.  It's really easy to push data into ST.

In my imagination, I can imagine that an unorthodox language for which
there are some difficulties processing the data into a suitable format
for ST, then that language is going to have difficulties processing
data into _any_ suitable format.

But this is a hypothetical anyway...


> The key to making ST work in many situations is ST Data Generosity,
> the idea that ST should be generous about accepting data. However,
> that can be a can of worms.

ST provides generous acceptance.

What ST does not provide is anything remotely approaching
'comprehensive DP facilities'.

And _that_ is by design. It's not a DP tool.
But it _is_ the best view templating tool in existence. Period.

...
> Adding data conversion + hosting support would expand ST would become
> a two-part toolset.  1.  ST the functional language.  2.  ST data
> conversion and hosting tools.

Totally agree. Would be a two part toolset.

> That would be new focus for ST and ST community, and would require
> dropping the insular attitude and adopting an open attitude toward
> data as a first-class citizen in the ST space.
...
> I'm not sure if the ST community is ready or even wants such success.  One
...
> expansion may be seen as a threat to the community or otherwise undesirable.

Furfy! The hide of you!  :)  :)

It would require only development of the second of the two tools you
refer to - the DP tool. I find Java just fine, myself. But I do imagine
something lisp like (ahh, perhaps lisp <shrug>) could provide some
useful benefits depending on project.

best
zen

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