<span class="Apple-style-span" style="font-family: Times; font-size: medium; "><b><div><span class="Apple-style-span" style="font-weight: normal;">Graham, thank you for a great insights and suggestions.</span></div><div><br>
</div>Graham Wideman</b> wrote on <i>Mon Oct 19 16:11:21 PDT 2009:</i></span><div><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><i></i><p></p><ul></ul></span><font class="Apple-style-span" face="Times"><span class="Apple-style-span" style="font-size: medium;"><i><span class="Apple-style-span" style="font-style: normal; "><pre>
> I am currently not sold on the importance of native.if per se, and feel that it's trying to address a genuine problem, but at the wrong place.
Mmm, perhaps, but I think operators are pretty core. I think any solution would involve operators since they're core. Perhaps they're just a good starting point, jumping off point for discussion?</pre><pre>BTW, I just finished reading many posts on this mailing list from 2009, and there are definitely use cases for making ST more adaptable to model input, so I think ST could definitely benefit from some TLC in this area.</pre>
<pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>> So, maybe there's an argument to provide, within ST, access to particular native language features,</pre><pre>> but I am skeptical about it's importance in the area of "if".</pre>
<pre>I think you make a good case that "if" is limited in solving all the problems. However, "if" is a key for ST, so getting it to work nicely still seems compelling, even if insufficient. You make a case (and from past posts I've read), there are plenty of niggly little data importing issues that crop of to cause impedance mismatches between model and view/ST. As you suggest, even a multi-headed "if" is insufficient to solve them all.</pre>
<pre>Past posts and your well-written expose on "if" et al. convince me that the language and user based customizations _will_ get used to make ST adapt to various situations it smugly avoids now. Once ST is willing to solve the niggly import issues, I believe ST will get more use.</pre>
<pre>Which is a good segue to your final suggestions...</pre></span></pre><pre>> avoid using the keyword "native", and instead use the keyword for the language: java.somefunction or csharp.somefunction etc.</pre>
<pre>+1, and</pre><pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>> com.yourdomain.somefunction
</pre><pre>+1</pre><pre>I was cracking up when I read your suggestions, because they're spot on, I didn't see them coming, yet I was thinking in the same direction. My next suggestion was:</pre><pre>model.*</pre>
<pre>So "native.*" is out. It was bugging me. I was thinking "lang.*" but hadn't thought to actually specify the language. Your solution is great. I also was thinking about "user.*"; again, your solution is better.</pre>
<pre>Let me explain my "model.*" suggestion even if it turns out inferior to your suggestions (not to mention a little tongue in cheek:-). What I realized is that unsolved interfacing problems in the mailing list degenerate into exhortations of "Do it in the model!". In other words, whenever a model doesn't provide exactly what ST needs (and ST takes a pretty narrow view of data), the model has to get "fixed" when it wasn't broken.</pre>
<pre>That's a problem for two reasons.</pre><pre>1. If the model isn't broken, why is it being fixed? In other words, why can't ST handle normal stuff like everything else on the market? (Answer: because ST is pure, and doesn't do "model" like the rest of the template engines.) That's what makes ST cool... and what makes it suicidal.</pre>
<pre>ST needs to be friendly to models, and by friendly I mean: Be generous in what you accept!</pre><pre>If ST can not adapt to "normal" models, then it's useless in many situations, and dangerous to standardize for unknown/future projects. For example, what if the model can not be changed? That happens, right? That's what ST strives for: total separation of view and model. What if it's literally the case that they're already separated, and the view simply has to make do? Then saying "Do it in the model!" is an admission of ST failure. Unacceptable.</pre>
<pre>I read a thread where one guy was very polite, understood the value of ST's separation of concerns, but struggling to make it work. He kept requesting relief for niggling data massage problems (e.g., calculations, filtering, little stuff). His final answer was that he doesn't have access to the model, so he can't change it. The official response was essentially: Do it in the model, or bust! I don't think he ever posted again. I bet he dropped ST like a hot potato (and for good reason).</pre>
<pre>That's garbage (not him, ST's smug attitude, "Do it in the model, or bust!").</pre><pre>ST has several advantages. One it's more often than not an endpoint for processing. So it only has to serve one master --- the model on input. So it should at least make itself as easy to use by the model as possible (a la the "Robustness Principle", "Be generous in what you accept!", ease of use, adaptability, and all that).</pre>
<pre>Second, ST is usually the new kid on the block, so it's installed base in each new project is small, simple, and blank slate. It's a perfect place to add complexity when the rest of an application is overloaded. Yeah, I said it: add complexity. Sometimes model stuff is easier done elsewhere. That's what people keep asking for, projects keep asking for, and desperate measures keep asking for. So, ST should help out (again, be easy to work with). Again, just saying "Do it in the model!" is purist gobbledygook, and from an engineering standpoint can even be wrong. Sometimes its better to offload straightforward stuff to endpoints (e.g., ST).</pre>
<pre>So, my epiphany is that all those posts exhorting poor infidels to "Do it in the model!" would suddenly come true. With</pre><pre>> model.*</pre><pre>With "model.*" user custom hooks, anyone could do anything in the model, including massage input for easy processing in ST. The perennial exhortation "Do it in the model." could remain true, and yet ST would be easy to use and adaptable by providing an outlet for model massaging, "model.*".</pre>
<pre>So even mundane non-view stuff could be done in model.* (trimming, calculating, filtering, etc.) with native language support, but apart from ST itself. Sure it's violation of purity, but not of ST purity. Model massage is segregated to "model.*" and that's fine. Suddenly the world doesn't have to adapt to ST; ST can adapt to the world.</pre>
<pre>Much better for all.</pre><pre>Plus, model.* customizations take some of the pressure off ST to handle any but the most straightforward model stuff (such as themost basic "if.*" cases). Model massage can take care of the rest. ST gets to maintain its sanity, while being much more adaptable to real world situations.</pre>
<pre>Prospective users don't have to worry about getting rabbit-holed (etc. etc.) by ST purity, or "fixing" a model that already works (just because StringTemplate demands it). Impure code goes in "model.*" (in the model where it's supposed to be :-).</pre>
<pre>My reading of the list suggests such an escape valve is sorely needed for massaging data on the way into ST but criticized every time someone gets too pushy. IMO, ST should shoulder some of the massaging work when necessary. I was tempted to call massaging "middleware.*", but "model.*" says it all, and keeps the advice "Do it in the model." as current as it ever was.</pre>
<pre>-=-</pre><pre>However, Graham's suggestions about language specific or even domain specific names are well taken. After my reading of the list, I found cases of shared language specific code ('if you're using java, just email me for the code'), and also some demand for custom hooks and massaging to get data into ST without modifying preexisting models. So, taking the long-view with the domain names may be appropriate. I'm open to either or both! I'll think on it, and look forward to other insights.</pre>
<pre>Thanks for the suggestions,</pre><pre>= Joe =</pre><pre><br></pre></span></pre></span></i></span></font></div>