Townson, Chris wrote:
> http://niksilver.com/2007/05/10/guardian-unlimiteds-new-look-s
>
> thought this might interest members of this list, if you haven't
already seen it.
>
> It would be interesting to know a little more about the tools they
built:
> I know that we at Nature have been working towards a
"component"-based system
I'm actually quite interested in this sort of thing and I wrote a blog
article about it. You might or might not find it interesting. Other
people might (or might not) find it interesting as well:
http://freemarker.blogspot.com/2006/07/designerdeveloper-division-of-labor.html
There, you see that, I make no bones about what I think regarding
Velocity. It definitely seems to me that VTL is lacking certain basic
features that you would need to build reusable components. The macro
system is just too deficient.
That's not just my opinion. For example, look at the comments by Ken
Egervari in this blog entry:
http://jroller.com/page/raible?entry=freemarker_vs_velocity
I'm referring to this part specifically, where Ken says:
<QUOTE>
However, I've been doing some pretty complex stuff in the view. Now, I
don't mean I'm putting business logic in there - that's not it. I've
just been making massive amounts of investment in macro libraries and I
build higher-level marcos for all sorts of application-specific
presentation reuse. However, Velocity just isn't any good at doing this
- and I'm not even talking about large scale applications, I'm talking
about a small to medium-sized but featureful project a competent
developer can write in a few weeks.
I think I've hit the capabilities of Velocity and I've been stretching
it quite a bit. Without named/optional parameters or even basic macro
overloading, I just can't build complex views and avoid duplication at
the same time very easily. It's like a pain in the ass just to add an
option column, button or sub-screen for a specific listing that uses the
general listing macro and so on. I have all kinds of cases where I have
to do functional-oriented type checking and it's inexcusable.
Freemarker seems like the way to go. While it's probably more difficult,
the end result looks to be more like html. When I saw features for
unordered named, optional parameters and nested content, I realized that
these features alone make it better than Velocity because they just
aren't "nice" features, the are just down-right required.
</QUOTE>
The above comments were made several years ago, and I do not see any
forward movement in this project in terms of addressing the deficiencies
that Ken is mentioning there.
>(which seems to be what they've developed at The Guardian) for a
little while
>now and are shortly to go live with a Spring-based system for
formalizing
> the management of the design and templating of large, complex, modular
> sites using Velocity.
Large, complex, modular sites using Velocity, eh? I suppose it's
possible. But really, you know, when you can't even #parse a set of
commonly used macros in a separate file, and there's no notion of
scoping or namespaces whatsoever, so that any variable defined locally
in a macro potentially clobbers variables defined elsewhere -- to rely
on that kind of tool to build something complex and modular, does not
seem like a very good technical decision. The tool simply lacks
necessary things for modularity.
>
> There might be some common ground covered between us and The
Guardian here
> which could be fed back into the Velocity project itself, perhaps?
Well, historically, lobbying Velocity developers for features that you
need has not been a very fruitful path. I won't go on further about
that, but surely you can perceive that, even bending over backwards to
be generous and all, you can't describe this as a very dynamic
environment, can you?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Best,
>
> Chris
>
>
********************************************************************************
> DISCLAIMER: This e-mail is confidential and should not be used by
anyone who is
> not the original intended recipient. If you have received this
e-mail in error
> please inform the sender and delete it from your mailbox or any
other storage
> mechanism. Neither Macmillan Publishers Limited nor any of its
agents accept
> liability for any statements made which are clearly the sender's own
and not
> expressly made on behalf of Macmillan Publishers Limited or one of
its agents.
> Please note that neither Macmillan Publishers Limited nor any of its
agents
> accept any responsibility for viruses that may be contained in this
e-mail or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of
Macmillan
> Publishers Limited or its agents by means of e-mail communication.
Macmillan
> Publishers Limited Registered in England and Wales with registered
number 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>
********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
