You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Quinton McCombs <qm...@nequalsone.com> on 2003/06/20 20:42:24 UTC
Freemarker support (was: RE: Decimal Number support)
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Jonathan Revusky
> Sent: Friday, June 20, 2003 12:19 PM
> To: turbine-user@jakarta.apache.org
> Subject: Re: Decimal Number support
>
>
> Quinton McCombs wrote:
> >>-----Original Message-----
> >>From: news [mailto:news@main.gmane.org] On Behalf Of
> Jonathan Revusky
> >>Sent: Friday, June 20, 2003 9:55 AM
> >>To: turbine-user@jakarta.apache.org
> >>Subject: Re: Decimal Number support
> >>
> >>
<snip>
>
> >
> > I was not around for the discussions of why things were
> done as they
> > were. I don't really care to know either. If I had to guess, the
> > active developers at the time used Velocity and were happy with it.
>
> Well, I'm only moderately familiar with all this, but I do happen to
> know that the original author of Velocity is really Jon Scott
> Stevens,
> who was also main developer of Turbine originally. Velocity began
> basically as a WebMacro clone, which was written by Jon because there
> was some personal falling-out between him and Justin Wells,
> the original
> WM author. WM was slated to become a Jakarta project, but
> then JS wrote
> a clone that became Velocity. In fact, in its earlier incarnations, I
> believe that Turbine supported WM and FM. WM was supposed to become a
> Jakarta project, but then JS wrote Velocity, probably as a kind of
> in-your-face one-upsmanship sort of thing.
>
> After that, I think the support for multiple template engines was
> something of a farce. Velocity usage was favored
> intentionally. The FM
> support was never kept up-to-date despite the absolutely
> minimal effort
> it would have required. I think you can definitely say that
> the emphasis
> on Velocity and the coupling you refer to was not something that came
> about based on purely technical considerations.
Hmmm... Interesting history. I can see how that might have happened.
Just like you like to actively promote your project, it would make
perfect sense that Jon, perhaps, saw no reason to provide robust support
for anything besides Velocity. In his eyes, and probabley many other at
the time, Velocity was _the_ answer.
You are correct about the WebMacro stuff. There is still comments in
the code used for Velocity support indicating the the code was
originally copied from a WebMacro version and adpated for Velocity. It
is rather clear which came first.
> I understand perfectly well that you and Henning had nothing
> to do with
> all this. Of course, given that, I don't see why you feel the
> slightest
> need to defend any of the prior foolishness.
Perhaps it does come across as defensiveness. We just did not agree
with your conclusion of why support was removed. You seemed to take it
as a negative reflection on the quality or robustness of your product.
Consider for a moment that perhaps that was not the case.
If it was really because it was so badly implemented within Turbine,
there were almost no active developers or contributors at the time, a
generaly lack of knowledge reguarding the improvements in FM, etc.....
Since this is one of the points that seemed to offend you, I just want
you to consider that maybe there were good reasons for dropping support.
Granted the argument of "it's being used by anyone" was invalid because
the support was so poor that no one could use it. However, that might
not have been the motivating reason.
Like I have said earlier, I like what I see in your product. I would
very much like to see support for FM in Turbine. Personally, I do not
really like velocity. However, since nothing else is supported with
Turbine very well, I am forced to deal with it.
Given that I would like to see support for FM in Turbine, it becomes
beneficial to have a good relationship with the developers of FM. This
is the reason that I am taking the effort to explain all of this. I
would hope that once one of us has the time to start looking into
supporting FM, that we will be able to get assistance when it becomes
needed.
> > Now, I understand that FM will be able to transparently use
> a Velocity
> > context object. We _could_ take that approach and put FM
> support back
> > into Turbine fairly quickly. Personally, the idea seems
> revolting to
> > me. From a design perspective, I would wonder what the
> developer was
> > smoking who implemented FM support using a Velocity context object.
>
> I asked Henning in the message that he flamed me over whether this
> VelocityContext thing was the only real sticking point. I
> don't believe
> he answered. If it is, I just don't think it's a big deal.
There are other services which are tightly coupled with out Velocity
service as well. This is really where Hennning has been doing a great
deal of clean up work. He is probabley correct about it being a
significant level of effort to provide all of the fucntionality that we
currently have with Velocity in FM.
I am not as familiar with that code as he is. Perhaps it will not be as
big of a deal as it might seem at just the first look. I do intend on
looking into this myself since I am interested in trying out FM.
> Frankly, I think you probably should implement the solution I
> gave you.
> It actually *looks* much more screwy than it is. You see, you
> can pass
> in a java.util.HashMap to FM and it converts it transparently to the
> internal thing it needs. Using the same ObjectWrapper API. For all of
> it, a VelocityContext is just a hashtable. That, for
> historical reasons,
> you're using VelocityContext there instead of
> java.util.HashMap or some
> other thing, is really kind of a little wrinkle.
Point taken. There are other issues like our PullService which is very
tightly integrated with Velocity. We would need to come up with a way
to address that.
> It's like something that *looks* like bad design, but is more like a
> little implementation wrinkle. As for being concerned about
> what other
> people will think when they see that, that's.... maybe.... (a
> bit silly ;-))
Fair enough. I have been accused of being a little anal about things at
times.
> >
> > I am not opposed to putting FM support back into Turbine. I have
> > looked over the docs and I am quite imnpressed with the product. I
> > think that it would benefit our users to have something other than
> > Velocity to choose from on the view layer. Granted, there
> is JSP but
> > the support for that is not on par with Velocity.
> >
> > I do not want to see another quick hack put into this project. We
> > need to take a step back and decide how we are going to restructure
> > the inner workings to allow for multiple view technologies
> all having
> > equal integration into our product. If we do this
> correctly, we can
> > not only easily add FM support but support for other
> choices as well.
>
> Well, basically, the XP principle of doing the simplest thing
> that works
> until a need is proven for something more sophisticated
> should probably
> apply. I mean, the obsessive desire with doing the grand
> theoretically
> correct refactoring strikes me as possibly counterproductive in this
> instance.
Except for the fact that we need to improve the JSP support as well. We
still have users asking how to implement JSP with Turbine. There is
clearly a demand for it. In order to support FM, Velocity, and JSP with
equal functionality, we do need to take a step back and come up with a
common approach that works for each other them. I suppose that proves a
need for something more sophisticated.
On the other hand, it might make sense to try and integrate FM without
considering the needs of JSP for the first implementation. It will
allow for us to get a better feel for how FM works.
> At the end of the day, any object you use as the root of the
> data model
> is just a hashtable. VelocityContext is as good a hashtable as any
> other, probably.
>
> If you were going from scratch, you wouldn't do it that way,
> but given
> the corner you've been painted into, I think you might as
> well go that
> route now.
>
> And the other thing I wonder is why you can't just use
> java.util.Object
> where you were using VelocityContext. Then the Velocity-specific
> implementation could cast it to VelocityContext. The FM
> implementation
> could deal with the VelocityContext transparently, and other
> solutions
> would need a different kind of object passed in, but you
> could deal with
> that later when the need shows up.
If we provide FM support before we rework the view integration code,
there might not be much work needed at all. The only thing that is
unclear to me is how we will provide for pull tools in FM. Without
digging through the docs, perhaps you can shed a little light on this.
Our pull service allows you to write tools that are available for use
inside of the template. The tools are initialized and put into the
Velocity context. On the template, the tools are referenced by some
configurable name like $link. To Create a URL using this tool the code
looks something like $link.setPage("myPage.vm").
I userstand that you do expose java object to the template but not by
using reflection. Could you briefly explain how my javabean used in the
previous example would work in FM?
>
> These are the 2 basic things that got my back up:
>
> 1. This stuff about everybody having chosen Velocity and
> nobody wanting
> FM -- this seems very dishonest to me, because the two things
> were never
> competing on an equal footing. It's a contrived argument based on a
> rigged situation.
But I think your problem with it seemed to revolve around the belief
that it was rigged make a competing product look better than yours. It
certainly was not a fair question to ask the users for obvious reasons.
However, as I stated earlier, perhaps there was nothing underhanded
going on at all.
> 2. The implicit idea that I am the one in a supplicant
> position asking
> *you* for something. "If you want the FM support in there, submit a
> patch".
Come on now. This is a common first reaction from many OSS
developers.... Granted, it is usually the wrong response.
> Quite literally, there seems to be this idea that, by
> leveraging
> *our* community's hard work, you are doing *us* a favor. You can deny
> that this was ever insinuated, but I have inferred this subtext.
Maybe that is what he meant. Maybe it was not. Perhaps he simply
thought that you were asking for support to be added and so he offered
to let you implement it. There could have been a misunderstanding on
both sides.
> To be brutally honest, Turbine gains a lot more from FM
> integration than
> we do. You say you've looked through the FM docs, so I think you know
> that what I'm saying is true. And the truth should be
> something that is
> respected.
The real truth is that we both have something to gain. You get a little
more wider acceptance. We get to offer our users more freedom in
implementing the view layer. Perhaps even a more powerful and robust
option.
> Anyway, my honest advice to you guys is to put in the support
> the quick,
> easy way. It's a bit screwball, but it's not particularly bad on
> design/architectural grounds. I really don't think so. It's
> mostly just
> annoying on aesthetic grounds, not pragmatic ones.
I do agree with you on that. My point with using the Context object in
FM support was aesthetic. Like I said, I can be a little anal at times.
> Best Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-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 Jonathan Revusky <jo...@revusky.com>.
Quinton McCombs wrote:
<snip>
>>I think you can definitely say that
>>the emphasis
>>on Velocity and the coupling you refer to was not something that came
>>about based on purely technical considerations.
>
>
> Hmmm... Interesting history. I can see how that might have happened.
> Just like you like to actively promote your project, it would make
> perfect sense that Jon, perhaps, saw no reason to provide robust support
> for anything besides Velocity. In his eyes, and probabley many other at
> the time, Velocity was _the_ answer.
Well, they wanted people to perceive Velocity as _the_ (sole) answer.
>
> You are correct about the WebMacro stuff. There is still comments in
> the code used for Velocity support indicating the the code was
> originally copied from a WebMacro version and adpated for Velocity. It
> is rather clear which came first.
This is well known.
>
>
>>I understand perfectly well that you and Henning had nothing
>>to do with
>>all this. Of course, given that, I don't see why you feel the
>>slightest
>>need to defend any of the prior foolishness.
>
>
> Perhaps it does come across as defensiveness.
Well, I earlier made rather harsh comments about saving the energy
expended in bullshitting one another. They're harsh comments, but I
think they apply in this instance.
There is no particular reason for you to try to come up with
rationalizations for bonehead decisions that you were not part of. It is
a waste of energy.
> We just did not agree
> with your conclusion of why support was removed. You seemed to take it
> as a negative reflection on the quality or robustness of your product.
> Consider for a moment that perhaps that was not the case.
Not to worry. I never took it as a negative reflection on the quality or
robustness or our product. And why would I? For one thing, the extremely
obsolete version of FM you were supporting was not even my work. I have
been the main developer in all the FreeMarker 2.x cycles -- 2.0, 2.1,
2.2, and now 2.3. The version of FM you were supporting was 1.5.2, I
think. Also, by people's own admission, they never even looked at
current versions of FreeMarker when deciding to remove support.
>
> If it was really because it was so badly implemented within Turbine,
> there were almost no active developers or contributors at the time, a
> generaly lack of knowledge reguarding the improvements in FM, etc.....
Well, again, in the above, there seems to be an attempt to put spin on
things. I think you should refrain from that.
The fact remains that if you (or whoever) lacked knowledge about what
was going on in FM, that was really by your own choice, wasn't it?
I mean, why didn't anyone look at the FreeMarker website and make some
comparisons? Why was the decision made to remove FM support (as opposed
to bringing it up-to-date) in favor of Velocity without comparing the
state of the 2 tools and the underlying development efforts?
The above are not accusations. They are questions that only the
people involved can answer.
Now, my take on this is that there is something of a "we are the world"
sort of bias in Jakarta/ASF culture. It really is a bit like non-ASF
projects don't quite really exist for you guys. That bias would explain
why a decision was made to remove FM support (as opposed to making the
minimal effort to keep it up-to-date) *without* even looking at the
state of the project.
>
> Since this is one of the points that seemed to offend you, I just want
> you to consider that maybe there were good reasons for dropping support.
> Granted the argument of "it's being used by anyone" was invalid because
> the support was so poor that no one could use it. However, that might
> not have been the motivating reason.
>
> Like I have said earlier, I like what I see in your product. I would
> very much like to see support for FM in Turbine. Personally, I do not
> really like velocity. However, since nothing else is supported with
> Turbine very well, I am forced to deal with it.
Well, this is a problem, and I think it is damaging to Turbine at this
point.
>
> Given that I would like to see support for FM in Turbine, it becomes
> beneficial to have a good relationship with the developers of FM. This
> is the reason that I am taking the effort to explain all of this. I
> would hope that once one of us has the time to start looking into
> supporting FM, that we will be able to get assistance when it becomes
> needed.
Well, there is no particular cause for concern here. The FM community
really is pretty responsive when people ask for help on this kind of thing.
<snip>
> There are other services which are tightly coupled with out Velocity
> service as well. This is really where Hennning has been doing a great
> deal of clean up work. He is probabley correct about it being a
> significant level of effort to provide all of the fucntionality that we
> currently have with Velocity in FM.
>
> I am not as familiar with that code as he is. Perhaps it will not be as
> big of a deal as it might seem at just the first look. I do intend on
> looking into this myself since I am interested in trying out FM.
My own experience is that supporting multiple template engines from a
web app framework tends to be rather trivial.
<snip>
>
>
> If we provide FM support before we rework the view integration code,
> there might not be much work needed at all. The only thing that is
> unclear to me is how we will provide for pull tools in FM. Without
> digging through the docs, perhaps you can shed a little light on this.
What is a "pull tool"? You mean you just expose a javabean to the
context and you invoke methods on it? Well, you can do that perfectly
well from FM.
>
> Our pull service allows you to write tools that are available for use
> inside of the template. The tools are initialized and put into the
> Velocity context. On the template, the tools are referenced by some
> configurable name like $link. To Create a URL using this tool the code
> looks something like $link.setPage("myPage.vm").
>
> I userstand that you do expose java object to the template but not by
> using reflection. Could you briefly explain how my javabean used in the
> previous example would work in FM?
See:
http://freemarker.org/docs/pgui_misc_beanwrapper.html
You can expose an object with full reflection if you want.
>
>
>>These are the 2 basic things that got my back up:
>>
>>1. This stuff about everybody having chosen Velocity and
>>nobody wanting
>>FM -- this seems very dishonest to me, because the two things
>>were never
>>competing on an equal footing. It's a contrived argument based on a
>>rigged situation.
>
>
> But I think your problem with it seemed to revolve around the belief
> that it was rigged make a competing product look better than yours. It
> certainly was not a fair question to ask the users for obvious reasons.
> However, as I stated earlier, perhaps there was nothing underhanded
> going on at all.
Maybe not consciously. However, the end result of this is annoying. You
have to look it from my POV a bit, and that of the FM camp. We are
"competing" with Velocity, which is *extremely* inferior technology at
this point. OTOH, I have little doubt that Velocity still has more users
than FM. Why?
Placement.
Fine. Why do all the Turbine users use Velocity and not FM? Did they
really choose Velocity?
No, of course not. It was placement. We all know this. There are no
recriminations really. However, to start claiming that everyone is using
Velocity because they chose that... that's a bit much. But I have now
heard several times, things like:
"Everybody chose Velocity and is happy with it, so there is no point in
offering our users a choice." (*)
Now, I specifically asked Henning Schmiedehausen how he, in my position,
would react to people laying this bullshit on him? (Because it *is*
bullshit, and not only is it bullshit, but it's pretty obvious.)
Rather than answer the question, he then engaged in a lot of what can
only be characterized as phony posturing about what a terrible guy I am
-- basically to avoid answering the question. Some other poster then
claimed (quite falsely) that I had questioned Henning's technical skill
level (????!!!!) and thus, Henning's diatribe was justified. Supposedly,
I was guilty of all kinds of ad-hominem attacks.
<shrug>
I don't really want to rehash all that, but you can understand that I am
getting _tired_. People may perceive that I'm on edge here, but it may
well boil down to this feeling of mine that I'm dealing with people who
don't play fair -- people who like to play a rigged game, stack the deck
-- and generally, do not have the high respect for the truth that
engineering/technical sorts of people ought to have.
Actually, I would like you to answer the question, Quinton. If you were
in my shoes, how would you feel in that situation when somebody comes
out with the above? (*) above.
I would also appreciate if Henning answered the question. It was a
good-faithed question and I think it deserves a response.
>
>>2. The implicit idea that I am the one in a supplicant
>>position asking
>>*you* for something. "If you want the FM support in there, submit a
>>patch".
>
>
> Come on now. This is a common first reaction from many OSS
> developers.... Granted, it is usually the wrong response.
In this case, I think it really was. Given the history of this whole
situation, it is quite something for someone in my position to swallow.
>
>
>>Quite literally, there seems to be this idea that, by
>>leveraging
>>*our* community's hard work, you are doing *us* a favor. You can deny
>>that this was ever insinuated, but I have inferred this subtext.
>
>
> Maybe that is what he meant. Maybe it was not. Perhaps he simply
> thought that you were asking for support to be added and so he offered
> to let you implement it. There could have been a misunderstanding on
> both sides.
Well, I never asked for support to be added. Henning broached the
possibility in a dialogue on another list.
Now, I think that, in this culture, there is some tendency just to
automatically assume that I must be the one asking you guys for
something. It's a cultural assumption of some sort.
There are a lot of things that you guys probably are not even doing
consciously, but are extremely obnoxious and provocative. However, you
don't perceive how obnoxious and provocative you are, you think you're
really nice mild-mannered guys, so I must be the aggressor. Something
like that.... there is an incredible perception gap here, stepping back
from this a sec, it's actually quite an interesting sociological
phenomenon....
>
>
>>To be brutally honest, Turbine gains a lot more from FM
>>integration than
>>we do. You say you've looked through the FM docs, so I think you know
>>that what I'm saying is true. And the truth should be
>>something that is
>>respected.
>
>
> The real truth is that we both have something to gain. You get a little
> more wider acceptance. We get to offer our users more freedom in
> implementing the view layer. Perhaps even a more powerful and robust
> option.
We both gain, and, yes, I do prefer for Turbine to support FM than for
it not to support FM.
But anyway, Quinton, I commend you. On this: You are the first guy here
who seems to have recognized that I (the FM community really) have a lot
to offer you. And thus, I guess you realize that it makes sense to
behave in a somewhat humble, respectful way.
Other people just don't realize that...
Rudeness: "Hey, submit a patch and stop spamming us."
Silliness: "You're a bad guy and, you know what, we might not use your
work, because you're such a bad guy..."
There are people in your community who have to open their eyes and
realize that there is a world out there, there is a logic and structure
to things, and... you know... behave more in accordance with that...
Regards,
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: Freemarker support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Rodrigo Reyes" <ro...@instaservi.com> writes:
[...]
> Is this the current state of Turbine? I don't think so. We still have
>strong dependencies to specific tools (being Torque and Velocity the most
>obvious ones). It is like Microsoft telling me that it is impossible to
>create a good Operating System without having Internet Explorer embeded.
Well, fact is, in these days you "can't create a good Operating System
without having a Browser embedded". :-)
First and most important move for Turbine would be towards a component
based architecture where we interact between the parts by well known
and defined interfaces. So we won't have any dependencies to a
particular project or tool.
The actual tool access would then happen by (tool-specific) adapters
and/or interface classes.
Basically, this is what we called "avalonization" for post-2.3.
The fact that our "Internet Explorer" ATM is called Velocity (actually
it is more called Torque, because the Scheduler and Security Service
heavily depend on Torque up to the point that Criteria is part of the
method signatures of the Security Service), doesn't mean that it is
impossible to decouple. It just needs work. And unless anyone is
willing to do the work, you will find out that most of the current
developers mainly work to "scratch their itch".
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 Rodrigo Reyes <ro...@instaservi.com>.
Hi all
I've been reading the current posts about Freemaker and I think it is
time to share my point of view.
I believe Turbine should be "tool-agnostic". What do I mean? Turbine
should (and I think, it does most of the time) provide a framework which
should be able to work with whichever tool I decide to use. An example for
this: OR mapping tools. I know most people around Turbine like Torque.
Still, I don't. I may change my opinion later, but so far, I prefer other
tools like Hibernator. So I think Turbine should provide a trully
"tool-agnostic" framework where I could use Hibernator without any strings
attached to Torque.
Is this the current state of Turbine? I don't think so. We still have
strong dependencies to specific tools (being Torque and Velocity the most
obvious ones). It is like Microsoft telling me that it is impossible to
create a good Operating System without having Internet Explorer embeded.
What about Velocity? I like Velocity. We have a commercial project here
written with extensive use of Velocity. Could Velocity be better? Sure it
could. Is it getting better? Not even people in Velocity dev team agree on
that. So should Turbine decide to drop other Templating Engine support? I
really don't think so.
What could be done to become a trully "tool-agnostic" Framework? I like
the way Eclipse project has managed to stay completely agnostic. They focus
on having a great IDE platform and publish lots of documentation on how to
extend it. The community does the rest. And so far, there are hundreds of
pluggins for Eclipse.
So, I know FM people may haven't tell things the right way, but I think
they deserve a place (like anyone else) around Turbine. Let's make sure they
have it... Let's make sure we all have it...
Rodrigo
---------------------------------------------------------------------
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
Re: Freemarker support
Posted by Daniel Rall <dl...@finemaltcoding.com>.
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: Freemarker support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> "Quinton McCombs" <qm...@nequalsone.com> writes:
>
>
>>Hmmm... Interesting history. I can see how that might have happened.
>>Just like you like to actively promote your project, it would make
>>perfect sense that Jon, perhaps, saw no reason to provide robust support
>>for anything besides Velocity. In his eyes, and probabley many other at
>>the time, Velocity was _the_ answer.
>
>
>>You are correct about the WebMacro stuff. There is still comments in
>>the code used for Velocity support indicating the the code was
>>originally copied from a WebMacro version and adpated for Velocity. It
>>is rather clear which came first.
>
>
> http://jakarta.apache.org/velocity/differences.html
Henning, I hope I won't offend you (you do seem to be a rather sensitive
guy) by saying that the above is not exactly an unbiased, objective
source of information.
Frankly, I still tend to believe that the primary reasons for the WM/Vel
thing were the ones I stated -- ego and personality conflict. Obviously,
those reasons would not appear on the document you point to.
>
> --- 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. 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. I also
somehow doubt that the WM people were ever that totally inflexible on
the license. 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.
Meanwhile, the "clean-room" rewrite thing seems like a pretty extreme
step -- the duplication of effort involved. It seems that pragmatic
people would have tried very very hard to avoid that.
Come to think of it, what other cases are there of a "clean-room
rewrite" of an OSS project? I mean, to do a clean-room implementation of
a closed, proprietary system is more the norm, isn't it? There are forks
of OSS projects, like Emacs/XEmacs and so on, but that's another matter...
One striking thing about Velocity IMO is how technically unambitious it
was. I mean, they basically just uncritically copied WebMacro, it seems,
copying all its worst design flaws. The two libraries share most of the
same warts. Rather strange. If I were going to write a template engine
from scratch (a Template engine is, at the root of it, based on a rather
trivial idea, you know) I would try to further the state of the art, or
at least not copy design mistakes in the existing ones.
I took over FreeMarker and there are things in there that I wouldn't
have copied if I were to do something from scratch. Meanwhile, we have
been gradually remedying a lot of legacy warts. Some probably can't
really be fixed though.
>
> If you're not afraid to dig in the past, you might as well start here:
Thanks for the links. Speaking for myself, I can't say that I'm so very
interested.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> http://share.whichever.com/viewcvs.cgi/dash/
>
> Dash got renamed to be Turbine. If you google around and use the
> Internet Wayback-Machine, then the oldest Turbine code base where it
> is called "Turbine" is
>
> http://web.archive.org/web/20000815211455/http://java.apache.org/turbine/
>
> There seem to have been snapshots available but they got lost in time
> and space on the internet. Ah, well.
>
> 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 (was: RE: Decimal Number support)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Daniel Rall <dl...@finemaltcoding.com> writes:
>"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
>...
>> http://web.archive.org/web/20000815211455/http://java.apache.org/turbine/
>>
>> There seem to have been snapshots available but they got lost in time
>> and space on the internet. Ah, well.
>If there was need, I could probably dig those up from the
>java.apache.org archives.
That would be great for historical reasons. You can send them to me
offline or put them on a web site somewhere. It's a shame that much of
the Turbine history got lost in the various reshuffles.
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 (was: RE: Decimal Number support)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
...
> http://web.archive.org/web/20000815211455/http://java.apache.org/turbine/
>
> There seem to have been snapshots available but they got lost in time
> and space on the internet. Ah, well.
If there was need, I could probably dig those up from the
java.apache.org archives.
--
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 (was: RE: Decimal Number support)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>Hmmm... Interesting history. I can see how that might have happened.
>Just like you like to actively promote your project, it would make
>perfect sense that Jon, perhaps, saw no reason to provide robust support
>for anything besides Velocity. In his eyes, and probabley many other at
>the time, Velocity was _the_ answer.
>You are correct about the WebMacro stuff. There is still comments in
>the code used for Velocity support indicating the the code was
>originally copied from a WebMacro version and adpated for Velocity. It
>is rather clear which came first.
http://jakarta.apache.org/velocity/differences.html
--- 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 ---
If you're not afraid to dig in the past, you might as well start here:
http://share.whichever.com/viewcvs.cgi/dash/
Dash got renamed to be Turbine. If you google around and use the
Internet Wayback-Machine, then the oldest Turbine code base where it
is called "Turbine" is
http://web.archive.org/web/20000815211455/http://java.apache.org/turbine/
There seem to have been snapshots available but they got lost in time
and space on the internet. Ah, well.
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: "Never argue with an idiot. They drag you down
to their level, then beat you with experience." ---
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org