> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Revusky
> Sent: Friday, June 20, 2003 12:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Decimal Number support
>
>
> Quinton McCombs wrote:
> >>-----Original Message-----
> >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of
> Jonathan Revusky
> >>Sent: Friday, June 20, 2003 9:55 AM
> >>To: [EMAIL PROTECTED]
> >>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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
