You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2003/07/12 09:09:46 UTC
Re: Freemarker support
Jonathan Revusky <jo...@revusky.com> writes:
...
> > --- cut ---
>
> > Velocity was built new from the ground up. There isn't a snippet of
> > shared code. This was originally done because WebMacro was released
> > under a license (GPL) that is not compatible with the BSD/ASF license
> > and we (the original authors) needed a solution that was not under a
> > GPL license. Since then, WebMacro has been released under a dual
> > GPL/ASF license, however, that was too late, this project was already
> > well underway and we also felt that we have a better technical
> > solution by going with a generated parser instead of a hand coded one.
> > --- cut ---
>
> Weeeell, this license story as the driving thing could have some truth
> to it.
How magnanimous of you.
> OTOH, that they so desperately needed all of a sudden a version
> of WM that was under the Apache License -- while possible, is
> surprising nonetheless. I dunno. I don't see how there was much of an
> issue in terms of just using WM with no alterations as a 3rd party
> lib.
You seem to be under the delusion that Velocity is technically
lacking. You should've seen WebMacro three years ago! One couldn't
get away without patching it, in turn complicating its redistribution.
> They surely wanted to get the thing out there and used by a lot of
> people. And, as noted above, the WM people did ultimately just give
> in on the license issue. It's available under a BSD-style license.
You've a habit of pointing out the reason for that, even if you don't
associate it with licensing.
> One striking thing about Velocity IMO is how technically unambitious
> it was.
Isn't it wonderful? One of my favorite aspects.
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Volunteer Opportunity (was Re: Freemarker support)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Eric Dobbs <er...@dobbse.net> writes:
>Regardless of what "cleaning" means to anyone, it's pretty clear
>that neither Jonathan, nor Dan, nor Henning have any interest in it.
No. I have lots of interest to get this separated out in a clean
way. But I will block any attempts to "short cut" or to introduce
kludges here as the TemplateService/TemplateEngine/PullService
interaction is one of the things that really separate Turbine from
other frameworks.
I know that we have work to do here. I agree that this is not the
scope of a "template engine developer" but of the turbine core
people. However, at the moment I feel no pressing need to work here.
Just because some people wrote that "they would try feature <xxx> out
if it was readily available to them" doesn't mean, that feature <xxx>
suddently pops on top of our priority list.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
<snip>
> About supporting other templating engines on "equal footing": This
> makes two assumptions:
>
> a) The current code surrounding the view engine is abstract enough to
> be templating engine neutral.
>
> b) There is interest enough interest from Turbine developers to support
> a second, third, fourth, fifth engine.
>
>
> For a): Most of the code is. Some is not. This will change post-2.3
>
> For b): There are much more interesting fish to fry and code to
> write. At least I have no intention to do so in my _spare_ time.
> Personally I have a templating engine that fills all my needs and I
> see no reason to reinvent the wheel. If a developer or a project
> needs an <xxx>-view, well, they can communicate with the Turbine
> developers to donate code (that is what open source is all about)
You have a standing offer from the lead developer of the FreeMarker
project (me) to provide the integration with FM if condition (a) is met.
I do not believe, however, that you can assume that this offer is
open-ended in time. I may be too busy at a later point to attend to this.
> or they can contract one of us to write it for them.
IOW, you are not willing to do anything on this, it seems. Then, I would
like to ask something. Why did you post the following article on the
turbine-user list?
http://article.gmane.org/gmane.comp.jakarta.turbine.user/7165
I mean, you are clearly the one who brought up the topic. I did not
bring it up, because I always just assumed that Turbine was coupled with
Velocity for political reasons, and that you wouldn't support FreeMarker
despite it being technically better. You claim that this is conspiracy
theory stuff, fine, but given that I just assumed that FM support was
not in the cards, I would not have brought up the topic. Also, there is
a clear electronic record of this. *You* brought up the subject.
Now, as a result of your post, various people did express interest. Now,
you are stating that you are not interested in this, and are not willing
to do anything on this front unless maybe someone pays you.
Why did you bring up the topic then?
I think this is a reasonable question, because if you brought up the
topic and then, when people expressed interest in FM support, you start
saying that it's of no interest to *you* personally and you don't want
to do anything on it, well, it is suggestive of the possibility that you
were just wasting everybody's time with this -- jerking them around, to
use the vernacular.... Now, there may be a more generous interpretation
of your behavior, so I leave it open to you to explain.
But do please refrain from ad-hominem attacks in your response. There is
a simple question I have posed: If you are not willing to do anything on
FM integration, why on earth did you ask your user community whether
they were interested?
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jim Seach <jw...@yahoo.com>.
--- "Henning P. Schmiedehausen" <hp...@intermeta.de> wrote:
> Jim Seach <jw...@yahoo.com> writes:
>
> Hi,
>
> >Would it make any sense to support view/template engines by
> forwarding
> >to a view-specific servlet (like the newly released
> >VelocityViewServlet) and communicating with all view engines through
> >request, session, and application attributes? That way you let the
> >Servlet mapping function of the Servlet container choose the view
> >engine and they would all be on the same footing. It would be the
> >responsibility of the view engine's servlet to make the Turbine
> objects
> >available to the engine in the proper manner.
>
> IMHO, no. Mainly because (as far as I understand the function of
> VelocityServlet), this is already part of the Turbine Servlet (which
> is, in fact, one big servlet. ;-) ). I haven't heard of
> VelocityViewServlet, where can I find this?
It's part of the just released Velocity-Tools project. See
http://jakarta.apache.org/velocity/tools/index.html
Basically, the VelocityViewServlet (VVS) assumes the developer has put
whatever the view requires into one of the Servlet contexts then has
done a forward or include to a URL that maps to the VVS. The VVS
constructs a Velocity Context from the attributes from ServletRequest,
HttpSession, and ServletContext and also from a configurable Toolbox,
locates the template, and renders it.
It allows Velocity to be used in place of JSPs in a WebApp without
requiring any changes to the WebApp logic. For example, VVS permits a
Struts developer to Velocity in place of or alongside JSPs without
changing any of the Struts classes.
>
> We use our java-class broker to return render classes for "now take
> this file and render it as <xxx>-template". This maps your template
> name to a java class name. Most of the time, it comes out as "use the
> VelocityPage class to render this template". Because the
> VelocityService (see below) has registered the VelocityPage class as
> the page render class for templates, ending in .vm
>
Using the VVS approach, you would just need to map a logical
page/template name to a URL and use the Servlet API to figure out the
proper view servlet to call based on the servlet mappings.
> VelocityPage is coupling point between the class-based assembler
> broker (in the AssemblerBroker Service) and the actual template
> mapping engine (which came later into play when Turbine was already
> busily serving web applications with a java based view).
>
> VelocityPage prepares the Context by pulling it from the
> VelocityService (which is the Factory that builds up and tears down
> the Context objects and is also the initialization point for the
> Velocity View engine) and then maps your template to an actual
> template file (this is scope of the TemplateService), renders it (by
> using Screen, Layout and optional Navigation) and returns it to the
> container.
Rather than use a VelocityContext it could prepare a TurbineContext,
put it in a ServletRequest attribute, then use the xxx-ViewServlet to
render the desired view.
>
> About supporting other templating engines on "equal footing": This
> makes two assumptions:
>
> a) The current code surrounding the view engine is abstract enough to
>
> be templating engine neutral.
>
Or that it can be refactored to make it so :^)
> b) There is interest enough interest from Turbine developers to
> support
> a second, third, fourth, fifth engine.
>
If there is no interest in making the code more generic it won't get
done, but based on this discussion it seems like some of the developers
see it as a positive (if low priority) thing to do, so if someone puts
in the effort to do this it might be accepted.
>
> For a): Most of the code is. Some is not. This will change post-2.3
>
> For b): There are much more interesting fish to fry and code to
> write. At least I have no intention to do so in my _spare_
> time.
> Personally I have a templating engine that fills all my needs
> and I
> see no reason to reinvent the wheel. If a developer or a
> project
> needs an <xxx>-view, well, they can communicate with the
> Turbine
> developers to donate code (that is what open source is all
> about)
> or they can contract one of us to write it for them.
>
Well, I don't particularly like JSP, ASP, or similar view technologies
because it makes it too easy (and therefore tempting) to put business
and controller logic into the template. I would rather take a little
more time to develop a more maintainable system. I like Velocity
because of its simplicity: if something is hard to do even with a tool,
it probably shouldn't be in the view.
I don't *need* support for other view technologies, but I was just
wondering if by changing the approach it would both simplify Turbine
and allow for other view engines. Some people prefer JSP or Freemarker
over Velocity, and if Turbine supported them, it may attract more users
(and developers).
> Regards
> Henning
>
Thanks,
Jim Seach
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> --- Quote of the week: "It is pointless to tell people anything when
> you know that they won't process the message." --- Jonathan Revusky
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jim Seach <jw...@yahoo.com> writes:
Hi,
>Would it make any sense to support view/template engines by forwarding
>to a view-specific servlet (like the newly released
>VelocityViewServlet) and communicating with all view engines through
>request, session, and application attributes? That way you let the
>Servlet mapping function of the Servlet container choose the view
>engine and they would all be on the same footing. It would be the
>responsibility of the view engine's servlet to make the Turbine objects
>available to the engine in the proper manner.
IMHO, no. Mainly because (as far as I understand the function of
VelocityServlet), this is already part of the Turbine Servlet (which
is, in fact, one big servlet. ;-) ). I haven't heard of
VelocityViewServlet, where can I find this?
We use our java-class broker to return render classes for "now take
this file and render it as <xxx>-template". This maps your template
name to a java class name. Most of the time, it comes out as "use the
VelocityPage class to render this template". Because the
VelocityService (see below) has registered the VelocityPage class as
the page render class for templates, ending in .vm
VelocityPage is coupling point between the class-based assembler
broker (in the AssemblerBroker Service) and the actual template
mapping engine (which came later into play when Turbine was already
busily serving web applications with a java based view).
VelocityPage prepares the Context by pulling it from the
VelocityService (which is the Factory that builds up and tears down
the Context objects and is also the initialization point for the
Velocity View engine) and then maps your template to an actual
template file (this is scope of the TemplateService), renders it (by
using Screen, Layout and optional Navigation) and returns it to the
container.
About supporting other templating engines on "equal footing": This
makes two assumptions:
a) The current code surrounding the view engine is abstract enough to
be templating engine neutral.
b) There is interest enough interest from Turbine developers to support
a second, third, fourth, fifth engine.
For a): Most of the code is. Some is not. This will change post-2.3
For b): There are much more interesting fish to fry and code to
write. At least I have no intention to do so in my _spare_ time.
Personally I have a templating engine that fills all my needs and I
see no reason to reinvent the wheel. If a developer or a project
needs an <xxx>-view, well, they can communicate with the Turbine
developers to donate code (that is what open source is all about)
or they can contract one of us to write it for them.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>Yeah, I know it's pretty trivial really. But, then the other classes
>>should really use the template service abstraction. You shouldn't have
>
>
> You don't understand what the template service does. You read
> "template" and think "template engine". That's your problem. You talk
> before you think.
<sigh>
Look, all this baiting and so on, it's a little bit too obvious. My read
on this is that you want me to get angry. It gives you something
tangible to sink your teeth into, and then then all the other yahoos can
pile on.... that much is clear, but I am wondering about the motive. I
guess the motive is sort of tactical, to create a distraction or something.
I could be wrong, but that's my understanding of this.
I mean, I look at this situation and I see the following points:
1. It's pretty trivially simple for anybody who actually knows the
Turbine code (you, for example, *not* me) to refactor things such that
multiple template engines can be supported on an equal footing. You
could fix this today if you wanted to.
2. Not only is such a refactoring clearly desirable for its own sake,
but, when asked, some users expressed quite real interest in giving FM a
try. I have little doubt that a lot of people are up to the gills with
some of Velocity's limitations and the lack of any forward movement in
that camp.
So clearly, you should do this. However, I guess you don't really want
to do this (probably, for whatever murky non-technical reasons... if I
state them, you'll start with this "conspiracy theory" stuff again, so I
won't...).
So, bottom line: you're trying to create a distraction.
>
> TemplateService is a vastly different beast than "maybe similar named
> things in other frameworks". What you think of are Template Engines,
> which are in Turbine _completely_ separated out into things like
> JspService and VelocityService and register with the TemplateService.
>
> Turbine can use multiple templating engines simultanously. We can have
> JSPs and Templates side by side in a single application.
>
> Template Service is mapping template descriptors (like "foo,bar,Baz.vm"
> or "yadda,yadda,Yadda.jsp" to a Templating Engine (Velocity or JSP or
> anything else) and let the templating engine render it. It is
> _completely_ engine independent. In fact it couldn't care less what
> engine is used to _render_ a template.
>
> You won't find a single reference to any templating engine in the
> o.a.turbine.services.template package (besides examples used in the
> comments).
Well, I'm sure that's all true, but the fact remains that I don't know
which package does what and there is not much onus on me to know these
things. Also, these things aren't terribly well documented anyway.
All I know is that I finally did a CVS checkout to evaluate how
difficult it was to put FM support back, and, with a quick grep, I saw
that Velocity API's are used directly in a lot of different places
throughout the code. I counted 21 different classes.
I have a lot of different things I'm doing, I didn't consider the
situation reasonable, so after taking that glance, I simply gave up on
it. I wrote a note in which I said that this was the situation and that
it wasn't reasonable. In response, you accused me of spreading FUD.
But anyway, it seemed to me that you did not have a sufficiently
modularized codebase that I could offer a patch. Now, this was after you
(and someone else IIRC) started this "submit a patch" sort of stuff. I
concluded that the "Why don't you submit a patch" stuff was not stated
in good faith, because you knew perfectly well that the codebase was not
in a state that I could just go in and find a couple of key points to patch.
This is confusing stuff. My current interpretation of this weird
behavior on your part is that it was political in origin. You wanted to
spin things in such a way that the lack of support for FM, say, was due
to something that *I* wasn't doing. You were trying to represent that
there was some onus on me to just submit a patch. My pointing out the 21
coupling points made it pretty clear that there was no such onus on me,
that the ball was in your court.
I earlier stated that I was unwilling to do anything on this because of
the history of this whole thing. However, I changed my position. My
position is now, that if you get your house in order on all these
various points of coupling with org.apache.velocity.* classes in the
codebase -- so that the codebase generally just uses whatever template
engine abstraction you set up, then I would help you.
The offer of help is sincere and I stand by it, but to be completely
frank, it was offered for tactical reasons in a sense. I simply did not
want you to have any excuses.
>
>
>>all these other things that directly use velocity classes. It makes no
>>sense.
>
>
> It makes no sense to you. Because you don't understand the basic
> concepts how Turbine pages are rendered from page, layout and screen
> classes. This is classes. Not templates.
Well, there is no onus on me to understand these things.
>
> And I do not feel inclined to describe it to you, because you won't
> listen anyway.
This is more baiting, but you actually have a point. I have little time
for listening to you explain all this stuff. It's of no interest to me.
If you get the codebase to the point where you don't have all these
coupling points with Velocity classes, where the framework just uses Vel
through a generic template engine API, I will help you get FM working
via the same generic template engine API. If this is done properly, I
don't need to undersand how the Turbine framework works as a whole. I
just implement the API's needed to plug in FM and that's that.
However, from my POV, if you don't get rid of all those coupling points,
I would be wasting my time. You see, if I go through the bother of
making FM available through some abstracted tempalte engine API, but
large parts of your codebase use Velocity classes directly, then there
will be significant functionality available to Velocity users that is
not available to people who opt for FM.
Ergo, same rigged situation as before. Ergo, I'm wasting my time. And I
don't like to waste my time.
> If you dig in the turbine-users archives, you can find
> a long mail from me where I describe the process (including the
> AssemberBroker and Template Service lookups) in detail.
No onus on me to understand any of this really. At least, certainly,
unless you get your house in order on all the points of coupling with
Velocity classes, it is a waste of my time to bother with looking at this.
>
> You're looking at the wrong place. Supporting any other templating
> solution in Turbine is ridiculously easy. That's why we hade at some
> point five of them (Vel, JSP, FM, WM and Jython).
Well, if it's that easy and you have such a wonderful architecture for
supporting view tools, then why is it that the only template engine
people can use through Turbine is Velocity?
Doesn't make sense to me...
>
> But getting the stuff where Turbine _really_ shines and is superior to
> other web frameworks, which is the whole tool mechanism from the pull
> service and the toolbox, is hard. Because the original _Pull_ Service
> was written with Velocity in mind. And this is where the problem comes
> from. And this is, why Velocity was always better supported than any
> other templating solution. And this is, why no one bothered to use FM
> and WebMacro with Turbine. And this is, why at some point, the support
> for these rotted and was dropped.
>
> I've told this numerous times but you neither listen (hands over your
> ears) nor do you accept it as the truth, but you prefer to believe in
> some obscure Apache conspiracy theory.
<sigh>
My belief that the decision to favor Velocity over other solutions was
not entirely technically based is hardly that much of a conspiracy
theory, Henning. This attempt to portray me as some kind of lunatic
because I simply state things that everybody who wasn't born yesterday
knows anyway... that's getting a bit old, isn't it?
Just one final question:
It's clear what needs to be done, right? Given that, do you have any
intention of doing anything on this?
(Okay, that might be 2 questions, but they're reasonable questions, I
think...)
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
So be it, I accepted it.
>
> Regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jim Seach <jw...@yahoo.com>.
Would it make any sense to support view/template engines by forwarding
to a view-specific servlet (like the newly released
VelocityViewServlet) and communicating with all view engines through
request, session, and application attributes? That way you let the
Servlet mapping function of the Servlet container choose the view
engine and they would all be on the same footing. It would be the
responsibility of the view engine's servlet to make the Turbine objects
available to the engine in the proper manner.
(I haven't used Turbine yet, so please forgive me if this is totally
off-base :^)
Jim Seach
--- "Henning P. Schmiedehausen" <hp...@intermeta.de> wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
> >Yeah, I know it's pretty trivial really. But, then the other classes
> >should really use the template service abstraction. You shouldn't
> have
>
> You don't understand what the template service does. You read
> "template" and think "template engine". That's your problem. You talk
> before you think.
>
> TemplateService is a vastly different beast than "maybe similar named
> things in other frameworks". What you think of are Template Engines,
> which are in Turbine _completely_ separated out into things like
> JspService and VelocityService and register with the TemplateService.
>
> Turbine can use multiple templating engines simultanously. We can
> have
> JSPs and Templates side by side in a single application.
>
> Template Service is mapping template descriptors (like
> "foo,bar,Baz.vm"
> or "yadda,yadda,Yadda.jsp" to a Templating Engine (Velocity or JSP or
> anything else) and let the templating engine render it. It is
> _completely_ engine independent. In fact it couldn't care less what
> engine is used to _render_ a template.
>
> You won't find a single reference to any templating engine in the
> o.a.turbine.services.template package (besides examples used in the
> comments).
>
> >all these other things that directly use velocity classes. It makes
> no
> >sense.
>
> It makes no sense to you. Because you don't understand the basic
> concepts how Turbine pages are rendered from page, layout and screen
> classes. This is classes. Not templates.
>
> And I do not feel inclined to describe it to you, because you won't
> listen anyway. If you dig in the turbine-users archives, you can find
> a long mail from me where I describe the process (including the
> AssemberBroker and Template Service lookups) in detail.
>
> You're looking at the wrong place. Supporting any other templating
> solution in Turbine is ridiculously easy. That's why we hade at some
> point five of them (Vel, JSP, FM, WM and Jython).
>
> But getting the stuff where Turbine _really_ shines and is superior
> to
> other web frameworks, which is the whole tool mechanism from the pull
> service and the toolbox, is hard. Because the original _Pull_ Service
> was written with Velocity in mind. And this is where the problem
> comes
> from. And this is, why Velocity was always better supported than any
> other templating solution. And this is, why no one bothered to use FM
> and WebMacro with Turbine. And this is, why at some point, the
> support
> for these rotted and was dropped.
>
> I've told this numerous times but you neither listen (hands over your
> ears) nor do you accept it as the truth, but you prefer to believe in
> some obscure Apache conspiracy theory. So be it, I accepted it.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> --- Quote of the week: "It is pointless to tell people anything when
> you know that they won't process the message." --- Jonathan Revusky
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jonathan Revusky <jo...@revusky.com> writes:
>Yeah, I know it's pretty trivial really. But, then the other classes
>should really use the template service abstraction. You shouldn't have
You don't understand what the template service does. You read
"template" and think "template engine". That's your problem. You talk
before you think.
TemplateService is a vastly different beast than "maybe similar named
things in other frameworks". What you think of are Template Engines,
which are in Turbine _completely_ separated out into things like
JspService and VelocityService and register with the TemplateService.
Turbine can use multiple templating engines simultanously. We can have
JSPs and Templates side by side in a single application.
Template Service is mapping template descriptors (like "foo,bar,Baz.vm"
or "yadda,yadda,Yadda.jsp" to a Templating Engine (Velocity or JSP or
anything else) and let the templating engine render it. It is
_completely_ engine independent. In fact it couldn't care less what
engine is used to _render_ a template.
You won't find a single reference to any templating engine in the
o.a.turbine.services.template package (besides examples used in the
comments).
>all these other things that directly use velocity classes. It makes no
>sense.
It makes no sense to you. Because you don't understand the basic
concepts how Turbine pages are rendered from page, layout and screen
classes. This is classes. Not templates.
And I do not feel inclined to describe it to you, because you won't
listen anyway. If you dig in the turbine-users archives, you can find
a long mail from me where I describe the process (including the
AssemberBroker and Template Service lookups) in detail.
You're looking at the wrong place. Supporting any other templating
solution in Turbine is ridiculously easy. That's why we hade at some
point five of them (Vel, JSP, FM, WM and Jython).
But getting the stuff where Turbine _really_ shines and is superior to
other web frameworks, which is the whole tool mechanism from the pull
service and the toolbox, is hard. Because the original _Pull_ Service
was written with Velocity in mind. And this is where the problem comes
from. And this is, why Velocity was always better supported than any
other templating solution. And this is, why no one bothered to use FM
and WebMacro with Turbine. And this is, why at some point, the support
for these rotted and was dropped.
I've told this numerous times but you neither listen (hands over your
ears) nor do you accept it as the truth, but you prefer to believe in
some obscure Apache conspiracy theory. So be it, I accepted it.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Volunteer Opportunity (was Re: Freemarker support)
Posted by Eric Dobbs <er...@dobbse.net>.
On Wednesday, July 16, 2003, at 08:08 AM, Jonathan Revusky wrote:
> First of all, the question was posed on the turbine-user list and
> various people expressed interest in FreeMarker support. IIRC, at
> least three people openly said they would give FM a try if it was
> available within Turbine. Now, that may not sound like a lot of people
> the fact remains that, in open-source projects, one tends to get
> fairly little feedback. If several people openly say they are
> interested in something, it is safe to assume that there are far more
> people who would be interested that you don't know about. Certainly, I
> thought the response was favorable enough that, in your shoes, I would
> assume there was significant interest in FreeMarker -- and possibly
> other alternatives to Velocity.
I don't think the question is about how many *users* are interested
in using FM with Turbine. The critical question is are there any
*developers* who will volunteer to do the work.
Jonathan, thank you for offering to help and for being clear about
where you are willing to help and where you are not willing to help.
Clearly *Someone Else* will have to do some "cleaning" in Turbine
after which you will adjust FM as appropriate. Sounds reasonable to
me.
"Cleaning" could mean code decoupling, or it may mean clearly
documenting an existing place to tie in a template engine. Someone
Else will have to do the work to figure out which it is.
Regardless of what "cleaning" means to anyone, it's pretty clear
that neither Jonathan, nor Dan, nor Henning have any interest in it.
We're all volunteers around here and have the luxury of choosing
which parts of Turbine we want to improve. If you're looking for a
place to contribute, this is a fairly well defined opportunity.
For any of you *developers* who might be interested in volunteering
to do the work, Henning outlined the code that you'll need to study:
TemplateService provides mapping between filenames and template
engines. And the PullService is where Turbine is a little too tied
to Velocity. He also mentioned a posting in the turbine-user mail
archive in which which he detailed the whole process -- that would
be worth digging up.
Good luck.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Daniel Rall <dl...@finemaltcoding.com> writes:
>
>
>>How about "death to bloat! Live long and streamline!"
>
>
>>What color is your soapbox today? (Mine is tan. =)
>
>
> Daniel,
>
> this discussion finally died down on velocity-dev, it would be
> great if we don't continue it here on turbine-dev.
>
> What Mr. Revusky does not understand (because he has his hands over
> his ears and screams at the top of his lungs, that "you must bring
> your house in order" and "you have 21 coupling points to velocity in
> turbine"),
Henning, I do think you're trying to bait me. Finally, I'm replying
nonethless, but simply to address quite calmly the points that I think
need to be addressed.
First of all, I am not screaming that "you must bring house in order".
Far be it from me to "demand" that you do anything with *your* project.
I am simply stating that if you do not get this situation into better
shape, you cannot expect any help from me in terms of any FreeMarker
integration, and it is unreasonable to solicit any help from me, along
the lines of "Submit a patch" and so on.
> that actually Turbine has _one_ coupling point (the rest
> are velocity related classes which can be replaced in a breeze with
> "xxx-templating engine" related classes), which is unfortunately
> embedded deep in another service (not templating related): the Pull
> Service. Changing this (by either using a Map-based interface or an
> adapter class) would mean an user visible break which according to the
> deprecation rules must be pulled over one full release cycle. Actually
> fixing the code is a matter of some minutes.
Yeah, I know it's pretty trivial really. But, then the other classes
should really use the template service abstraction. You shouldn't have
all these other things that directly use velocity classes. It makes no
sense.
>
> The Turbine-3 code base got this right, which is a result of the
> pipeline and the decoupling of Fulcrum. However, this doesn't mean,
> that Turbine-2 can't stea^Wlearn from it. ;-)
>
> This is the same thing as with SecurityService and Torque. The
> SecurityService has a org.apache.torque.Criteria object embedded in
> its interface. This makes it very hard to write a non-torque-dependent
> Security Service implementation.
>
> The problem for some people is, that our two main view types of
> interest (Velocity and JSP) are already supported by Turbine-2 and
> there is no real pressure besides from "special interest groups" to
> get another view logic.
Look, this is a very clear attempt to spin the situation. First of all,
the question was posed on the turbine-user list and various people
expressed interest in FreeMarker support. IIRC, at least three people
openly said they would give FM a try if it was available within Turbine.
Now, that may not sound like a lot of people the fact remains that, in
open-source projects, one tends to get fairly little feedback. If
several people openly say they are interested in something, it is safe
to assume that there are far more people who would be interested that
you don't know about. Certainly, I thought the response was favorable
enough that, in your shoes, I would assume there was significant
interest in FreeMarker -- and possibly other alternatives to Velocity.
Moreover, I do tend to think that the tight coupling with Velocity, at
the moment, makes Turbine less attractive to potential users than it
would be if the framework were truly view-tool-neutral.
In any case, when I say that you are putting "spin" on the situation, it
is not just the above. You see, basically, on first principles, there is
no particular reason to consider that FreeMarker integration is actually
more of a "special interest" than Velocity integration. That Velocity
was set up as the default, and other tools were never really equal
citizens, as it were, that's basically an artificial situation entirely
of the making of the Turbine developers. And, as far as I can see, it is
not something technically based really.
Again, it strikes me as quite dishonest, Henning, to keep on with
variants of this: "Nobody or hardly anybody is interested in FreeMarker
integration" -- when all of your evidence in this regard is based on a
completely rigged comparison, where FreeMarker support in the past only
supported an extremely obsolete version, and obviously nobody was going
to be interested in it. And besides that, the recent evidence (based on
actually asking people on the turbine-user list) is that there is
significant interest in FM support.
Actually, I am quite convinced that, once you offer Velocity and
FreeMarker support on an equal footing, your user base (particularly new
users) will tend to gravitate towards FreeMarker, simply because it is
much more powerful and is being actively developed and maintained.
>
> Working on the pull service is one of the things for post-2.3 to
> me. I'm pretty sure that what will materialize will be able to work
> well with all kinds of templating solutions. Getting the Template
> Service to work with Factories (which are currently wrapped a little
> cumbersome into JspService and VelocityService) is an easy thing and
> after some Avalonziation I'm pretty sure that Turbine will have a View
> engine which is much superior to our current code.
Well, my offer stands. If you get rid of all these points of coupling,
I'll help you within the boundaries of the reasonable. But without that,
it is simply not a reasonable situation, you see. If there are all kinds
of helper classes in the framework that only work with Velocity, then FM
is not competing on an equal footing, since there is functionality
available via Velocity that is not available to the user who opts for
FreeMarker.
What this means is that the overall Turbine codebase should not use
Velocity classes directly, but rather, the abstracted TemplateEngine API
that potentially encapasulates Velocity, FreeMarker, and other tools.
Anyway, I never demanded or screamed that you had to do anything. I
simply stated the conditions under which it would make sense for me to
help you on this front. I further said that if you got rid of all these
points of coupling with Velocity classes, I would do my part to get the
FM integration working. Now, I do wish you would stop playing games and
attempting to spin and distort everything that is going on, and portray
me as some kind of lunatic. I am satisfied that anybody who reflects
seriously on what I am saying will realize that my position is
emininently sane and reasonable.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
>
> Regards
> Henning
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@finemaltcoding.com> writes:
Hi,
>This raises the question of exactly how to change it down the road.
>My interest in the jakarta-turbine-2 repo is focused on the future, as
>I want to see the appropriate parts of jakarta-turbine-3 repo merged
>into it (and plan on helping with that when the time is right).
Cool. I'll get back to you on this. ;-)
>The decoupling of Fulcrum is definitely beneficial. The introduction
>of the pipeline is great, offering many hooks for plugging in
>additional functionality. As suggested by Ilka (a la Tami), I
>recommend providing a Servlet API 2.3 Filter facade for it when it is
>merged back into the next release of the jakarta-turbine-2. This will
>provided better inter-op with today's popular technologies.
Going API 2.3-only probably makes sense. We already have a service (Session
Service) which requires 2.3.
>However, as a developer and user of Turbine 3 + Fulcrum, I must
>protest that the TemplateEngineService contains unnecessary complexity
>that should be simplified before coming anywhere near the
>jakarta-turbine-2 repo.
You might want to take a look at the Turbine TemplateService. I
rewrote it early this year and moved all the mappers out into mapper
classes. I'd consider the Turbine code much cleaner than the
Fulcrum-one. However, the Fulcrum code has less core dependencies,
because it is developed with clean interfaces from the Core.
[...]
>Shall we codify this policy? Something like:
> Support for new view engines will only be considered when there is
> both demand from the user community and a Turbine developer (new or
> existing) who has agreed to maintain it. Support is likely to be
> dropped if there is no one available to do maintainence and there
> are a proliferation of defect reports.
>How's that sound?
I don't like to "set these things in stone". If someone shows up that
donates support for a templating engine and it is done in a clean way,
I don't see no reason not to add it. And if it's done right, it won't
fall prey to code rot as WebMacro and FreeMarker Support did.
[...]
>Yup. If you find the time to follow up to my response to Jonathan's
>suggested template system abstraction, I'd be happy to take any
>feedback into consideration, Avalonize it, and check that
>ContentGenerationSystem in as a proprosal for the next major release.
I've read it. One thing I want to avoid is to fall into the Turbine-3
trap: Putting too many major changes into one release:
Basically, people that were struggling with Turbine-2 had to adapt to
a new code structure (Turbine-2 -> Turbine-3, Fulcrum), lots of
code-breakout and repackaging (Torque, Stratum, JCS, Fulcrum, lots of
commons-stuff) which partly were simply a wrong way and abandoned
half-baked (JCS, Stratum), a new core concept (Pipeline) and an ever
breaking build tool (The beginnings of Maven, where Jason was using
the Turbine repositories as his "testbed" (as he stated on one of the
mailing lists some time ago)) and almost non-existed docs.
In the end, most people simply gave up on the Turbine-3 code base,
except those who really helped developing it. That's why there are
almost no active Turbine-3 users (these seem to be jmcnally and
you. Ilka went Tami, JvZ went Maven, Plexus, Summit, jon went
somewhere completely else). Abandoning the user base with a
half-finished project (which would have gone in the direction of
Velocity if not a new generation of developers (mpoeschl, quinton,
eric, yours truly) had cropped up) would have been a real shame as
Turbine is IMHO one of the most-underestimated Jakarta projects.
BTW: Something I read some days ago: This is from the O'Reilly book
"Programming Jakarta Struts", p.15
--- cut ---
Jakarta Turbine
Turbine is a servlet-based framework and an open source Jakarta
project. Currently, there isn't a great deal of documentation for
Turbine, but it seems to be similar to Struts, with a few major
differences. For one thing, it doesn't seem to be coupled to JSP. The
focus of Turbine appears to be to provide a collection of reusable
components. A large set of components is included with the framework,
but they are quite disparate. It seems to present more of a component
library, but as it's lacking documentation, it's hard to get a good
feel for the complete architecture. More information can be found at
http://jakarta.apache.org/turbine/.
--- cut ---
This sums the state of the current Turbine pretty nicely. "Cool stuff
but noone knows about it, because the docs are lacking".
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
...
> What Mr. Revusky does not understand (because he has his hands over
> his ears and screams at the top of his lungs, that "you must bring
> your house in order" and "you have 21 coupling points to velocity in
> turbine"), that actually Turbine has _one_ coupling point (the rest
> are velocity related classes which can be replaced in a breeze with
> "xxx-templating engine" related classes), which is unfortunately
> embedded deep in another service (not templating related): the Pull
> Service. Changing this (by either using a Map-based interface or an
> adapter class) would mean an user visible break which according to the
> deprecation rules must be pulled over one full release cycle. Actually
> fixing the code is a matter of some minutes.
This raises the question of exactly how to change it down the road.
My interest in the jakarta-turbine-2 repo is focused on the future, as
I want to see the appropriate parts of jakarta-turbine-3 repo merged
into it (and plan on helping with that when the time is right).
> The Turbine-3 code base got this right, which is a result of the
> pipeline and the decoupling of Fulcrum. However, this doesn't mean,
> that Turbine-2 can't stea^Wlearn from it. ;-)
The decoupling of Fulcrum is definitely beneficial. The introduction
of the pipeline is great, offering many hooks for plugging in
additional functionality. As suggested by Ilka (a la Tami), I
recommend providing a Servlet API 2.3 Filter facade for it when it is
merged back into the next release of the jakarta-turbine-2. This will
provided better inter-op with today's popular technologies.
However, as a developer and user of Turbine 3 + Fulcrum, I must
protest that the TemplateEngineService contains unnecessary complexity
that should be simplified before coming anywhere near the
jakarta-turbine-2 repo.
> This is the same thing as with SecurityService and Torque. The
> SecurityService has a org.apache.torque.Criteria object embedded in
> its interface. This makes it very hard to write a non-torque-dependent
> Security Service implementation.
Yes.
> The problem for some people is, that our two main view types of
> interest (Velocity and JSP) are already supported by Turbine-2 and
> there is no real pressure besides from "special interest groups" to
> get another view logic.
Shall we codify this policy? Something like:
Support for new view engines will only be considered when there is
both demand from the user community and a Turbine developer (new or
existing) who has agreed to maintain it. Support is likely to be
dropped if there is no one available to do maintainence and there
are a proliferation of defect reports.
How's that sound?
> Working on the pull service is one of the things for post-2.3 to
> me. I'm pretty sure that what will materialize will be able to work
> well with all kinds of templating solutions. Getting the Template
> Service to work with Factories (which are currently wrapped a little
> cumbersome into JspService and VelocityService) is an easy thing and
> after some Avalonziation I'm pretty sure that Turbine will have a View
> engine which is much superior to our current code.
Yup. If you find the time to follow up to my response to Jonathan's
suggested template system abstraction, I'd be happy to take any
feedback into consideration, Avalonize it, and check that
ContentGenerationSystem in as a proprosal for the next major release.
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@finemaltcoding.com> writes:
>How about "death to bloat! Live long and streamline!"
>What color is your soapbox today? (Mine is tan. =)
Daniel,
this discussion finally died down on velocity-dev, it would be
great if we don't continue it here on turbine-dev.
What Mr. Revusky does not understand (because he has his hands over
his ears and screams at the top of his lungs, that "you must bring
your house in order" and "you have 21 coupling points to velocity in
turbine"), that actually Turbine has _one_ coupling point (the rest
are velocity related classes which can be replaced in a breeze with
"xxx-templating engine" related classes), which is unfortunately
embedded deep in another service (not templating related): the Pull
Service. Changing this (by either using a Map-based interface or an
adapter class) would mean an user visible break which according to the
deprecation rules must be pulled over one full release cycle. Actually
fixing the code is a matter of some minutes.
The Turbine-3 code base got this right, which is a result of the
pipeline and the decoupling of Fulcrum. However, this doesn't mean,
that Turbine-2 can't stea^Wlearn from it. ;-)
This is the same thing as with SecurityService and Torque. The
SecurityService has a org.apache.torque.Criteria object embedded in
its interface. This makes it very hard to write a non-torque-dependent
Security Service implementation.
The problem for some people is, that our two main view types of
interest (Velocity and JSP) are already supported by Turbine-2 and
there is no real pressure besides from "special interest groups" to
get another view logic.
Working on the pull service is one of the things for post-2.3 to
me. I'm pretty sure that what will materialize will be able to work
well with all kinds of templating solutions. Getting the Template
Service to work with Factories (which are currently wrapped a little
cumbersome into JspService and VelocityService) is an easy thing and
after some Avalonziation I'm pretty sure that Turbine will have a View
engine which is much superior to our current code.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>>Daniel Rall wrote:
>>
>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>
>>>>Daniel Rall wrote:
>
>
> You tried to play this game on velocity-dev, now you're trying to play
> it here. For someone that "does not care about these projects
> (Turbine, Velocity)" and that is actively hostile towards the ASF (I
> read some of your comments on the FM mailing lists), you spend an
> awful lot of time on these lists.
I don't know what you're talking about, Henning.
Daniel referred to my post as "shlock". I asked Daniel what he meant by
that, i.e. to back up his statement.
This situation is quite simple really: you are not Daniel, you have no
business answering.
You guys are just desperately trying to bait and provoke me and I kind
of understand why, but really, you're not very good at it. It's just a
tad too obvious.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Regards
> Henning
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jonathan Revusky <jo...@revusky.com> writes:
>Daniel Rall wrote:
>> Jonathan Revusky <jo...@revusky.com> writes:
>>>Daniel Rall wrote:
You tried to play this game on velocity-dev, now you're trying to play
it here. For someone that "does not care about these projects
(Turbine, Velocity)" and that is actively hostile towards the ASF (I
read some of your comments on the FM mailing lists), you spend an
awful lot of time on these lists.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>Daniel Rall wrote:
>>
>>>I'm impressed that you actually have the nerve to talk about spin when
>>>you're shoveling out shlock like this.
>
> ...
>
>>Daniel, I think that you really ought to specify in what way it's "shlock".
>
> ...
>
> When you don't know, you fill in as you like.
That's maybe how you approach things, Daniel, but when *I* don't know, I
ask for clarification from the person who made the statement.
You're the one who claimed it was "shlock" so you're the one who is
supposed to back it up. Certainly, not *me* of all people...
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jonathan Revusky <jo...@revusky.com> writes:
> Daniel Rall wrote:
> > I'm impressed that you actually have the nerve to talk about spin when
> > you're shoveling out shlock like this.
...
> Daniel, I think that you really ought to specify in what way it's "shlock".
...
When you don't know, you fill in as you like.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [OT] Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> I'm impressed that you actually have the nerve to talk about spin when
> you're shoveling out shlock like this.
<sigh>
Daniel, I think that you really ought to specify in what way it's "shlock".
You know, if what I've said is so flawed logically and/or factually, you
should be able to take apart my arguments quite easily.
But your response strongly suggests to me (and not just to me, I don't
think) that you can't do that, so you're reduced to this kind of
hand-waving. Kind of sad, really....
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
> Ever considered a career in
> politics?
>
> - Dan
>
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>Daniel Rall wrote:
>>
>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>
>>
>>>>Daniel Rall wrote:
>>>>
>>>>
>>>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>>>
>>>>>
>>>>>>One striking thing about Velocity IMO is how technically unambitious
>>>>>>it was.
>>>>>
>>>>>Isn't it wonderful? One of my favorite aspects.
>>>>
>>>>Yeah. Death to excellence! Long live mediocrity!
>>>
>>>How about "death to bloat! Live long and streamline!"
>>
>>
>>Well, the concerns about feature bloat have some basis. However, your
>>comment makes me uneasy.
>>
>>
>>I mean, there's a question of setting up the right criteria of
>>evaluation. Suppose a teacher announces that the sole criterion for
>>grading an exam is the fewer mistakes made, the better. Well, the
>>clever (but lazy) student will realize that there is a very easy way
>>of having a perfect exam -- he can turn in a blank examination
>>booklet. Since that obviously contains no errors, it must logically
>>receive the highest possible grade. And of course, once one realizes
>>that one can receive a perfect grade by returning an blank
>>examination, there is hardly much reason to study or even to attend
>>class, right?
>>
>>
>>Similarly, if you set up the lack of "feature bloat" as this great
>>virtue, then it would seem that you can achieve maximal levels of
>>virtue by simply never adding any features. Or to put it more crudely,
>>by doing absolutely nothing -- i.e. squat, nichts, nada, zilch.
>>
>>
>>A similar sort of thing occurred in recent dialogue. Recently, various
>>people were criticizing FreeMarker on the basis of backward
>>incompatibilities that were introduced (mainly FM 1.x->2.0 and
>>2.0->2.1, since then, the 2.2 and 2.3 release cycles, it's been fairly
>>good on that front) and even contrasting that unfavorably with
>>Velocity. Well, it's a similar sort of thing: to achieve your perfect
>>backward compatibility by simply not releasing any new
>>versions... what kind of achievement is that?
>>
>>
>>Now, it's not that the concerns about feature bloat or backward
>>incompatibilities are unjustified. In the course of the ongoing
>>maintenance and development of an open-source project, there is some
>>danger of indiscriminately giving in to every special-interest feature
>>suggestion and ending up with something that is bloated and full of
>>features that nobody uses. However, it often does happen that a user
>>will point out an idea for a new feature that is really just generally
>>useful and should be added because it makes the tool better. As
>>regards backward incompatibilities, sometimes you end up running into
>>the fact that bad design decisions were made and you have a choice
>>between kludgy workarounds that maintain backward compatibility or
>>making some kind of break with the past and imposing some upgrade cost
>>on people.
>>
>>
>>These are issues that require some fine judgment and there are no easy
>>answers. But, at least, I have to say that I reject the A-1-A easy
>>answer, which is that you avoid feature bloat by simply never adding
>>any features, or that you avoid backward incompatibility by simply
>>never having a new version.
>>
>>
>>It's too obviously absurd. It sets the bar too low.
>>
>>
>>>What color is your soapbox today? (Mine is tan. =)
>>
>>
>>I don't know. Independently of the color of the soapbox you're
>>standing on, you're in a very weak position defending the current
>>state of the Velocity project. That that project is in a pretty
>>disastrous state is pretty much an open secret at this point, and,
>>basically, to put it crudely, you're not fooling anybody, Daniel.
>>
>>
>>Best Regards,
>>
>>Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
[OT] Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
I'm impressed that you actually have the nerve to talk about spin when
you're shoveling out shlock like this. Ever considered a career in
politics?
- Dan
Jonathan Revusky <jo...@revusky.com> writes:
> Daniel Rall wrote:
> > Jonathan Revusky <jo...@revusky.com> writes:
> >
>
> >>Daniel Rall wrote:
> >>
> >>>Jonathan Revusky <jo...@revusky.com> writes:
> >>>
> >>>>One striking thing about Velocity IMO is how technically unambitious
> >>>>it was.
> >>>
> >>>Isn't it wonderful? One of my favorite aspects.
> >>
> >>Yeah. Death to excellence! Long live mediocrity!
> > How about "death to bloat! Live long and streamline!"
>
>
> Well, the concerns about feature bloat have some basis. However, your
> comment makes me uneasy.
>
>
> I mean, there's a question of setting up the right criteria of
> evaluation. Suppose a teacher announces that the sole criterion for
> grading an exam is the fewer mistakes made, the better. Well, the
> clever (but lazy) student will realize that there is a very easy way
> of having a perfect exam -- he can turn in a blank examination
> booklet. Since that obviously contains no errors, it must logically
> receive the highest possible grade. And of course, once one realizes
> that one can receive a perfect grade by returning an blank
> examination, there is hardly much reason to study or even to attend
> class, right?
>
>
> Similarly, if you set up the lack of "feature bloat" as this great
> virtue, then it would seem that you can achieve maximal levels of
> virtue by simply never adding any features. Or to put it more crudely,
> by doing absolutely nothing -- i.e. squat, nichts, nada, zilch.
>
>
> A similar sort of thing occurred in recent dialogue. Recently, various
> people were criticizing FreeMarker on the basis of backward
> incompatibilities that were introduced (mainly FM 1.x->2.0 and
> 2.0->2.1, since then, the 2.2 and 2.3 release cycles, it's been fairly
> good on that front) and even contrasting that unfavorably with
> Velocity. Well, it's a similar sort of thing: to achieve your perfect
> backward compatibility by simply not releasing any new
> versions... what kind of achievement is that?
>
>
> Now, it's not that the concerns about feature bloat or backward
> incompatibilities are unjustified. In the course of the ongoing
> maintenance and development of an open-source project, there is some
> danger of indiscriminately giving in to every special-interest feature
> suggestion and ending up with something that is bloated and full of
> features that nobody uses. However, it often does happen that a user
> will point out an idea for a new feature that is really just generally
> useful and should be added because it makes the tool better. As
> regards backward incompatibilities, sometimes you end up running into
> the fact that bad design decisions were made and you have a choice
> between kludgy workarounds that maintain backward compatibility or
> making some kind of break with the past and imposing some upgrade cost
> on people.
>
>
> These are issues that require some fine judgment and there are no easy
> answers. But, at least, I have to say that I reject the A-1-A easy
> answer, which is that you avoid feature bloat by simply never adding
> any features, or that you avoid backward incompatibility by simply
> never having a new version.
>
>
> It's too obviously absurd. It sets the bar too low.
>
> > What color is your soapbox today? (Mine is tan. =)
>
>
> I don't know. Independently of the color of the soapbox you're
> standing on, you're in a very weak position defending the current
> state of the Velocity project. That that project is in a pretty
> disastrous state is pretty much an open secret at this point, and,
> basically, to put it crudely, you're not fooling anybody, Daniel.
>
>
> Best Regards,
>
> Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>Daniel Rall wrote:
>>
>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>
>>>>One striking thing about Velocity IMO is how technically unambitious
>>>>it was.
>>>
>>>Isn't it wonderful? One of my favorite aspects.
>>
>>Yeah. Death to excellence! Long live mediocrity!
>
>
> How about "death to bloat! Live long and streamline!"
Well, the concerns about feature bloat have some basis. However, your
comment makes me uneasy.
I mean, there's a question of setting up the right criteria of
evaluation. Suppose a teacher announces that the sole criterion for
grading an exam is the fewer mistakes made, the better. Well, the clever
(but lazy) student will realize that there is a very easy way of having
a perfect exam -- he can turn in a blank examination booklet. Since that
obviously contains no errors, it must logically receive the highest
possible grade. And of course, once one realizes that one can receive a
perfect grade by returning an blank examination, there is hardly much
reason to study or even to attend class, right?
Similarly, if you set up the lack of "feature bloat" as this great
virtue, then it would seem that you can achieve maximal levels of virtue
by simply never adding any features. Or to put it more crudely, by doing
absolutely nothing -- i.e. squat, nichts, nada, zilch.
A similar sort of thing occurred in recent dialogue. Recently, various
people were criticizing FreeMarker on the basis of backward
incompatibilities that were introduced (mainly FM 1.x->2.0 and 2.0->2.1,
since then, the 2.2 and 2.3 release cycles, it's been fairly good on
that front) and even contrasting that unfavorably with Velocity. Well,
it's a similar sort of thing: to achieve your perfect backward
compatibility by simply not releasing any new versions... what kind of
achievement is that?
Now, it's not that the concerns about feature bloat or backward
incompatibilities are unjustified. In the course of the ongoing
maintenance and development of an open-source project, there is some
danger of indiscriminately giving in to every special-interest feature
suggestion and ending up with something that is bloated and full of
features that nobody uses. However, it often does happen that a user
will point out an idea for a new feature that is really just generally
useful and should be added because it makes the tool better. As regards
backward incompatibilities, sometimes you end up running into the fact
that bad design decisions were made and you have a choice between kludgy
workarounds that maintain backward compatibility or making some kind of
break with the past and imposing some upgrade cost on people.
These are issues that require some fine judgment and there are no easy
answers. But, at least, I have to say that I reject the A-1-A easy
answer, which is that you avoid feature bloat by simply never adding any
features, or that you avoid backward incompatibility by simply never
having a new version.
It's too obviously absurd. It sets the bar too low.
>
> What color is your soapbox today? (Mine is tan. =)
I don't know. Independently of the color of the soapbox you're standing
on, you're in a very weak position defending the current state of the
Velocity project. That that project is in a pretty disastrous state is
pretty much an open secret at this point, and, basically, to put it
crudely, you're not fooling anybody, Daniel.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Velocity->FreeMarker template conversion tool,
http://freemarker.org/usCavalry.html
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jonathan Revusky <jo...@revusky.com> writes:
> Daniel Rall wrote:
> > Jonathan Revusky <jo...@revusky.com> writes:
> >>One striking thing about Velocity IMO is how technically unambitious
> >>it was.
> > Isn't it wonderful? One of my favorite aspects.
>
> Yeah. Death to excellence! Long live mediocrity!
How about "death to bloat! Live long and streamline!"
What color is your soapbox today? (Mine is tan. =)
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Daniel Rall wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
> ...
>
>>>--- cut ---
>>
>>>Velocity was built new from the ground up. There isn't a snippet of
>>>shared code. This was originally done because WebMacro was released
>>>under a license (GPL) that is not compatible with the BSD/ASF license
>>>and we (the original authors) needed a solution that was not under a
>>>GPL license. Since then, WebMacro has been released under a dual
>>>GPL/ASF license, however, that was too late, this project was already
>>>well underway and we also felt that we have a better technical
>>>solution by going with a generated parser instead of a hand coded one.
>>>--- cut ---
>>
>>Weeeell, this license story as the driving thing could have some truth
>>to it.
>
>
> How magnanimous of you.
Look, Daniel. It's basically an open secret that the Vel-WM rift took
place mostly because of personality issues. I was even looking in my old
archived personal email and I realized that I have personal email
correspondance in which both Vel and WM people, when alluding to these
events, basically take as a given that the whole thing occurred for
personal, non-technical reasons.
>
>
>>OTOH, that they so desperately needed all of a sudden a version
>>of WM that was under the Apache License -- while possible, is
>>surprising nonetheless. I dunno. I don't see how there was much of an
>>issue in terms of just using WM with no alterations as a 3rd party
>>lib.
>
>
> You seem to be under the delusion that Velocity is technically
> lacking.
I think you're under the delusion that it isn't. :-)
> You should've seen WebMacro three years ago! One couldn't
> get away without patching it, in turn complicating its redistribution.
>
>
>>They surely wanted to get the thing out there and used by a lot of
>>people. And, as noted above, the WM people did ultimately just give
>>in on the license issue. It's available under a BSD-style license.
>
>
> You've a habit of pointing out the reason for that, even if you don't
> associate it with licensing.
>
>
>>One striking thing about Velocity IMO is how technically unambitious
>>it was.
>
>
> Isn't it wonderful? One of my favorite aspects.
>
Yeah. Death to excellence! Long live mediocrity!
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org