velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Bubna <nat...@esha.com>
Subject Re: a new paper on enforcing separation in template engines
Date Mon, 17 Nov 2003 22:11:02 GMT
Terence Parr said:
> Rob said:
...
> > Plus, for markup developers, something like this looks a little
> > too PhD-in-CS-ish to write:
> >
> > $names:{<b>$attr$</b>}:{<li>$attr$</li>}$
>
> Designers like patterns not programs...they don't understand loops, but
> they do understand "apply this pattern to all the book entries".  Well,
> I have empirical evidence that this works for our (albeit very smart)
> designer.

does she know that you don't think she understands loops? ;)

> Can anyone on the list here claim to have a designer (just a designer)
> building their sites?  Until I hear that for a commercial site, I'll
> stick to my guns that designers don't understand for-loops and method
> calls.

i dunno.  stick to your guns if you like, but it seems to me that most
designers will know method calls at least.  find me a designer who hasn't done
at least a little javascript and i'll be really shocked!

also, understanding that $tool.getData('foo') is a method call and how it
works is not a prerequisite to using it (assuming the tool developer has a
brain and writes a little documentation).  aren't you the one who keeps saying
$title and $model.getTitle() are functionally equivalent?  :)

> Most importantly, nonprogrammers don't understand state.  They
> don't understand setting, testing, and reseting values.  That is why my
> attribute refs are side-effect free.  No order, no changes of state.

this is also why pull tools should not affect state, they should just access
it.  this is primarily an argument against bad Pull-MVC design, and thus it is
at best a weak argument for Push-MVC.

...
> OTOH, can
> your designer understand this (from the Velocity manual)??
>
> ## toolview.vm
>
> #set ($title = "Tool Listing")
> #set ($deck = "A list of content creation tools")
> #set ($desc = "Without tools, people are nothing more than animals." )
>
> #parse ("header.vm")
>
> $toolbean.setToolsFile($application.getInitParameter("toolsFile"))
>
> #set ($tools = $toolbean.getTools($request.getParameter("state")))
>
> #foreach ($tool in $tools)
>    <HR SIZE=2 ALIGN=LEFT>
>
>    <H3>
>    $tool.Name
>
>    #if ($tool.isNewWithin(45))
>      <FONT COLOR="#FF0000"><B> (New!) </B></FONT>
>    #elseif (tool.isUpdatedWithin(45))
>      <FONT COLOR="#FF0000"><B> (Updated!) </B></FONT>
>    #end
>    </H3>
>    <A HREF="$tool.homeURL">$tool.homeURL</A><BR>
>
>    $tool.comments
> #end
>
> #parse ("footer.vm")
>
> I'm pretty sure that would be a bit much for a nonprogrammer. ;)

egad!!  that's disgusting.  i assure, that is not the recommended pattern
these days!  and the use of the term "tool" here is atrocious.  if you wanna
know how to do Pull-MVC right or what *i* mean when i talk about a "pull
tool", then check out VelocityTools: http://jakarta.apache.org/velocity/tools/

...
> > You have a point that Velocity allows you to do things like only
> > showing a list of users whose age is under 30, which should of
> > course be done in the controller, but I personally think I can
> > sacrifice some lack of enforcement for something that is very
> > easy to understand.
>
> Actually, if I may be pedantic, you get total lack of enforcement.  I
> mean that is the whole point I'm trying to make.  Either you enforce no
> conditional logic upon dependent values or you merely encourage.  It's
> binary ;)
...

"toString()"

sorry, i just couldn't resist. ;)

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message