Will Glass-Husain wrote:
Sure - I'd welcome any kind of constructive on-topic discussion.
I'm not a Jython user or developer.
Okay, but as the only guy really active in this project, don't you think
the issue of integrating with JVM-based scripting languages is at least
somewhat interesting?
A Velocity user wrote this
and kindly shared in on our wiki. But he and others might
be interested in thoughts.
They "might" be interested in feedback? You aren't interested?
Under normal circumstances, I would just assume that people who write
and maintain open-source code are interested in any feedback they can
get. The reason I asked whether you were interested in any further
feedback on this is because a reasonable observer would have doubts here
as to whether there is genuine interest in making Velocity better.
Anyway, there is a fundamental design problem as regards this
JythonUberspect thing. In the example the guy gives in the Wiki, he puts
a tool in the context to get an element from a jython list.
$listtool.get($jythonlist, 4)
My previous comment just concentrated on how awkward the above syntax
is, which, in a way, is the lesser issue. You see, the problem is that
a typical usage pattern with a scripting language like Jython is that
you use it for fast prototyping and then, later, for performance
reasons, you might change the code to Java. If you use the above
listtool, and the list is a java.util.ArrayList, say, then the above
snippet fails.
So, IOW, you have a disposition whereby the template writer has to know
whether a list exposed to the template is a jython sequence or a
java.util.List or whatever.
Don't you see the design (or lack of design) problem there?
Actually, Bertrand Meyer considers something called the "Uniform access
principle" to be a key thing in object-oriented programming. That
certainly applies here. A template writer should not care whether a list
exposed to a template is precisely a PySequence, an ArrayList, or a
LinkedList. He should be able to access the nth element of a sequence in
a uniform way and the template code should just transparently work.
If you are going to have interoperability with jython or other JVM-based
languages, you have to have the "uniform access principle" operating as
much as possible and the template writer should not be aware that
something is a Python dictionary as opposed to a java.util.HashMap, or
is a PySequence vs. a java.util.ArrayList. It should just all work in a
uniform way.
Until you have this working properly, when people bring up jython
integration, you might as well point them to FreeMarker, where it is
implemented correctly. And, BTW, we also have rhino (javascript)
integration.
Jonathan Revusky
--
freemarker project, http://freemarker.org/
WILL
----- Original Message ----- From: "Jonathan Revusky" <[EMAIL PROTECTED]>
To: <velocity-user@jakarta.apache.org>
Sent: Thursday, September 29, 2005 2:06 AM
Subject: Re: Using Velocity with Jython (and uberspect)
Will Glass-Husain wrote:
Thanks, Jonathan, that's interesting.
Well, you're welcome. I have a bit of further constructive criticism
about
this JythonUberspect thing. I will provide that if you are genuinely
interested.
Jonathan Revusky
--
FreeMarker project, http://freemarker.org/
James - there's some more info about Jython and Velocity on the Wiki.
http://wiki.apache.org/jakarta-velocity/JythonUberspect
If you go this route, let us know how it works out. Would love to see
more
examples and content about this on the Wiki.
Best,
WILL
----- Original Message ----- From: "Jonathan Revusky"
<[EMAIL PROTECTED]>
To: <velocity-user@jakarta.apache.org>
Sent: Tuesday, September 27, 2005 10:26 AM
Subject: Re: Using Velocity with Jython (and uberspect)
This JythonUberspect stuff is extremely experimental stuff in Velocity.
Somebody can correct me if I'm wrong, but I don't think it's something
that is a stable, supported part of the product.
I think that, for anybody interested in a java template engine that
interacts seamlessly with Jython, FreeMarker is the obvious choice,
since the Jython integration is part of the core distro and has been for
the last couple of years at least. I don't recall any reported problems
with this and at least some people must use it. Of course, if you do run
into any problems, we'd definitely address it since it is a supported
part of the main distro.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
