velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jonah benton <jo...@jonah.com>
Subject Re: foreach
Date Sat, 04 May 2002 07:33:39 GMT
On Fri, 2002-05-03 at 17:42, Daniel Dekany wrote:
> Friday, May 3, 2002, 11:03:21 PM, jonah benton wrote:
> 
> > On Fri, 2002-05-03 at 12:59, Jonathan Revusky wrote:
> >> jonah benton wrote:
> >> > We've had occasional need for it, but we're generally iterating over a
> >> > list maintained by an object we have in the context, so when we reach a

> >> > state change where we want to stop iterating, we tell the object, and
> >> > the object arranges for the next call to hasNext() to return false.
> >> 
> >> Yes, but that's apples and oranges. Essentially, what you're doing is 
> >> using your control of the java code layer to work around a deficiency in 
> >> the template language.
> >
> > Better that than the other way around. :)
> >
> >> In the idealized MVC situation, the people working at the template layer 
> >> are completely separate people from those working at the java code layer.
> [snip]
> > More generally, at this point in web development, I am much more
> > comfortable with a simpler template language that requires some
> > solutions in Java to "work around [its] deficiencies", than a more
> > sophisticated template language that encourages designers to grow their
> > creative instincts into unmaintainable code without programmer
> > involvement. FreeMarker is much more restrained than PhP, ColdFusion,
> > and others in that ilk, but the mindset encouraging non-programmers to
> > find programmatic solutions is certainly present in its design. 
> 
> A more sophisticated template language is not necessary a drawback:
> 
> 1.: V layer tends to be simple (compared to C and M) but it is not
> always simple. Moving complexities of V into C/M just because the
> templating language is too stupid is a nonsense. Blend V into C/M is a
> clean violation of the MVC model idea.
> 

Of course- the key point is that in the web world, unlike the worlds
where MVC originated, most people working in the V are not programmers.
This has a substantial impact on code quality, especially procedural/oo
code quality. In my experience, non-programmers and programmers write
equally good code in declarative languages (html), but non-programmers
write unmaintainable or incorrect code in more expressive procedural/oo
languages. So the reason to put what could be V abstractions into Java
and make them available through method calls is to ensure that those
abstractions are developed and maintained by the best programmers. 

Velocity has procedural constructs, but happily limited abstraction
mechanisms, and this really helps to improve code quality in templates.


> 2.: Not everything in the V is made by the non-programmer designers.
> Even right now you may write tools that perform cleanly V tasks (HTML
> encoder for example). And I think many users would be more happy if
> Velocity offers a facility similar to JSP tag-libs. This does not mean
> that designers will write Velocity-tags. They will not as they will
> not learn how to do it and they will not be allowed to write tags
> anyway. Programmers can write velocity tags, and non-programmer
> designers can use them. This was just an example, not a proposal...

Yes- I've worked extensively with taglibs and have good and bad things
to say about them. Where the problem domain permits a declarative
solution with an appropriately structured set of taglibs, they're really
great. But many problems don't fit into this category, including view
problems.

I briefly explored the possibility of extending Velocity with custom
directives to capture some of the tag semantics we had been working with
in the past- because to follow on to a good point that Jonathan made,
sometimes exposing a more restricted semantics than objects usually
expose is a good idea- again, for code quality reasons. Tags let you do
this, sometimes more clearly than objects. I'd like to explore it
further at some point.


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



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


Mime
View raw message