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

[Jonathan Buhacoff]

On Oct 19, 2009, at 11:04 PM, Joseph Grace wrote:

> Jonathan Buhacoff wrote on Mon Oct 19 22:20:04 PDT 2009:
>
> > I believe that ST's growth in popularity will be precisely because  
> it
> > maintains a strict separation that attracts programmers who are
> > suffering from spaghetti-code syndrome with other tools.
> No argument here.
> Nothing changes.  If you don't need the hooks, do not use them.

Ok, that's fair.

> > Everything that needs to be done to "massage" data can be done and
> > should be done in the model.
> Echoes of "Do it in the model!"
> What if the model is inaccessible, feature frozen, or otherwise  
> source code inaccessible?  Count your blessings that you have fully  
> accessible model code.  Some projects don't and that makes ST a dead- 
> end due to logistical difficulties.

Then you need another layer of model, not view hooks. If the model is  
also integrated with the controller and you can't change the fact that  
the system uses ST for output, you could rewrite the templates to  
output all the model's  output in a suitable data format, write  
middleware to take that as input and supplement it with whatever else  
you need, and then use that with a copy of your original templates.

I guess I'd need an example of how you would use model.* to run  
arbitrary code that's not in the template to compensate for a model  
and/or controller that you can't change.  In the scenario you  
described, you'd have to actually write the code in the template  
because you wouldn't be able to change the model to take advantage of  
the hooks...

It just seems to me that if you can add a hook, you can also do  
anything else that's needed to fix the model and keep the view  
simple.   Here's a paragraph I copied & pasted from a previous email:

On Oct 19, 2009, at 5:59 PM, Joseph Grace wrote:

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.
So I think I just disagree with this premise. If they are already  
separated, great, make the change in the model. If they are already  
separated AND the model is frozen,  then modify the controller to  
either merge data from the frozen model with a new one, or to wrap  
data presented by the model with variations that you need in the view.  
If both the model and the controller are frozen, then you have an  
issue that is entirely outside the scope of the view.
If I were in a restaurant and the waiter (the view) told me he can't  
bring my favorite dish because they're out of ingredients,  I would  
call the owner and complain about the manager (the model/controller)  
not the waiter.  I certainly wouldn't expect the waiter to run to town  
(with hooks) buy the ingredients and cook them for me.  That's just  
not his job.
Similarly,  ST wouldn't be at fault,  and neither would the principle  
of separation between model and view, which predates ST.   ST is just  
better at enforcing what we already believe to be good and true.


>  > of course you can abuse these with side-effect programming... but  
> that
> > would be abuse of a feature, as opposed to something built-in to
> > encourage entanglement of model and view.
> Really?  Extensibility solves real world, logistical problems that  
> would prevent ST from being used.
> Think of it as a "nice convenience feature" for pulling data from  
> the model.
> = Joe =
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091020/4bc656b8/attachment-0001.html