You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/06/17 17:29:38 UTC
FreeMarker Support
Hi,
is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Jeffrey D. Brekke" <jb...@brekke.org>.
>>>>> On Wed, 18 Jun 2003 10:41:50 +0000 (UTC), "Henning P. Schmiedehausen" <hp...@intermeta.de> said:
> The reason for this (and Jonathans' response): On the Velocity
> lists, there has been some rumbling about the current development
> state of Velocity and talking about alternatives to it. As we
> (Turbine) did remove the (quite aged and not actively maintained)
> FreeMarker support post Turbine-2.2, there have been some
> accusations of doing this because of "political reasons". As I was
> not really involved in the FM stuff or its removal, I'm trying to
> collect opinions from the Turbine users about getting FM support
> back into Turbine. However, if noone wants to use it, it wouldn't
> make much sense and the change itself is (IMHO) quite a major one to
> support FM really good.
Hardly political as I was the one who ultimately removed it. It was
around the time we were working on cleaning up the old ant build,
which ultimately lead to Maven. The code was old and no one was
supporting it or using it, so we removed Freemarker, Webmacro, and
Jython support from the build, leaving Velocity and JSP I
believe. Nothing political at all, just no one actively supporting it
or using it at the time.
I agree with you Henning, if no one wants to use Freemarker, no reason
to add it. Same for WebMacro, Tea, etc. If there are developers
willing to contribute and support it, +1 to support for other
templating solutions.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Tyler Burd wrote:
> I don't think Velocity has reached EOL just yet - there has recently
> been quite a bit of discussion on the Velocity dev list regarding
> recommencing active development and integrating several user patches.
Well, I am not the most objective source of information on this topic,
as anybody can see from my sig. But the extremely neglected state of the
Velocity project is really an objective fact. To all intents and
purposes, nobody has committed any code for a year. You can see that
from examining the archives of the velocity-dev list. Their last
release, 1.3.1 final was in March, but that is deceptive, since 1.3.1
final was identical to 1.3.1rc2, and was AFAICS put out for marketing
reasons, to give the impression that something was happening.
Believe me, Velocity, as a project, is in a very neglected state. For
example, the user patches that they are discussing in the "recommencing"
thread, the map support and decimal number support, were submitted last
autumn. Like 8 months ago! That's really not very confidence-inspiring
for anybody who will be in a position of relying on Velocity.
As for whether they are going to get moving again, for the moment that
is all talk. I think that once development has stalled for that long,
it's easier said than done. You know, if I don't work on code for a
year, I forget my way around. It becomes very difficult to get back in.
Right now, I know the FM codebase like the back of my hand, but if I
didn't do anything there for a year or more...
>
> BUT, I know that if Turbine DID support other template dialects, I would
> probably at least give FreeMarker a try, since it has some nice features
> that Velocity doesn't, like the including of templates in a location
> other than the template base directory, the compress directive, etc
> (from a quick look at the manual). If I discovered I liked Velocity
> better after spending some time with fm, I would switch back. It's the
> fact that Turbine doesn't support fm and other template dialects that
> prohibits me from trying alternative solutions.
It seems to me that offering a choice is just clearly better. And there
are certain fallacies in the air in this regard. Even if party X has won
the elections by a landslide for the last 20 years and seem to be
governing fairly well, is that an argument for introducing a one-party
state?
The fact that they can be voted out of power is what keeps the ruling
party honest. (Okay, I mean less crooked, they are politicians, of
course...) Similarly, at least having the option of switching to another
template engine could be quite important for people.
>
> If it's not a huge headache, I vote for the proxied Context as well. If
> the api was similar enough to the VelocityContext currently used,
> converting screens and actions could just be a matter of changing the
> import statements, and that could be done with a quick search & replace
> on the source files and a recompile.
As I pointed out in a separate note, FreeMarker (via a custom
ObjectWrapper instance) could even be configured to work transparently
with VelocityContext objects. It's quite easy.
I'm hesitant to make this following point, since this whole thing about
whether removal of FM support was political or not is not something I
want to keep debating with anybody. It's all water under the bridge.
But, once you know how relatively easy it is to keep the FM support
working, and given the fact that offering choice is clearly better, it
is hard to make sense of what happened.
Also, the fact that people would create this coupling between Turbine
and core Velocity classes makes one wonder how interested these people
were in really giving people a choice between multiple template engines.
But it's a sterile debate. If what happened before was a mistake, then
the obvious thing to do is to correct that mistake.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
Velocity-FreeMarker template conversion utility,
http://freemarker.org/usCavalry.html
>
> -Tyler Burd
>
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Wednesday, June 18, 2003 9:24 PM
> To: Turbine Users List
> Subject: Re: Decimal Number support
>
>
> At the end of the day, if Velocity has reached EOL then we will at some
> stage have to consider a new way forward. If FM is being actively
> developed and provides a good migration path then it is a likely
> candidate for consideration.
>
> Nobody seemed to express any concerns when WM, FM and Jython support was
> removed, but at that point in time Velocity was still being actively
> developed (and as Jeffrey points out Turbines support for all of the
> others was not). If I was new to Turbine today I think I would be
> questioning the logic of using Velocity for my templates, but then again
> if there was no support for anything else then I wouldn't really have a
> choice would I :-) If FM was supported and there was at least a sample
> of app that used it then I would probably consider it. The biggest push
> to use something other than Velocity would be if the Turbine site said
> something like "Velocity is really great, but no longer being
> maintained, we recommend you use ??? instead".
>
> As a general direction I think it would be great if we at
> least look at relaxing the coupling between turbine and velocity such
> that it would be easier to hook some other template service in should
> someone have the desire and cycles to put it together.
>
> Cheers,
>
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
jbrekke@wi.rr.com (Jeffrey D. Brekke) writes:
>Another item that contributed to the removal or rotting of the FM, WM,
>and Jython support was the conditional build that existed. The code
>for supporting those template frameworks wasn't compiled unless the
>jars were present on the classpath. I now consider this a build
>'anti-pattern' and would not like to see somthing like this back into
>the mainline build for Turbine.
As we have maven and a central repository, getting this back is pretty
much out of the question. We put these jars on ibiblio and always
build the whole code. So that's no longer a problem.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Scott Eade <se...@backstagetech.com.au> writes:
> As a general direction I think it would be great if we at
> least look at relaxing the coupling between turbine and
> velocity such that it would be easier to hook some other
> template service in should someone have the desire and cycles
> to put it together.
Another item that contributed to the removal or rotting of the FM, WM,
and Jython support was the conditional build that existed. The code
for supporting those template frameworks wasn't compiled unless the
jars were present on the classpath. I now consider this a build
'anti-pattern' and would not like to see somthing like this back into
the mainline build for Turbine.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Scott Eade <se...@backstagetech.com.au> writes:
> As a general direction I think it would be great if we at
> least look at relaxing the coupling between turbine and
> velocity such that it would be easier to hook some other
> template service in should someone have the desire and cycles
> to put it together.
+0
Sounds very reasonable, but I may like it better in the context of
actually adding support for another templating solution instead of
just speculating how the decoupling should work. But then again, I've
been swamped and haven't had much time to contribute either...
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Decimal Number support
Posted by Tyler Burd <ty...@fenetics.com>.
I don't think Velocity has reached EOL just yet - there has recently
been quite a bit of discussion on the Velocity dev list regarding
recommencing active development and integrating several user patches.
BUT, I know that if Turbine DID support other template dialects, I would
probably at least give FreeMarker a try, since it has some nice features
that Velocity doesn't, like the including of templates in a location
other than the template base directory, the compress directive, etc
(from a quick look at the manual). If I discovered I liked Velocity
better after spending some time with fm, I would switch back. It's the
fact that Turbine doesn't support fm and other template dialects that
prohibits me from trying alternative solutions.
If it's not a huge headache, I vote for the proxied Context as well. If
the api was similar enough to the VelocityContext currently used,
converting screens and actions could just be a matter of changing the
import statements, and that could be done with a quick search & replace
on the source files and a recompile.
-Tyler Burd
-----Original Message-----
From: Scott Eade [mailto:seade@backstagetech.com.au]
Sent: Wednesday, June 18, 2003 9:24 PM
To: Turbine Users List
Subject: Re: Decimal Number support
At the end of the day, if Velocity has reached EOL then we will at some
stage have to consider a new way forward. If FM is being actively
developed and provides a good migration path then it is a likely
candidate for consideration.
Nobody seemed to express any concerns when WM, FM and Jython support was
removed, but at that point in time Velocity was still being actively
developed (and as Jeffrey points out Turbines support for all of the
others was not). If I was new to Turbine today I think I would be
questioning the logic of using Velocity for my templates, but then again
if there was no support for anything else then I wouldn't really have a
choice would I :-) If FM was supported and there was at least a sample
of app that used it then I would probably consider it. The biggest push
to use something other than Velocity would be if the Turbine site said
something like "Velocity is really great, but no longer being
maintained, we recommend you use ??? instead".
As a general direction I think it would be great if we at
least look at relaxing the coupling between turbine and velocity such
that it would be easier to hook some other template service in should
someone have the desire and cycles to put it together.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au
---------------------------------------------------------------------
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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Scott Eade <se...@backstagetech.com.au>.
At the end of the day, if Velocity has reached EOL then we will
at some stage have to consider a new way forward. If FM is
being actively developed and provides a good migration path
then it is a likely candidate for consideration.
Nobody seemed to express any concerns when WM, FM and Jython
support was removed, but at that point in time Velocity was
still being actively developed (and as Jeffrey points out
Turbines support for all of the others was not). If I was
new to Turbine today I think I would be questioning the logic
of using Velocity for my templates, but then again if there
was no support for anything else then I wouldn't really have
a choice would I :-) If FM was supported and there was at
least a sample of app that used it then I would probably
consider it. The biggest push to use something other than
Velocity would be if the Turbine site said something like
"Velocity is really great, but no longer being maintained,
we recommend you use ??? instead".
As a general direction I think it would be great if we at
least look at relaxing the coupling between turbine and
velocity such that it would be easier to hook some other
template service in should someone have the desire and cycles
to put it together.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Quinton McCombs wrote:
>>-----Original Message-----
>>From: Bill [mailto:bhalpin@collaborativefusion.com]
>>Sent: Wednesday, June 18, 2003 8:15 AM
>>To: Henning P. Schmiedehausen
>>Cc: turbine-user
>>Subject: Re: Decimal Number support
>>
>>
>>Henning
>>
>>I think working on Freemarker support would be a waste of the
>>developers valuable time.
>
>
> It would not be a waste of time is people are interested in using it.
>
>
>>However, divorcing Turbine from
>>Velocity to allow more flexibility not only seems like a good
>>idea, it seems absolutely necessary if the I understand the
>>path to Avalonization.
>
>
> I agree with you that the flexibility would be a very good thing.
>
> Our view architecture is really not very plugable. The problem is that
> once you start writing your actions and screen classes which accept
> RunData and Context as parameters, you are become tied to the view
> implementation. This was very much a shortcoming of the core design of
> Turbine.
What you say is interesting, Quinton. In terms of the discussion at
hand, I think a clear distinction really ought to be made. I mean,
there's the question of whether it is *inherently* desirable to support
other view technologies (such as FM) as well as Velocity.
Then there is the question of whether it is pragmatic given the current
architecture. Now, one trap I think you guys should avoid is arguing
that it is *inherently* undesirable to support FM simply because, given
the current architecture, it is messy or a lot of work to do so. Because
that's really a separate issue that should not be confused.
But anyway, I have a technical point to make about this. I suspect that,
at least in terms of FM integration, even the inflexible architecture
you describe does not pose much of a problem. FM is currently
architected flexibly enough that there are fairly straightforward solutions.
>
> Hennings idea to create a proxy class to represent the context type
> object of the underlying view is indeed a good way to solve this
> problem. It would require deprecating the methods that everyone
> normally overrides in the screen and action classes. The replacement
> would be virtually the same interface replacing Context with the new
> class.
>
> Even if we do not decide to support FreeMarker, I think that it would be
> in our best interests to implement the proxy class for the context.
> Right now, if your view is JSP and you want to switch to Velocity or
> visa-versa, you must modify all of your action and screen classes. Not
> fun.
Yeah, I guess I should throw you guys a bone on this.
Turbine may be poorly architectured in this regard, but FreeMarker is
not. Consider the following FreeMarker API:
http://freemarker.org/docs/api/freemarker/template/ObjectWrapper.html
What an ObjectWrapper instance does is that it "wraps" (converts,
really) an arbitrary object to a FreeMarker TemplateModel. In fact, the
ObjectWrapper API was specifically designed with MVC framework writers
in mind. Basically, it provides an extra level of indirection, where you
can transparently convert application-level business objects to
presentation-level objects. The setting of an ObjectWrapper instance
basically is a point at which you can define a policy on that.
There are several default implementations of the ObjectWrapper API that
you could use as extension points. Probably you'd use
freemarker.template.DefaultObjectWrapper. Like this:
public class CustomWrapper extends DefaultObjectWrapper {
public TemplateModel wrap(Object obj) throws TemplateModelException
{
if (obj instanceof VelocityContext) {
VelocityContext vc = (VelocityContext) obj;
SimpleHash result = new SimpleHash(this);
Object[] keys = vc.getKeys();
for (int i=0; i<keys.length; i++) {
result.put(keys[i], vc.get((String) keys[i]);
}
return result;
}
return super.wrap(obj);
}
}
The above is a trivial subclass of the default ObjectWrapper
implementation that will check whether something is a VelocityContext,
convert it to the appropriate FM API, and if it's not that, then it just
falls back on the default behavior. You get it, right?
Now, elsewhere, to set the above custom ObjectWrapper implementation as
the default used, you would need to do something like:
freemarker.template.Configuration.getDefaultConfiguration().setObjectWrapper(new
CustomWrapper());
What this means is that when you expose an object to the template, it
will, by default, now use the CustomWrapper. As you can see by
eyeballing the source code, the CustomWrapper "knows" how to convert a
VelocityContext object to an object that FM can deal with.
In particular, what it also means is that in the process() calls here:
http://freemarker.org/docs/api/freemarker/template/Template.html#process(java.lang.Object,%20java.io.Writer)
you could pass in a VelocityContext as the rootMap object and all the
right things would simply happen transparently!
So, you see, FreeMarker has a very flexible architecture that allows you
to deal with even this kind of silly rigidity described fairly easily
and elegantly.
IOW, if you implement the appropriate ObjectWrapper instance, FreeMarker
will deal transparently with whatever data-side objects you throw at it!
The little bit of magic above requires about a dozen lines of code.
I hope that's illuminating.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison, http://freemarker.org/fmVsVel.html
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Jeffery Painter wrote:
> Jonathan and other FM evanglizers, I don't recall ever seeing you post to
> this list before, although I've only been a user for a little less than
> a year, and I believe you even stated that you do not use
> turbine. This is the turbine-users group and not the turbine-dev.
>
> While I find it interesting to hear all the things freemarker supports, I
> do not really find this pertinent exactly to turbine-users support group,
> which is largely what this list is used for.
>
> This seems more like a turbine-dev discussion to me.
Jeff,
I infer from your message that you think that I initiated this thread.
That is not the case.
Henning P. Schmiedehausen commenced this thread on FM support in Turbine.
Please pay more attention in the future.
Thanks,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
FreeMarker 2.3pre4 is out.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: CLOSED: RE: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Scott Eade wrote:
> Jonathan Revusky wrote:
>
>> All fun and games. I don't have much time for it.
>
>
> ROTFL. You clearly have more time on your hands than most.
Point taken. My telling you guys off was clearly self-indulgent and I
was conscious that I was wasting my time. It is pointless to tell people
anything when you know that they won't process the message.
>
> I think we are by now all pretty clear as to your opinions
Thank you. I think I have expressed myself quite clearly and if anybody
doesn't understand what I'm saying at this point, it's willful.
> and are ready to move on.
Well, I'm not optimistic on that. I sense that a lot of people here are
in a state of arrested development.
When I saw that founding members of the project, in particular Jon
Stevens, were not involved any more, I had a flash of optimism about
this. Also, there did seem to be some somewhat reasonable people.
However, now I think the basic "culture" established by the original
developers persists.
Also, I broke down and eyeballed the code yesterday, did a checkout. I
grepped over the sources and saw that 21 (!) different source files
reference classes in the org.apache.velocity.* hierarchy.
Given that all you need to do basically, (in pseudocode) is:
Get Template
Stick your variables in a context (which is just a hash)
merge the template and data
How there are 21 different coupling points with the rest of the
framework is beyond me. The Niggle framework (which I am the author of)
supports FM, Vel, and WM. I did a similar grep and there are 3 files
which reference Velocity classes. I did a similar grep over JPublish
sources, which support the same 3 template engines. There are 4 source
files that reference org.apache.velocity classes. In both cases, one can
look at those 3 or 4 files, and it is quite easy to get a feeling of
what would be necessary to support another template engine, what hooks
you would need to replace.
From this examination of the Turbine code, I came to the unappealing
conclusion that, when Henning and a couple of other people who know the
code proposed that I submit a patch against the CVS HEAD, the suggestion
was not made in completely good faith. They would have to do a cleanup
to get the coupling down before it is feasible for me to come in and do
that.
But anyway, at the end of the day, what is the point of having such a
highly abstracted framework if you can't replace a given component of it
without a major re-architecture?
The whole thing does not inspire much confidence.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Regards,
>
> Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: CLOSED: RE: Decimal Number support
Posted by Scott Eade <se...@backstagetech.com.au>.
Jonathan Revusky wrote:
> All fun and games. I don't have much time for it.
ROTFL. You clearly have more time on your hands than most.
I think we are by now all pretty clear as to your opinions and
are ready to move on.
Regards,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: CLOSED: RE: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Keith Seim wrote:
> Jonathan
>
> It was a <b>joke</b>, not meant to hurt anyone.
Not to worry. It wasn't really offensive.
OTOH, it was notably not funny also. It was just sort of annoying really.
> I'm sorry you didn't
> like it, I can't help that. I apologize, ask your forgiveness,
Oh, never mind. Just, if you don't have anything to say, then maybe you
shouldn't say anything.
> and in
> any case, retreat fully from the conversation between people who
> admittedly dwarf my talent and intellect.
Well, don't assume that all the people around here are of such great
talent and intellect.
I'm not annoyed at you, Keith. I'm annoyed at the guy who engaged in the
phony posturing that I was "bullying" the list because I responded
sharply to your post.
All fun and games. I don't have much time for it.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
> I'm a newbie, and neither
> understand, nor speak for the Turbine community.
> Sincerely, honestly and finally
> Keith
>
> On a side note, I do hope this thread can stop (if not
>
> On Sunday, June 22, 2003, at 08:30 AM, Jonathan Revusky wrote:
>
>> Chris K Chew wrote:
>>
>>> Well, I think we can officially say that this thread should be closed.
>>> Jonathan, I appreciate your work on the FreeMarker project. Bullying
>>> the
>>> turbine-user list certainly won't cause us to support FreeMarker any
>>> sooner.
>>
>>
>> Chris (and all Turbine developers)
>>
>> You guys have to start being more honest. I have participated on this
>> list long enough to have come to the conclusion that there is simply
>> not a culture here that is based on a high respect for the truth.
>>
>> Take this above statement that I'm "bullying the list". I simply
>> responded sharply to a moronic post from Keith -- reread it, why don't
>> you? This utterly moronic crap about FM and Ham radio and so on. It
>> seemed like the start of some kind of obnoxious "Greek chorus" kind of
>> low-level harassment.
>>
>> Whether I should respond to the provocation is one thing. (Probably
>> not, though I thought it made sense just to shut it down immediately.)
>> But to say that I'm "bullying" the list on the basis of my responding
>> to somebody else's provocation!!!???
>>
>> That is highly dishonest on your part, Chris. Shame on you! Did your
>> parents bring you up to tell such falsehoods?
>>
>> However, it's not just you. There has been a clear lack of honesty in
>> my interchanges with Turbine people. It started when Henning P.
>> Schmiedehausen claimed (this occurred in dialogue on the Velocity-dev
>> list) that FM support was removed because nobody was using it. In a
>> later post, he noted that, though it "taken him ages to realize it"
>> (:-)) he was aware that FM and WM were *never* supported on an equal
>> footing to Velocity.
>>
>> IOW, the whole situation was rigged from the get-go. This also means
>> that Henning's earlier claim that nobody was using, and thus, there
>> was no interest on the part of users was, at best, a very contrived
>> half-truth.
>>
>> I pointed out that this was equivalent to a situation in which
>> 3-day-old fish was offered on the menu, nobody ordered it, and this
>> was taken as proof that there was no interest on anybody's part in
>> eating fish. It is highly provocative when people start with these
>> ridiculously contrived arguments. I asked Henning how he would react
>> if in my shoes if somebody "laid this line of bullshit on him".
>>
>> He then postured that he was extremely offended by me and so on and so
>> forth. In fact, he engaged in ad-hominem to avoid the point, which was
>> how he would react to somebody else's dishonesty in this spot.
>>
>> One Peter Riegsberger then claimed that I was the one engaging in
>> ad-hominem and that I had questioned Henning's technical competence.
>>
>> That was a falsehood. I had never questioned Henning's technical
>> competence.
>>
>> Peter then claimed that he understood valid argumentation. Well, he
>> didn't seem to understand that untruthful statements are not a valid
>> form of argumentation. And I think that is a very basic point.
>>
>> I am also dealing with incredible amounts of rudeness. That people to
>> whom I have taken such a deep personal dislike can make use of my work
>> free of charge is one thing. But that people then engage in this
>> posturing where the implicit idea is that, by leveraging my hard work,
>> they are doing *me* a favor!!!???
>>
>> I am convinced that there is just no consciousness here of how
>> arrogant, obnoxious, and also STUPID you guys come across as.
>>
>> That a project is dominated by rude, arrogant, self-righteous people,
>> who are disrespectful of others, that is one thing. However, when the
>> members are also disrespectful of the truth, I think that's the kiss
>> of death. I do not believe that much can be achieved in technical
>> fields without a respect for the truth.
>>
>> Thus, I am not optimistic about the future of Turbine, and thus, my
>> already minimal interest in the FM-Turbine integration is diminished
>> even further.
>>
>> I hope you can understand my position here. I anticipate that you are
>> likely to engage in more posturing in which you say I'm such a
>> terrible guy and so on and in which you indulge in more falsehoods. I
>> don't care.
>>
>> I just say that you guys should start being more honest. There is also
>> a notable lack of certain other human qualities here: humility,
>> respect for others, and so on. You could work on that as well.
>> However, the lack of honesty is really what is going to do you in.
>> Honesty is absolutely necessary in a technical endeavor.
>>
>> Regards,
>>
>> Jonathan Revusky
>> --
>> lead developer, FreeMarker project, http://freemarker.org/
>>
>>> Turbine Developers, Perhaps it is time that we move the details of any
>>> development repercussions this discussion has created over to the
>>> turbine-dev list?
>>
>>
>>
>>
>>
>>> Chris
>>>
>>>> -----Original Message-----
>>>> From: news [mailto:news@main.gmane.org]On Behalf Of Jonathan Revusky
>>>> Sent: Friday, June 20, 2003 5:52 PM
>>>> To: turbine-user@jakarta.apache.org
>>>> Subject: Re: Decimal Number support
>>>>
>>>>
>>>> Unknown (Keith Seim) wrote:
>>>>
>>>>> I think FM is great - you get good sound, it's free, and the
>>>>> technology
>>>>> costs close to nothing. I don't know about these other
>>>>
>>>>
>>>> frequencies, but
>>>>
>>>>> I doubt they're stereo (maybe they're like ham radio... you have to
>>>>> pay
>>>>> for a licence... 'course, that sound more like proprietary
>>>>
>>>>
>>>> software to me).
>>>>
>>>>> alright, shutting up now
>>>>
>>>>
>>>> Keith,
>>>>
>>>> Do you have an excuse for this? Some mitigating circumstances? Like, do
>>>> you know if your momma did a lot drinking while she was pregnant with
>>>> you? Or was she doing drugs? Or maybe there's a limited gene pool in
>>>> your case, like you're maybe the product of an incestuous relationship?
>>>>
>>>> Or it could be all of the above...
>>>>
>>>> Whatever, but if you are a congenital idiot, I think you should
>>>> dissimulate it better. Everybody has their cross to bear, after all.
>>>>
>>>> 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-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>>
>>
> ___________________________________
> Keith Seim • http://kjsdesigns.co
> m
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: CLOSED: RE: Decimal Number support
Posted by Keith Seim <ke...@kjsdesigns.com>.
Jonathan
It was a <b>joke</b>, not meant to hurt anyone. I'm sorry you didn't
like it, I can't help that. I apologize, ask your forgiveness, and in
any case, retreat fully from the conversation between people who
admittedly dwarf my talent and intellect. I'm a newbie, and neither
understand, nor speak for the Turbine community.
Sincerely, honestly and finally
Keith
On a side note, I do hope this thread can stop (if not
On Sunday, June 22, 2003, at 08:30 AM, Jonathan Revusky wrote:
> Chris K Chew wrote:
>> Well, I think we can officially say that this thread should be closed.
>> Jonathan, I appreciate your work on the FreeMarker project. Bullying
>> the
>> turbine-user list certainly won't cause us to support FreeMarker any
>> sooner.
>
> Chris (and all Turbine developers)
>
> You guys have to start being more honest. I have participated on this
> list long enough to have come to the conclusion that there is simply
> not a culture here that is based on a high respect for the truth.
>
> Take this above statement that I'm "bullying the list". I simply
> responded sharply to a moronic post from Keith -- reread it, why don't
> you? This utterly moronic crap about FM and Ham radio and so on. It
> seemed like the start of some kind of obnoxious "Greek chorus" kind of
> low-level harassment.
>
> Whether I should respond to the provocation is one thing. (Probably
> not, though I thought it made sense just to shut it down immediately.)
> But to say that I'm "bullying" the list on the basis of my responding
> to somebody else's provocation!!!???
>
> That is highly dishonest on your part, Chris. Shame on you! Did your
> parents bring you up to tell such falsehoods?
>
> However, it's not just you. There has been a clear lack of honesty in
> my interchanges with Turbine people. It started when Henning P.
> Schmiedehausen claimed (this occurred in dialogue on the Velocity-dev
> list) that FM support was removed because nobody was using it. In a
> later post, he noted that, though it "taken him ages to realize
> it" (:-)) he was aware that FM and WM were *never* supported on an
> equal footing to Velocity.
>
> IOW, the whole situation was rigged from the get-go. This also means
> that Henning's earlier claim that nobody was using, and thus, there was
> no interest on the part of users was, at best, a very contrived
> half-truth.
>
> I pointed out that this was equivalent to a situation in which
> 3-day-old fish was offered on the menu, nobody ordered it, and this was
> taken as proof that there was no interest on anybody's part in eating
> fish. It is highly provocative when people start with these
> ridiculously contrived arguments. I asked Henning how he would react if
> in my shoes if somebody "laid this line of bullshit on him".
>
> He then postured that he was extremely offended by me and so on and so
> forth. In fact, he engaged in ad-hominem to avoid the point, which was
> how he would react to somebody else's dishonesty in this spot.
>
> One Peter Riegsberger then claimed that I was the one engaging in
> ad-hominem and that I had questioned Henning's technical competence.
>
> That was a falsehood. I had never questioned Henning's technical
> competence.
>
> Peter then claimed that he understood valid argumentation. Well, he
> didn't seem to understand that untruthful statements are not a valid
> form of argumentation. And I think that is a very basic point.
>
> I am also dealing with incredible amounts of rudeness. That people to
> whom I have taken such a deep personal dislike can make use of my work
> free of charge is one thing. But that people then engage in this
> posturing where the implicit idea is that, by leveraging my hard work,
> they are doing *me* a favor!!!???
>
> I am convinced that there is just no consciousness here of how
> arrogant, obnoxious, and also STUPID you guys come across as.
>
> That a project is dominated by rude, arrogant, self-righteous people,
> who are disrespectful of others, that is one thing. However, when the
> members are also disrespectful of the truth, I think that's the kiss of
> death. I do not believe that much can be achieved in technical fields
> without a respect for the truth.
>
> Thus, I am not optimistic about the future of Turbine, and thus, my
> already minimal interest in the FM-Turbine integration is diminished
> even further.
>
> I hope you can understand my position here. I anticipate that you are
> likely to engage in more posturing in which you say I'm such a terrible
> guy and so on and in which you indulge in more falsehoods. I don't care.
>
> I just say that you guys should start being more honest. There is also
> a notable lack of certain other human qualities here: humility, respect
> for others, and so on. You could work on that as well. However, the
> lack of honesty is really what is going to do you in. Honesty is
> absolutely necessary in a technical endeavor.
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
>
>> Turbine Developers, Perhaps it is time that we move the details of any
>> development repercussions this discussion has created over to the
>> turbine-dev list?
>
>
>
>
>> Chris
>>> -----Original Message-----
>>> From: news [mailto:news@main.gmane.org]On Behalf Of Jonathan Revusky
>>> Sent: Friday, June 20, 2003 5:52 PM
>>> To: turbine-user@jakarta.apache.org
>>> Subject: Re: Decimal Number support
>>>
>>>
>>> Unknown (Keith Seim) wrote:
>>>
>>>> I think FM is great - you get good sound, it's free, and the
>>>> technology
>>>> costs close to nothing. I don't know about these other
>>>
>>> frequencies, but
>>>
>>>> I doubt they're stereo (maybe they're like ham radio... you have to
>>>> pay
>>>> for a licence... 'course, that sound more like proprietary
>>>
>>> software to me).
>>>
>>>> alright, shutting up now
>>>
>>> Keith,
>>>
>>> Do you have an excuse for this? Some mitigating circumstances? Like,
>>> do
>>> you know if your momma did a lot drinking while she was pregnant with
>>> you? Or was she doing drugs? Or maybe there's a limited gene pool in
>>> your case, like you're maybe the product of an incestuous
>>> relationship?
>>>
>>> Or it could be all of the above...
>>>
>>> Whatever, but if you are a congenital idiot, I think you should
>>> dissimulate it better. Everybody has their cross to bear, after all.
>>>
>>> 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-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
>
___________________________________
Keith Seim • http://kjsdesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: CLOSED: RE: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Chris K Chew wrote:
> Well, I think we can officially say that this thread should be closed.
>
> Jonathan, I appreciate your work on the FreeMarker project. Bullying the
> turbine-user list certainly won't cause us to support FreeMarker any sooner.
Chris (and all Turbine developers)
You guys have to start being more honest. I have participated on this
list long enough to have come to the conclusion that there is simply not
a culture here that is based on a high respect for the truth.
Take this above statement that I'm "bullying the list". I simply
responded sharply to a moronic post from Keith -- reread it, why don't
you? This utterly moronic crap about FM and Ham radio and so on. It
seemed like the start of some kind of obnoxious "Greek chorus" kind of
low-level harassment.
Whether I should respond to the provocation is one thing. (Probably not,
though I thought it made sense just to shut it down immediately.) But to
say that I'm "bullying" the list on the basis of my responding to
somebody else's provocation!!!???
That is highly dishonest on your part, Chris. Shame on you! Did your
parents bring you up to tell such falsehoods?
However, it's not just you. There has been a clear lack of honesty in my
interchanges with Turbine people. It started when Henning P.
Schmiedehausen claimed (this occurred in dialogue on the Velocity-dev
list) that FM support was removed because nobody was using it. In a
later post, he noted that, though it "taken him ages to realize it"
(:-)) he was aware that FM and WM were *never* supported on an equal
footing to Velocity.
IOW, the whole situation was rigged from the get-go. This also means
that Henning's earlier claim that nobody was using, and thus, there was
no interest on the part of users was, at best, a very contrived half-truth.
I pointed out that this was equivalent to a situation in which 3-day-old
fish was offered on the menu, nobody ordered it, and this was taken as
proof that there was no interest on anybody's part in eating fish. It is
highly provocative when people start with these ridiculously contrived
arguments. I asked Henning how he would react if in my shoes if somebody
"laid this line of bullshit on him".
He then postured that he was extremely offended by me and so on and so
forth. In fact, he engaged in ad-hominem to avoid the point, which was
how he would react to somebody else's dishonesty in this spot.
One Peter Riegsberger then claimed that I was the one engaging in
ad-hominem and that I had questioned Henning's technical competence.
That was a falsehood. I had never questioned Henning's technical competence.
Peter then claimed that he understood valid argumentation. Well, he
didn't seem to understand that untruthful statements are not a valid
form of argumentation. And I think that is a very basic point.
I am also dealing with incredible amounts of rudeness. That people to
whom I have taken such a deep personal dislike can make use of my work
free of charge is one thing. But that people then engage in this
posturing where the implicit idea is that, by leveraging my hard work,
they are doing *me* a favor!!!???
I am convinced that there is just no consciousness here of how arrogant,
obnoxious, and also STUPID you guys come across as.
That a project is dominated by rude, arrogant, self-righteous people,
who are disrespectful of others, that is one thing. However, when the
members are also disrespectful of the truth, I think that's the kiss of
death. I do not believe that much can be achieved in technical fields
without a respect for the truth.
Thus, I am not optimistic about the future of Turbine, and thus, my
already minimal interest in the FM-Turbine integration is diminished
even further.
I hope you can understand my position here. I anticipate that you are
likely to engage in more posturing in which you say I'm such a terrible
guy and so on and in which you indulge in more falsehoods. I don't care.
I just say that you guys should start being more honest. There is also a
notable lack of certain other human qualities here: humility, respect
for others, and so on. You could work on that as well. However, the lack
of honesty is really what is going to do you in. Honesty is absolutely
necessary in a technical endeavor.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Turbine Developers, Perhaps it is time that we move the details of any
> development repercussions this discussion has created over to the
> turbine-dev list?
>
> Chris
>
>
>>-----Original Message-----
>>From: news [mailto:news@main.gmane.org]On Behalf Of Jonathan Revusky
>>Sent: Friday, June 20, 2003 5:52 PM
>>To: turbine-user@jakarta.apache.org
>>Subject: Re: Decimal Number support
>>
>>
>>Unknown (Keith Seim) wrote:
>>
>>>I think FM is great - you get good sound, it's free, and the technology
>>>costs close to nothing. I don't know about these other
>>
>>frequencies, but
>>
>>>I doubt they're stereo (maybe they're like ham radio... you have to pay
>>>for a licence... 'course, that sound more like proprietary
>>
>>software to me).
>>
>>>alright, shutting up now
>>
>>Keith,
>>
>>Do you have an excuse for this? Some mitigating circumstances? Like, do
>>you know if your momma did a lot drinking while she was pregnant with
>>you? Or was she doing drugs? Or maybe there's a limited gene pool in
>>your case, like you're maybe the product of an incestuous relationship?
>>
>>Or it could be all of the above...
>>
>>Whatever, but if you are a congenital idiot, I think you should
>>dissimulate it better. Everybody has their cross to bear, after all.
>>
>>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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
CLOSED: RE: Decimal Number support
Posted by Chris K Chew <ch...@fenetics.com>.
Well, I think we can officially say that this thread should be closed.
Jonathan, I appreciate your work on the FreeMarker project. Bullying the
turbine-user list certainly won't cause us to support FreeMarker any sooner.
Turbine Developers, Perhaps it is time that we move the details of any
development repercussions this discussion has created over to the
turbine-dev list?
Chris
> -----Original Message-----
> From: news [mailto:news@main.gmane.org]On Behalf Of Jonathan Revusky
> Sent: Friday, June 20, 2003 5:52 PM
> To: turbine-user@jakarta.apache.org
> Subject: Re: Decimal Number support
>
>
> Unknown (Keith Seim) wrote:
> > I think FM is great - you get good sound, it's free, and the technology
> > costs close to nothing. I don't know about these other
> frequencies, but
> > I doubt they're stereo (maybe they're like ham radio... you have to pay
> > for a licence... 'course, that sound more like proprietary
> software to me).
> >
> > alright, shutting up now
>
> Keith,
>
> Do you have an excuse for this? Some mitigating circumstances? Like, do
> you know if your momma did a lot drinking while she was pregnant with
> you? Or was she doing drugs? Or maybe there's a limited gene pool in
> your case, like you're maybe the product of an incestuous relationship?
>
> Or it could be all of the above...
>
> Whatever, but if you are a congenital idiot, I think you should
> dissimulate it better. Everybody has their cross to bear, after all.
>
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Unknown (Keith Seim) wrote:
> I think FM is great - you get good sound, it's free, and the technology
> costs close to nothing. I don't know about these other frequencies, but
> I doubt they're stereo (maybe they're like ham radio... you have to pay
> for a licence... 'course, that sound more like proprietary software to me).
>
> alright, shutting up now
Keith,
Do you have an excuse for this? Some mitigating circumstances? Like, do
you know if your momma did a lot drinking while she was pregnant with
you? Or was she doing drugs? Or maybe there's a limited gene pool in
your case, like you're maybe the product of an incestuous relationship?
Or it could be all of the above...
Whatever, but if you are a congenital idiot, I think you should
dissimulate it better. Everybody has their cross to bear, after all.
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
Re: Decimal Number support
Posted by "Keith Seim || kjsdesigns.com" <kjsdesigns.com>.
I think FM is great - you get good sound, it's free, and the technology
costs close to nothing. I don't know about these other frequencies, but
I doubt they're stereo (maybe they're like ham radio... you have to pay
for a licence... 'course, that sound more like proprietary software to
me).
alright, shutting up now
happily (trying) to install turbine
Keith
On Friday, June 20, 2003, at 01:49 PM, Jonathan Revusky wrote:
> peter riegersperger wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On Friday 20 June 2003 16:54, Jonathan Revusky wrote:
>>> I'm not completely sure you understand what "ad hominem" means. The
>>> ad-hominem fallacy is where you attack a person's character because
>>> you
>>> cannot legitimately deal with the argument that person is making.
>>>
>>> That is precisely what Henning was doing in his last respose to me.
>>> The
>>> ad-hominem fallacy was very much inevidence. These "arguments" like
>>> I'm
>>> such a disagreeable person, so nobody will be interested in FM. Of
>>> course, that's an ad-hominem argument. Unashamedly ad-hominem!
>> whatever history henning and you might share, on this list, the message
>> http://www.mail-archive.com/turbine-
>> user@jakarta.apache.org/msg12447.html
>> is the first in the thread that contains dismissive comments about
>> personality and skills of another person. and you are the author of
>> that mail.
>
> I never questioned the technical skills of Henning P. Schmiedehausen. I
> simply responded sarcastically to his statement that it had taken him
> "ages" to realize that FM and WM were not supported on an equal footing
> with Vel.
>
> I still don't know how to process that.
>
>
>> you started it, he shot back.
>> if this is not correct, and the message indicated above was not the
>> first agressive email on this list, i apologize for accusing you of
>> starting this.
>
> My interchange with Henning on this topic began on the velocity-devel
> list.
>
>> and just for the records: i think i have a tiny little bit of
>> understanding of valid and invalid forms of arguments.
>
> <sigh>
>
> Yes, I know that you think you do.
>
> 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
>
>
>
___________________________________
Keith Seim • http://kjsdesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
peter riegersperger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 20 June 2003 16:54, Jonathan Revusky wrote:
>
>>I'm not completely sure you understand what "ad hominem" means. The
>>ad-hominem fallacy is where you attack a person's character because you
>>cannot legitimately deal with the argument that person is making.
>>
>>That is precisely what Henning was doing in his last respose to me. The
>>ad-hominem fallacy was very much inevidence. These "arguments" like I'm
>>such a disagreeable person, so nobody will be interested in FM. Of
>>course, that's an ad-hominem argument. Unashamedly ad-hominem!
>
>
> whatever history henning and you might share, on this list, the message
>
> http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg12447.html
>
> is the first in the thread that contains dismissive comments about personality
> and skills of another person. and you are the author of that mail.
I never questioned the technical skills of Henning P. Schmiedehausen. I
simply responded sarcastically to his statement that it had taken him
"ages" to realize that FM and WM were not supported on an equal footing
with Vel.
I still don't know how to process that.
>
> you started it, he shot back.
>
> if this is not correct, and the message indicated above was not the first
> agressive email on this list, i apologize for accusing you of starting this.
My interchange with Henning on this topic began on the velocity-devel list.
>
> and just for the records: i think i have a tiny little bit of understanding of
> valid and invalid forms of arguments.
<sigh>
Yes, I know that you think you do.
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
Re: Decimal Number support
Posted by peter riegersperger <ri...@subnet.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 20 June 2003 16:54, Jonathan Revusky wrote:
> I'm not completely sure you understand what "ad hominem" means. The
> ad-hominem fallacy is where you attack a person's character because you
> cannot legitimately deal with the argument that person is making.
>
> That is precisely what Henning was doing in his last respose to me. The
> ad-hominem fallacy was very much inevidence. These "arguments" like I'm
> such a disagreeable person, so nobody will be interested in FM. Of
> course, that's an ad-hominem argument. Unashamedly ad-hominem!
whatever history henning and you might share, on this list, the message
http://www.mail-archive.com/turbine-user@jakarta.apache.org/msg12447.html
is the first in the thread that contains dismissive comments about personality
and skills of another person. and you are the author of that mail.
you started it, he shot back.
if this is not correct, and the message indicated above was not the first
agressive email on this list, i apologize for accusing you of starting this.
and just for the records: i think i have a tiny little bit of understanding of
valid and invalid forms of arguments.
peter
- --
|-
| peter riegersperger <ri...@subnet.at>
|-
| subnet
| platform for media art and experimental technologies
|-
| http://www.subnet.at/
|-
| muehlbacherhofweg 5 // 5020 salzburg // austria
|-
| fon/fax +43/662/842 897
|-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+8zQbIMP39JYOy9IRArwCAJ9aAlLg3N+BE5W7kXk+YTN13eIDewCg1U0G
f6e8IE36qoRU5T2p3PF96ts=
=mwP5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-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: 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
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: [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 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
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
Freemarker support (was: RE: Decimal Number support)
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----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: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
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>
>
>>>they merely discussed if they should
>>>"bolt it on" (making some hacks here or there, if i
>>
>>understood correctly), or
>>
>>>do it right (which would lead to a major redesign of their
>>
>>product).
>>
>>
>>Oh, the technical stuff is all fine.
>>
>>As I explain above, I just get very sensitized to hearing nonsense.
>>That's all.
>>
>
>
> Nonsense? Could you explain how that is nonsense?
I really don't want to rehash all this. But you are asking the question
and I shall respond. The nonsense I was referring to was the business
about the FM support being removed because "nobody was using it". I have
already explained why I consider that to be a very contrived half-truth.
There has been other nonsense that has got my back up too, but I don't
want to rehash it all.
I am getting sensitized to nonsense, and even in the best of
circumstances, I don't suffer it gladly. Maybe it really did take
Henning "ages" to figure out that other template engines were never
supported on an equal footing with Velocity in the Turbine framework. I
couldn't make any sense of that, and it got my back up.
I was already sensitized from previous dialogue to what I perceived as
rather contrived, dishonest arguments and things, and my irritation
definitely showed through.
>
> Turbine is a pretty good product. However, it has a fair amount of
> legacy code in it in which the design is a buit lacking to put it
> nicely. This was what the current developers have inheritied and are
> trying to rectify. These core design issues are what made the support
> for FM, JSP, and WM less than optimal.
That's fine. I processed all that.
>
> 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.
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.
Now, when I state that I am not that favorably disposed towards actively
helping you put the FM support back, there is a history here. If,
instead of simply removing the FM support, you had showed up in our
community and solicited our help in bringing it up-to-date, I think we
would have helped you. At this point, I do sort of feel strongly that
it's up to you guys to put it back in.
> They probabley made improvements to the product in the areas that
> directly affected what _they_ were using Turbine for. Since they used
> Velocity, they developed in those areas. This is all just speculation
> based on what I have see from other projects.
Let's let it rest. I think I know pretty much what happened. Or at
least, I know what happened as well as I care to.
>
> 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.
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.
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 ;-))
>
> 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.
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.
That would just require that people recompile against the newer jarfile,
because the method signatures would change. But that's hardly a big
deal. Where they explicitly passed in a VelocityContext object, they
could just continue doing so.
>
>
>>>from
>>>this point of view, you seemed to have achieved your goal.
>>
>>It was never much of a goal of mine, you know. Henning
>>brought it up on
>>the Velocity list. He suggested that I should provide a patch, and I
>>said quite matter-of-factly that that was not going to happen, since,
>>Turbine removed support for alternatives for rather murky
>>non-technical
>>reasons, AFAICS, and my position really just had to be that,
>>if you guys
>>wanted FM support back, you had to put it back yourselves.
>>
>>Then Henning started all this stuff about how we were nutty
>>conspiracy
>>theorists for believing that the removal of FM or WM support
>>and leaving
>>only Vel support was political in nature.
>
>
> He said, she said, BS. Does this really matter? If the two of you want
> to continue that particular thread of the discussion, please take it off
> the list.
Well, I was just explaining how we got to that point. You're also trying
to explain a bunch of things.
In any case, I think there are a couple of things that really got my
back up. I'll explain them below and be done with it.
>
>
>>I think it appropriate to re-iterate what I said in a
>>previous message.
>>If you want to foment constructive discussion and activity, I
>>think you
>>first need to foment more honesty in the basic culture here.
>>
>>You guys should stop these attempts to spin and distort what's really
>>going on.
>
>
> You are certainly welcome to your opinion but I think that you have
> mis-understood what Henning was saying about why it was removed.
> Henning was not the person that removed it. That decision was made
> before either of us started working on the project. He told you his
> understanding of the reasons behind the removal. If you choose to
> believe that he is not being honest about it, ask someone else. There
> is no need to accuse people of not being honest. He is being honest as
> long as what he tells you is what he believes to be true. It really has
> nothing to do with if it is the _real_ truth or not. But again, does
> any of that matter??
This could just be a misunderstanding. In general, if you're 100%
honest, it's pretty easy to get along with me.
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.
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". 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.
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.
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.
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
RE: Decimal Number support
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----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>
> > they merely discussed if they should
> > "bolt it on" (making some hacks here or there, if i
> understood correctly), or
> > do it right (which would lead to a major redesign of their
> product).
>
>
> Oh, the technical stuff is all fine.
>
> As I explain above, I just get very sensitized to hearing nonsense.
> That's all.
>
Nonsense? Could you explain how that is nonsense?
Turbine is a pretty good product. However, it has a fair amount of
legacy code in it in which the design is a buit lacking to put it
nicely. This was what the current developers have inheritied and are
trying to rectify. These core design issues are what made the support
for FM, JSP, and WM less than optimal.
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.
They probabley made improvements to the product in the areas that
directly affected what _they_ were using Turbine for. Since they used
Velocity, they developed in those areas. This is all just speculation
based on what I have see from other projects.
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 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.
> > from
> > this point of view, you seemed to have achieved your goal.
>
> It was never much of a goal of mine, you know. Henning
> brought it up on
> the Velocity list. He suggested that I should provide a patch, and I
> said quite matter-of-factly that that was not going to happen, since,
> Turbine removed support for alternatives for rather murky
> non-technical
> reasons, AFAICS, and my position really just had to be that,
> if you guys
> wanted FM support back, you had to put it back yourselves.
>
> Then Henning started all this stuff about how we were nutty
> conspiracy
> theorists for believing that the removal of FM or WM support
> and leaving
> only Vel support was political in nature.
He said, she said, BS. Does this really matter? If the two of you want
to continue that particular thread of the discussion, please take it off
the list.
> I think it appropriate to re-iterate what I said in a
> previous message.
> If you want to foment constructive discussion and activity, I
> think you
> first need to foment more honesty in the basic culture here.
>
> You guys should stop these attempts to spin and distort what's really
> going on.
You are certainly welcome to your opinion but I think that you have
mis-understood what Henning was saying about why it was removed.
Henning was not the person that removed it. That decision was made
before either of us started working on the project. He told you his
understanding of the reasons behind the removal. If you choose to
believe that he is not being honest about it, ask someone else. There
is no need to accuse people of not being honest. He is being honest as
long as what he tells you is what he believes to be true. It really has
nothing to do with if it is the _real_ truth or not. But again, does
any of that matter??
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
peter riegersperger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> jonathan, as a turbine-user, i think i've got the point now.
>
> but, please let me add some notes about style:
>
> first of all, ad hominem arguments are unacceptable.
Peter,
I'm not completely sure you understand what "ad hominem" means. The
ad-hominem fallacy is where you attack a person's character because you
cannot legitimately deal with the argument that person is making.
That is precisely what Henning was doing in his last respose to me. The
ad-hominem fallacy was very much inevidence. These "arguments" like I'm
such a disagreeable person, so nobody will be interested in FM. Of
course, that's an ad-hominem argument. Unashamedly ad-hominem!
And meanwhile, it's really the most utter, vacuous nonsense, you know.
People do not choose python over perl because they like Guido personally
better than Larry. Or vice versa. People aren't going to use FM because
they think I'm abrasive??? C'mon, Henning doesn't believe it himself,
I'm sure, it's such obvious nonsense....
Anyway, when I pointed out the less-than-honest, rigged nature, of some
of the arguments that Henning had produced in the past, and that this
had led to extreme tension, shall we say, I was not engaging in ad-hominem.
There has definitely been something of an honesty deficit in my
communications with people. And that deficit has not been on my side. I
mean, this stuff about how nobody was using FM and that's why support
was removed. Really, a very contrived half-truth, that I have
deconstructed several times already. And not just me. When one of my
collaborators, Daniel Dekany pointed out the contrived nature of this
argument, Henning started insinuating that he was a nutcase and alluded
to "conspiracy theories". Pure ad-hominem...
So there's some background here that people maybe aren't up on. It is
really not so strange that I am on edge with regard to some of this.
>
> second, as far as i can tell from a users perspective, the turbine development
> team seemed to be not only cooperative, but also quite interested in putting
> freemaker support (back) into turbine.
Well, that's fine. They can do it. Given the state of Velocity
development, they probably *should*. But that has pretty much nothing to
do with me.
> they merely discussed if they should
> "bolt it on" (making some hacks here or there, if i understood correctly), or
> do it right (which would lead to a major redesign of their product).
Oh, the technical stuff is all fine.
As I explain above, I just get very sensitized to hearing nonsense.
That's all.
> from
> this point of view, you seemed to have achieved your goal.
It was never much of a goal of mine, you know. Henning brought it up on
the Velocity list. He suggested that I should provide a patch, and I
said quite matter-of-factly that that was not going to happen, since,
Turbine removed support for alternatives for rather murky non-technical
reasons, AFAICS, and my position really just had to be that, if you guys
wanted FM support back, you had to put it back yourselves.
Then Henning started all this stuff about how we were nutty conspiracy
theorists for believing that the removal of FM or WM support and leaving
only Vel support was political in nature.
> on the other hand, if you're not satisfied with the path the developers want
> to take, it is of no use to get personal, start insulting people and whine
> about how much this or that sucks. this *is* open source. if you want it
> another way, code it. if the dev-team doesn't accept your changes, fork.
You seem confused. There's nothing to fork from my POV. I am not
involved in Turbine.
And do understand that I don't really get anything out of this. There
are half a dozen MVC frameworks that interoperate with FM at this point.
>
> third, ad hominem arguments are unacceptable.
My observation of these communities does not bear that out. It seems
that ad-hominem and all sorts of other assorted fallacious argumentation
is acceptable as long as it emanates from certain people.
However, when you point out the fallacies, people start pointing at you
and saying that *you* are the one engaging in ad hominem etcetera.
Well... I can't believe that I'm the only one who can see through this.
>
> fourth, permanently producing the shortcomings (or perceived shortcomings) of
> velocity does not make freemaker any better.
As far as that goes, yes. However, the fact is that FM and Vel are
competitors. A review of a product in a given space is necessarily based
largely on a comparison with alternatives in the same space -- whether
that product is a sports-car or a refrigerator or whatever.
To point out that a competing product is deficient in a certain way may
not be considered "nice". However, it really is perfectly fair and the
only grievance you could express in this respect would be if my
statements were false.
Moreover, most of Velocity's success is due to positioning. Everybody
knows that, right? So, to expect me, when competing at such a
disadvantage, to pull any punches, does not seem reasonable.
In short, it is completely fair for me to point out deficiencies in
Velocity. It is also completely fair for me to point out that there is
no ongoing development. (This is a first-order meta-deficiency because
it means that any existing deficiencies will never be remedied.)
>
> fifth, ad hominem arguments are unacceptable.
>
> thanks for your time. i'm always interested in a constructive discussion about
> the future of a tool i use, but this is getting out of hand.
I think it appropriate to re-iterate what I said in a previous message.
If you want to foment constructive discussion and activity, I think you
first need to foment more honesty in the basic culture here.
You guys should stop these attempts to spin and distort what's really
going on.
Look, FreeMarker has a very productive development culture. We're
abrasive, but we really get the job done. I think a lot of it is that
we're honest. That's not a moralistic thing, maybe, so much as
pragmatic. I mean, once you stop expending a high percentage of your
efforts trying to bullshit one another, it really becomes amazing what
can be achieved.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> peter
>
>
> - --
> |-
> | peter riegersperger <ri...@subnet.at>
> |-
> | subnet
> | platform for media art and experimental technologies
> |-
> | http://www.subnet.at/
> |-
> | muehlbacherhofweg 5 // 5020 salzburg // austria
> |-
> | fon/fax +43/662/842 897
> |-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE+8xYtIMP39JYOy9IRAvJGAJ0ZW3atNJMjt7FoDPc8olUWQPRzPwCfcXvo
> 56B69uwJjsfw80wiH8ttHXo=
> =nnzg
> -----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by peter riegersperger <ri...@subnet.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
jonathan, as a turbine-user, i think i've got the point now.
but, please let me add some notes about style:
first of all, ad hominem arguments are unacceptable.
second, as far as i can tell from a users perspective, the turbine development
team seemed to be not only cooperative, but also quite interested in putting
freemaker support (back) into turbine. they merely discussed if they should
"bolt it on" (making some hacks here or there, if i understood correctly), or
do it right (which would lead to a major redesign of their product). from
this point of view, you seemed to have achieved your goal.
on the other hand, if you're not satisfied with the path the developers want
to take, it is of no use to get personal, start insulting people and whine
about how much this or that sucks. this *is* open source. if you want it
another way, code it. if the dev-team doesn't accept your changes, fork.
third, ad hominem arguments are unacceptable.
fourth, permanently producing the shortcomings (or perceived shortcomings) of
velocity does not make freemaker any better.
fifth, ad hominem arguments are unacceptable.
thanks for your time. i'm always interested in a constructive discussion about
the future of a tool i use, but this is getting out of hand.
peter
- --
|-
| peter riegersperger <ri...@subnet.at>
|-
| subnet
| platform for media art and experimental technologies
|-
| http://www.subnet.at/
|-
| muehlbacherhofweg 5 // 5020 salzburg // austria
|-
| fon/fax +43/662/842 897
|-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+8xYtIMP39JYOy9IRAvJGAJ0ZW3atNJMjt7FoDPc8olUWQPRzPwCfcXvo
56B69uwJjsfw80wiH8ttHXo=
=nnzg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Jeffrey D. Brekke wrote:
> "Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
>
> I usually don't reply like this, but Henning did such a great job
> explaining himself, that I just must quote his message and echo that
> these are my sentiments also.
Ah, yes, Henning's "you're such a bad guy" diatribe. I said at the end
of my last note that people were bound to engage in more of this. It's
to be expected. I say certain negative things about this community, so
you come out with this. Of course, it does have one sad aspect. I mean,
it's like you're too lame to write your own "you're such a bad guy"
diatribe, so you copy-paste Henning's. :-) A bit like Rush Limbaugh and
the "ditto-heads" -- people who are too lame to come up with their own
looney right-wing diatribe, so they just listen to Rush's diatribe and
scream "Ditto!".
Of course, the stuff about what bad guy I am is completely irrelevant.
The comments I made in my last note were good-faithed and truthful.
There are some real issues in terms of the culture here. One aspect of
this that I didn't emphasize much is the complete lack of what I would
call graciousness here. Or appreciativeness.
FreeMarker is specifically designed as a component for the View layer of
an MVC web app. The existence of that project provides key technology
for Turbine and projects similar to Turbine. You can leverage that
technology or not, but it actually does make sense to be somewhat
appreciative towards the people who made that option available. There is
a lot of hard work in there, you know.
This whole subtext, where you'd be doing us a favor by using our work,
is really quite something. You and Henning and others do not have a
sense of just how ill-bred and obnoxious you come across to me. I think
this utter lack of graciousness is a key aspect to it.
Now, all of the above is non-technical in nature. What also gets me
about about all of this is that I recently looked at the various turbine
docs and everything, and I get the feeling of something that is very
complex and possibly overabstracted -- the XXX service, the YYY service,
and so on.
Yet, for all of the layers of abstraction, to support multiple template
engines on an equal footing apparently requires some significant
refactoring of the code. Isn't there something rather strange about this?
I mean, what's the point of having such a highly abstracted framework
then? I don't have the time or energy to investigate this too closely,
but it makes me wonder whether the emperor is just wearing no clothes.
Maybe that is why there is some amount of defensiveness about the whole
topic.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
>
>>Jonathan Revusky <jo...@revusky.com> writes:
>>
>>
>>>Tell me the truth. Wouldn't it piss you off to have somebody lay this
>>>load of bullshit on you?
>>
>>[...]
>>
>>>is probably about as useful as tits on a nun. But it makes for a
>>>good buzzword to add to your feature list...
>>
>>[...]
>>
>>I will stop talking to you now. I really have enough.
>>
>>It doesn't seem to be possible to discuss technical facts without
>>getting either dragged into some long and winded metaphorical
>>discussion behind which you always see a cabal. You style of putting
>>personal accusations and dismissing every technical explanation as
>>"blatant", "I always knew that" and "I'm not interested in that" while
>>simply not listening to facts, is to me both confusing and revolting.
>>
>>If you want to discuss technical things, come over to -dev. If you
>>want to help us integrating FM in a clean and turbine-like way, come
>>over to -dev. If you don't want to help us, please stay away.
>>
>>If you want to do ASF bashing, Velocity bashing or just continue to
>>actively drive people that once were neutral to FM away, please go
>>somewhere else.
>>
>>But sorry, I honestly tried to describe you the situation as it was
>>when I came to Turbine 18 months ago. I don't have "3+ years of
>>experience with Turbine" as you claim.
>>
>>To me, you come over as a mischief-maker which tries to promote his
>>own project/product not by talking about its merits but by putting
>>other projects down. This isn't exactly the style and spirit that I
>>consider helpful for developing open source. I have better things to
>>do than getting into a pissing match with you.
>>
>>
>>>If you have any FM-specific issues, we have mailing lists and we'll
>>>be quite helpful if you ask any questions there.
>>
>>After your posing here and on velocity-user I have serious trouble to
>>believe that. But if the need crops out, I might try this out. ATM I'm
>>pretty sure that with your obnoxious and demanding style you drove
>>most readers of this mailing list as far away from FM as possible. At
>>least you achieved this with me. You can be proud on this and laugh
>>long and hard now.
>>
>> 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
>>
>>---------------------------------------------------------------------
>>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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Blair Martin <bm...@earthlink.net>.
> I usually don't reply like this, but Henning did such a great job
> explaining himself, that I just must quote his message and echo that
> these are my sentiments also.
....
> > If you want to do ASF bashing, Velocity bashing or just continue to
> > actively drive people that once were neutral to FM away, please go
> > somewhere else.
No doubt. I knew little about FM before but became intrigued when the thread
first started. But after listening to that arrogant, humorless, spiteful,
pseudo-intellectual blowhard and his persecution complex I don't have the
stomach for ever supporting his work.
blair
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
I usually don't reply like this, but Henning did such a great job
explaining himself, that I just must quote his message and echo that
these are my sentiments also.
> Jonathan Revusky <jo...@revusky.com> writes:
>
>>Tell me the truth. Wouldn't it piss you off to have somebody lay this
>>load of bullshit on you?
> [...]
>> is probably about as useful as tits on a nun. But it makes for a
>> good buzzword to add to your feature list...
> [...]
>
> I will stop talking to you now. I really have enough.
>
> It doesn't seem to be possible to discuss technical facts without
> getting either dragged into some long and winded metaphorical
> discussion behind which you always see a cabal. You style of putting
> personal accusations and dismissing every technical explanation as
> "blatant", "I always knew that" and "I'm not interested in that" while
> simply not listening to facts, is to me both confusing and revolting.
>
> If you want to discuss technical things, come over to -dev. If you
> want to help us integrating FM in a clean and turbine-like way, come
> over to -dev. If you don't want to help us, please stay away.
>
> If you want to do ASF bashing, Velocity bashing or just continue to
> actively drive people that once were neutral to FM away, please go
> somewhere else.
>
> But sorry, I honestly tried to describe you the situation as it was
> when I came to Turbine 18 months ago. I don't have "3+ years of
> experience with Turbine" as you claim.
>
> To me, you come over as a mischief-maker which tries to promote his
> own project/product not by talking about its merits but by putting
> other projects down. This isn't exactly the style and spirit that I
> consider helpful for developing open source. I have better things to
> do than getting into a pissing match with you.
>
>> If you have any FM-specific issues, we have mailing lists and we'll
>> be quite helpful if you ask any questions there.
>
> After your posing here and on velocity-user I have serious trouble to
> believe that. But if the need crops out, I might try this out. ATM I'm
> pretty sure that with your obnoxious and demanding style you drove
> most readers of this mailing list as far away from FM as possible. At
> least you achieved this with me. You can be proud on this and laugh
> long and hard now.
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
>
>>Tell me the truth. Wouldn't it piss you off to have somebody lay this
>>load of bullshit on you?
>
> [...]
>
>>is probably about as useful as tits on a nun. But it makes for a
>>good buzzword to add to your feature list...
>
> [...]
>
> I will stop talking to you now.
I earlier apologized for calling you a clown. However, darnit, you are
making me laugh again. If you want to stop talking to somebody, just
stop talking to them. Don't say "I'm going to stop talking to you" and
then launch into some pathetic, self-righteous, phony speech.
> I really have enough.
>
> It doesn't seem to be possible to discuss technical facts without
> getting either dragged into some long and winded metaphorical
> discussion behind which you always see a cabal. You style of putting
> personal accusations and dismissing every technical explanation as
> "blatant",
I specifically pointed out that your "technical explanation" for the
removal of FM and WM support did not withstand the proverbial laugh
test. Obviously, nobody was going to use FM support that only supported
a 3-year-old version. For you to say "there's no end-user demand and
everybody is happy with Velocity" in that context was really quite
dishonest.
Everybody knows that the whole situation was completely rigged from the
get-go. FM and WM were never *really* presented as options. And we're
not debating that, right? You openly admit that FM was never *really*
supported on a par with Vel. (Something that everybody knows...)
Given that, your previous argument that FM support was axed because
there was no end-user demand was clearly not made in completely good
faith. Obviously, it was set up as a rigged, deceptive half-truth.
> "I always knew that" and "I'm not interested in that" while
> simply not listening to facts, is to me both confusing and revolting.
Well, this is pathetic posturing where you are attacking me in order to
cover up your own mendacity.
I would like you to answer the question I posed: Would it not piss you
off to have somebody lay this load of bullshit on you?
>
> If you want to discuss technical things, come over to -dev. If you
> want to help us integrating FM in a clean and turbine-like way, come
> over to -dev. If you don't want to help us, please stay away.
Well, I already told you that you could not expect any help with FM
integration. Now, I have helped other framework authors with FM
integration. I wrote the first pass on the JPublish integration.
However, there was no previous history of FM being supported and then
support being removed for murky, non-technical reasons. Given that, it
is ridiculous to think that I will help you very much. My position is as
follows:
"You removed it. If you want it, you put it back in."
You interpret this as hostile and arrogant, I suppose, but I don't think
so. I think that the logic and structure of the current situation is
such that anybody would react that way.
>
> If you want to do ASF bashing, Velocity bashing or just continue to
> actively drive people that once were neutral to FM away, please go
> somewhere else.
>
> But sorry, I honestly tried to describe you the situation as it was
> when I came to Turbine 18 months ago. I don't have "3+ years of
> experience with Turbine" as you claim.
Huh? I never claimed that. What are you talking about?
In any case, there is something odd about this. If the decision to
deprecate and then remove support for alternative template solutions and
also to tightly couple Turbine internals with Velocity API's was not
your decision, then you don't have to defend it or explain it at all.
In fact, if it was a bad decision, then just correct it. Or don't
correct it. But it has pretty much nothing to do with me.
>
> To me, you come over as a mischief-maker which tries to promote his
> own project/product not by talking about its merits but by putting
> other projects down.
In the case of Velocity, I have simply told the truth. No development
has taken place for over a year. The Velocity "fans" have continued
throughout this period to have conversations in which they discuss the
project as if ongoing development was still going on. "Could you submit
a patch for that? Maybe one of the committers will implement that for
you..."
It has seemed to me like there was a tacit understanding that they were
to continue talking about it as if it was being actively developed.
Finally, I simply looked at the commit records and saw that basically
nobody had committed any code for a year!
That pissed me off! I consider that whole thing fraudulent!
So, in recent posts, I simply pointed out that no active development was
taking place. This is a key fact that would be worth knowing for anybody
considering making an investment in that technology.
I was telling the truth. People who objected to my posts were trying to
cover up the truth. There was an intent to mislead. Given that, I rest
easy and sleep at night.
> This isn't exactly the style and spirit that I
> consider helpful for developing open source. I have better things to
> do than getting into a pissing match with you.
From my dialogues with you, and casual observation of your behavior, I
find that honesty is not one of your strong traits.
I mean, for starters, this comment that "we removed FM support because
nobody was using it" was true strictly speaking, but it was based such a
contrived, rigged argument, that it is really mendacious.
But, even your post that initiated this thread was deliberately phrased
so as to get the response (or lack thereof) that you wanted. You asked
if anybody was interested in FreeMarker.
Of course, most people here probably don't even know about FM, so you
were unlikely to get much of a response either way. I posted a response
because I felt obliged to rephrase the question as: "Is anybody
interested in decimal number support"? or it could equally be: "Is
anybody interested in a template engine that implements macros
correctly?" (You know that all macro parameters in Vel are passed as
strings that are reparsed and evaluated each time they occur in the
macro??? Heinous.)
And this latest gem, that it took you "ages" to realize that FM and WM
were not supported on an equal footing in Turbine. C'mon, it took you
ages to realize that? I could give you the benefit of the doubt on that,
I suppose, but c'mon... *nobody* is that bloody stupid!
I mean, why all the phony posturing? Why this attempt to bullshit
people? It's like a pathology, a compulsion or something....
>
>
>>If you have any FM-specific issues, we have mailing lists and we'll
>>be quite helpful if you ask any questions there.
>
>
> After your posing here and on velocity-user I have serious trouble to
> believe that.
<sigh> You can believe what you find convenient to believe, and you can
even repeat things on that basis if you want. However, these are open
communities and there is a record of everything that goes on.
Look at the archives. For example, look at the Velocity-user archives
and try to find the last time anybody requested a feature and it was
implemented. Carry out the same investigation looking at the FM
archives. See when the last time anybody requested a feature was and it
was implemented.
You will very quickly see which community is more helpful and responsive.
>But if the need crops out, I might try this out. ATM I'm
> pretty sure that with your obnoxious and demanding style you drove
> most readers of this mailing list as far away from FM as possible.
Henning, that you think that everybody makes technical decisions on
completely non-technical grounds says more about you than it does about
anything else. In terms of my abrasiveness driving people away from FM,
well, look at the FM-devel archives.
http://sourceforge.net/mailarchive/forum.php?forum_id=7170
I took over the project in early 2002. You will note that, before that,
there were rarely more than a few dozen posts in a month. Now, there are
hundreds of messages a month. This does not bear out the idea that my
"style" drives people away.
As regards my "demanding style", well, yes, in certain regards, I am
demanding. And I sense that you are not used to people who are demanding
in this way.
You see, I have a very low tolerance for dishonesty. If you lie or
otherwise dissemble, I will simply point it out. I don't even think it's
a moralistic thing really. It's pragmatic also. You just cannot make any
progress in open source, or in technical fields generally, without honesty.
You can't bullshit the compiler when it says your source file is
invalid. When I see significant levels of dishonesty in a community,
such as in the Velocity camp, I immediately assume that very little
quality technical work can be taking place.
I think that if you want to move things forward, you have to foment more
honesty in your community. It does seem to be lacking.
> At
> least you achieved this with me. You can be proud on this and laugh
> long and hard now.
The truth is that I feel sorry for you. You were caught in a lie,
Henning, and you're just making matters worse. Anybody can see that.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
FreeMarker 2.3pre4 is out!
>
> Regards
> Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jonathan Revusky <jo...@revusky.com> writes:
>Tell me the truth. Wouldn't it piss you off to have somebody lay this
>load of bullshit on you?
[...]
> is probably about as useful as tits on a nun. But it makes for a
> good buzzword to add to your feature list...
[...]
I will stop talking to you now. I really have enough.
It doesn't seem to be possible to discuss technical facts without
getting either dragged into some long and winded metaphorical
discussion behind which you always see a cabal. You style of putting
personal accusations and dismissing every technical explanation as
"blatant", "I always knew that" and "I'm not interested in that" while
simply not listening to facts, is to me both confusing and revolting.
If you want to discuss technical things, come over to -dev. If you
want to help us integrating FM in a clean and turbine-like way, come
over to -dev. If you don't want to help us, please stay away.
If you want to do ASF bashing, Velocity bashing or just continue to
actively drive people that once were neutral to FM away, please go
somewhere else.
But sorry, I honestly tried to describe you the situation as it was
when I came to Turbine 18 months ago. I don't have "3+ years of
experience with Turbine" as you claim.
To me, you come over as a mischief-maker which tries to promote his
own project/product not by talking about its merits but by putting
other projects down. This isn't exactly the style and spirit that I
consider helpful for developing open source. I have better things to
do than getting into a pissing match with you.
> If you have any FM-specific issues, we have mailing lists and we'll
> be quite helpful if you ask any questions there.
After your posing here and on velocity-user I have serious trouble to
believe that. But if the need crops out, I might try this out. ATM I'm
pretty sure that with your obnoxious and demanding style you drove
most readers of this mailing list as far away from FM as possible. At
least you achieved this with me. You can be proud on this and laugh
long and hard now.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jeffery Painter <pa...@kiasoft.com>.
Jonathan and other FM evanglizers, I don't recall ever seeing you post to
this list before, although I've only been a user for a little less than
a year, and I believe you even stated that you do not use
turbine. This is the turbine-users group and not the turbine-dev.
While I find it interesting to hear all the things freemarker supports, I
do not really find this pertinent exactly to turbine-users support group,
which is largely what this list is used for.
This seems more like a turbine-dev discussion to me.
Thank you,
Jeff Painter
painter@kiasoft.com
On Fri, 20 Jun 2003, Jonathan Revusky wrote:
> Henning P. Schmiedehausen wrote:
> > "Quinton McCombs" <qm...@nequalsone.com> writes:
>
> <snip>
>
> > Jonathan, what you don't see (and I don't hold it against you, it took
> > me ages to understand this), is the fact that the FM and WM support in
> > Turbine was never on pair with the velocity support.
>
> <ROTFL>
>
> Henning, it may have taken *you* ages to realize that, but.... I'm a
> pretty perceptive guy. I can say quite honestly that I *always* knew
> that... :-)
>
> I'm not saying that I knew all the technical details you are outlining,
> but they're residual trivia from my POV. For starters, I knew that the
> FM support in Turbine was a joke, since it only worked with a 3-year-old
> version of FM!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> "Quinton McCombs" <qm...@nequalsone.com> writes:
<snip>
> Jonathan, what you don't see (and I don't hold it against you, it took
> me ages to understand this), is the fact that the FM and WM support in
> Turbine was never on pair with the velocity support.
<ROTFL>
Henning, it may have taken *you* ages to realize that, but.... I'm a
pretty perceptive guy. I can say quite honestly that I *always* knew
that... :-)
I'm not saying that I knew all the technical details you are outlining,
but they're residual trivia from my POV. For starters, I knew that the
FM support in Turbine was a joke, since it only worked with a 3-year-old
version of FM!
> The various
> screen and navigation classes for Velocity were always more powerful
> that the FM and WM support, which was only "bolted on". And this
> (technical) aspect is IMHO the main reason that it wasn't really used.
That the FM support was not used is hardly something that requires much
explanation.
You enter a dining room and are told that you have a choice between a
meat and a fish entree. However, you immediately notice that everybody
else is eating meat. You ponder for a while, considering whether to
order fish or meat. The waiter then whispers to you: "Order the meat."
It turns out that the fish is 3 days old.
So, like everybody else, you order the meat. Nobody ever orders the fish.
Eventually, the fish is removed from the menu and the only thing offered
is the meat dish.
Somebody later proposes that fish be added as an option. This runs into
the following objection:
"Nobody wants fish."
"How do you know that?"
"We used to have it on the menu and nobody ordered it."
This is the dialectic that has been going on here. I mean, the
contrived, rigged nature of the scenario is blatantly obvious. Yet you
expressed surprise when I and another FreeMarker developer (Daniel
Dekany) got increasingly annoyed with you in that dialogue on the Vel list.
"We removed the fish from the menu because apparently nobody wants to
eat fish...."
Yeah, uh-huh. Right...
Tell me the truth. Wouldn't it piss you off to have somebody lay this
load of bullshit on you?
>
> Look at the JSP view in Turbine. Yes, you can render JSPs with the
> Turbine servlet, but the possibilities, especially in terms of the
> pull code, are terribly limited. If you're looking for a political
> decision in Turbine, then it is the fact that the JSP View was kept
> even though it isn't really good but keeping it gave us another
> "feature" when managers were looking for a web framework to use. :-)
> (The average manager is able to distinguish between "JSP" and "a
> templating solution" but not between "some templating solutions to
> choose from").
Yeah, it doesn't surprise me to hear that the JSP support is largely
political. I assume that XSLT support would be as well. XSLT (at least
in this MVC webapp context) is probably about as useful as tits on a
nun. But it makes for a good buzzword to add to your feature list...
>
> Putting the existing FM classes back into Turbine and getting them to
> work with the most recent FM release might be a work of some
> hours. But it won't really help the FM support in Turbine, because you
> would be back at the situation described above. One really well
> supported templating engine (Velocity) and one (or more) basically
> useable but severely limited engines (FM, WM, you name it). It would
> IMHO even hurt the FM support in the long run because one of the
> arguments to work on a template engine independent solution would no
> longer be valid.
Is there something besides the coupling with the VelocityContext API
that is at issue? I already gave you a simple path-of-least-resistance
solution to that.
>
> So IMHO we will have to make core code changes to get this stuff to
> fly right. And this is neither the work of hours but of days or weeks
> and we will have to make user-visible changes which is a work of
> releases.
Well, it sounds like you do need to carry out some significant code
refactoring. But that's not anything that I can help you with. If you
have any FM-specific issues, we have mailing lists and we'll be quite
helpful if you ask any questions there.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
FreeMarker 2.3pre4 is out!
>
> Regards
> Henning
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Colin Chalmers <co...@maxware.nl>.
<snip>
I think this is a very good idea. I would like to propose that we
consider supporting Velocity, JSP, XSLT, and perhaps FM as equally
supported templating solutions. I think that by having this as a design
goal we will end up with a truly pluggable solution.
</snip>
Good idea to define the scope before hand and looks a good achievable list
to me
Colin
----- Original Message -----
From: "Quinton McCombs" <qm...@nequalsone.com>
To: "'Turbine Users List'" <tu...@jakarta.apache.org>;
<hp...@intermeta.de>
Sent: Thursday, June 19, 2003 6:28 PM
Subject: RE: Decimal Number support
> > -----Original Message-----
> > From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> > Sent: Thursday, June 19, 2003 10:59 AM
> > To: turbine-user@jakarta.apache.org
> > Subject: Re: Decimal Number support
> >
> >
> > "Quinton McCombs" <qm...@nequalsone.com> writes:
> >
> > >Hennings idea to create a proxy class to represent the context type
> > >object of the underlying view is indeed a good way to solve this
> > >problem. It would require deprecating the methods that everyone
> > >normally overrides in the screen and action classes. The
> > replacement
> > >would be virtually the same interface replacing Context with the new
> > >class.
> >
> > As you already met one of the other big problems of our core
> > code (the fragility of some services that depend on the
> > correct init sequence), the best will be to rip out the
> > current Template, Pull, JSP and Velocity Service completely
> > (BTW: Everything under o.a.t.modules would go with this, too)
> > (rip out in this case means: Deprecate post-2.3) and replace
> > this with a new, pluggable architecture where the support for
> > a concrete templating engine is pretty much an afterthought.
>
> I think this is a very good idea. I would like to propose that we
> consider supporting Velocity, JSP, XSLT, and perhaps FM as equally
> supported templating solutions. I think that by having this as a design
> goal we will end up with a truly pluggable solution.
>
> > The current Turbine view structure doesn't allow this. The
> > Code in Fulcrum is a little further down this road but it is
> > not really good, either.
> >
> > I'm not ashamed to admit that I will look around at Summit,
> > T3 and some more frameworks to 'steal' good ideas and I'm
> > pretty sure that I can come up with some more (even though I
> > might be accused of "just reinventing the wheel one more time
> > :-) ). But in the end I want to have all of this to be
> > _TURBINE_ code and support for a templating engine will be by
> > adding an adaptor for its context-like element (I'm pretty
> > sure that such a bugger is at the core of most templating
> > engines, because it is an easy way to get stuff from java to
> > template code), a factory to create new render elements and
> > then some extensions to screen and layout to plug it into the
> > template service.
>
> Summit does at least have a proxy class for the context type objects of
> the various templating engines. That is about as far as I have looked
> into Summits approach to pluggable view layers.
>
> > After all, our "class -> template" matching code is something
> > pretty unique in the web framework world and having the
> > ability to back layout and screen templates with java code,
> > build navigation structures from templates and match
> > templates with "superclasses" e.g. for the authentication is
> > something pretty unique to Turbine. I do want to keep this.
> >
> > Jonathan, what you don't see (and I don't hold it against
> > you, it took me ages to understand this), is the fact that
> > the FM and WM support in Turbine was never on pair with the
> > velocity support. The various screen and navigation classes
> > for Velocity were always more powerful that the FM and WM
> > support, which was only "bolted on". And this
> > (technical) aspect is IMHO the main reason that it wasn't really used.
> >
> > Look at the JSP view in Turbine. Yes, you can render JSPs
> > with the Turbine servlet, but the possibilities, especially
> > in terms of the pull code, are terribly limited. If you're
> > looking for a political decision in Turbine, then it is the
> > fact that the JSP View was kept even though it isn't really
> > good but keeping it gave us another "feature" when managers
> > were looking for a web framework to use. :-) (The average
> > manager is able to distinguish between "JSP" and "a
> > templating solution" but not between "some templating
> > solutions to choose from").
>
> Very true. This is why I would like to see multiple templating engines
> have equal support within Turbine.
>
> > Putting the existing FM classes back into Turbine and getting
> > them to work with the most recent FM release might be a work
> > of some hours. But it won't really help the FM support in
> > Turbine, because you would be back at the situation described
> > above. One really well supported templating engine (Velocity)
> > and one (or more) basically useable but severely limited
> > engines (FM, WM, you name it). It would IMHO even hurt the FM
> > support in the long run because one of the arguments to work
> > on a template engine independent solution would no longer be valid.
> >
> > So IMHO we will have to make core code changes to get this
> > stuff to fly right. And this is neither the work of hours but
> > of days or weeks and we will have to make user-visible
> > changes which is a work of releases.
> >
> > 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
> >
> > ---------------------------------------------------------------------
> > 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-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Decimal Number support
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Thursday, June 19, 2003 10:59 AM
> To: turbine-user@jakarta.apache.org
> Subject: Re: Decimal Number support
>
>
> "Quinton McCombs" <qm...@nequalsone.com> writes:
>
> >Hennings idea to create a proxy class to represent the context type
> >object of the underlying view is indeed a good way to solve this
> >problem. It would require deprecating the methods that everyone
> >normally overrides in the screen and action classes. The
> replacement
> >would be virtually the same interface replacing Context with the new
> >class.
>
> As you already met one of the other big problems of our core
> code (the fragility of some services that depend on the
> correct init sequence), the best will be to rip out the
> current Template, Pull, JSP and Velocity Service completely
> (BTW: Everything under o.a.t.modules would go with this, too)
> (rip out in this case means: Deprecate post-2.3) and replace
> this with a new, pluggable architecture where the support for
> a concrete templating engine is pretty much an afterthought.
I think this is a very good idea. I would like to propose that we
consider supporting Velocity, JSP, XSLT, and perhaps FM as equally
supported templating solutions. I think that by having this as a design
goal we will end up with a truly pluggable solution.
> The current Turbine view structure doesn't allow this. The
> Code in Fulcrum is a little further down this road but it is
> not really good, either.
>
> I'm not ashamed to admit that I will look around at Summit,
> T3 and some more frameworks to 'steal' good ideas and I'm
> pretty sure that I can come up with some more (even though I
> might be accused of "just reinventing the wheel one more time
> :-) ). But in the end I want to have all of this to be
> _TURBINE_ code and support for a templating engine will be by
> adding an adaptor for its context-like element (I'm pretty
> sure that such a bugger is at the core of most templating
> engines, because it is an easy way to get stuff from java to
> template code), a factory to create new render elements and
> then some extensions to screen and layout to plug it into the
> template service.
Summit does at least have a proxy class for the context type objects of
the various templating engines. That is about as far as I have looked
into Summits approach to pluggable view layers.
> After all, our "class -> template" matching code is something
> pretty unique in the web framework world and having the
> ability to back layout and screen templates with java code,
> build navigation structures from templates and match
> templates with "superclasses" e.g. for the authentication is
> something pretty unique to Turbine. I do want to keep this.
>
> Jonathan, what you don't see (and I don't hold it against
> you, it took me ages to understand this), is the fact that
> the FM and WM support in Turbine was never on pair with the
> velocity support. The various screen and navigation classes
> for Velocity were always more powerful that the FM and WM
> support, which was only "bolted on". And this
> (technical) aspect is IMHO the main reason that it wasn't really used.
>
> Look at the JSP view in Turbine. Yes, you can render JSPs
> with the Turbine servlet, but the possibilities, especially
> in terms of the pull code, are terribly limited. If you're
> looking for a political decision in Turbine, then it is the
> fact that the JSP View was kept even though it isn't really
> good but keeping it gave us another "feature" when managers
> were looking for a web framework to use. :-) (The average
> manager is able to distinguish between "JSP" and "a
> templating solution" but not between "some templating
> solutions to choose from").
Very true. This is why I would like to see multiple templating engines
have equal support within Turbine.
> Putting the existing FM classes back into Turbine and getting
> them to work with the most recent FM release might be a work
> of some hours. But it won't really help the FM support in
> Turbine, because you would be back at the situation described
> above. One really well supported templating engine (Velocity)
> and one (or more) basically useable but severely limited
> engines (FM, WM, you name it). It would IMHO even hurt the FM
> support in the long run because one of the arguments to work
> on a template engine independent solution would no longer be valid.
>
> So IMHO we will have to make core code changes to get this
> stuff to fly right. And this is neither the work of hours but
> of days or weeks and we will have to make user-visible
> changes which is a work of releases.
>
> 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
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>Hennings idea to create a proxy class to represent the context type
>object of the underlying view is indeed a good way to solve this
>problem. It would require deprecating the methods that everyone
>normally overrides in the screen and action classes. The replacement
>would be virtually the same interface replacing Context with the new
>class.
As you already met one of the other big problems of our core code (the
fragility of some services that depend on the correct init sequence),
the best will be to rip out the current Template, Pull, JSP and
Velocity Service completely (BTW: Everything under o.a.t.modules would
go with this, too) (rip out in this case means: Deprecate post-2.3)
and replace this with a new, pluggable architecture where the support
for a concrete templating engine is pretty much an afterthought.
The current Turbine view structure doesn't allow this. The Code in
Fulcrum is a little further down this road but it is not really good,
either.
I'm not ashamed to admit that I will look around at Summit, T3 and
some more frameworks to 'steal' good ideas and I'm pretty sure that I
can come up with some more (even though I might be accused of "just
reinventing the wheel one more time :-) ). But in the end I want to
have all of this to be _TURBINE_ code and support for a templating
engine will be by adding an adaptor for its context-like element (I'm
pretty sure that such a bugger is at the core of most templating
engines, because it is an easy way to get stuff from java to template
code), a factory to create new render elements and then some
extensions to screen and layout to plug it into the template service.
After all, our "class -> template" matching code is something pretty
unique in the web framework world and having the ability to back
layout and screen templates with java code, build navigation
structures from templates and match templates with "superclasses"
e.g. for the authentication is something pretty unique to Turbine. I
do want to keep this.
Jonathan, what you don't see (and I don't hold it against you, it took
me ages to understand this), is the fact that the FM and WM support in
Turbine was never on pair with the velocity support. The various
screen and navigation classes for Velocity were always more powerful
that the FM and WM support, which was only "bolted on". And this
(technical) aspect is IMHO the main reason that it wasn't really used.
Look at the JSP view in Turbine. Yes, you can render JSPs with the
Turbine servlet, but the possibilities, especially in terms of the
pull code, are terribly limited. If you're looking for a political
decision in Turbine, then it is the fact that the JSP View was kept
even though it isn't really good but keeping it gave us another
"feature" when managers were looking for a web framework to use. :-)
(The average manager is able to distinguish between "JSP" and "a
templating solution" but not between "some templating solutions to
choose from").
Putting the existing FM classes back into Turbine and getting them to
work with the most recent FM release might be a work of some
hours. But it won't really help the FM support in Turbine, because you
would be back at the situation described above. One really well
supported templating engine (Velocity) and one (or more) basically
useable but severely limited engines (FM, WM, you name it). It would
IMHO even hurt the FM support in the long run because one of the
arguments to work on a template engine independent solution would no
longer be valid.
So IMHO we will have to make core code changes to get this stuff to
fly right. And this is neither the work of hours but of days or weeks
and we will have to make user-visible changes which is a work of
releases.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Bill wrote:
> Jonathan
>
> Based on this:
>
>>>Jonathan, some technical information (which you as a non-Turbine guy
>>>
>>>>might not have seen yet): Unfortunately the o.a.velocity.Context is
>>>>buried pretty deep in the Turbine code (this is legacy of the original
>>>>turbine developers). So we will have to replace this in every place
>>>>with an Adapter class with plugs either onto the Velocity Context or a
>>>>similar class in every other view solution (FreeMarker, WebMacro
>>>>etc.).
>>>>
>>>>Doing so, it would be necessary for all of our users to change the
>>>>imports in their self-written classes (Action, Screen), because the
>>>>Context is part of the signature of the methods which are overloaded
>>>>by user classes.
>>>>
>>>>If we don't do this but just 'bolt FM support on' by using different
>>>>classes, there wouldn't be much won, because people would still use
>>>>VelocityScreen, VelocityPage etc. just as in all the example code
>>>>around and the FM code would start to rot (again). I don't want this,
>>>>because it wouldn't buy much for the Turbine users.
>>>>So we would need some major core changes to allow developers to simply
>>>>switch views without having to rewrite all of their classes later.
>
>
> In addition, I based my point on the fact that the current developers
> obviously already made such a determination when they made the decision
> to stop supporting it.
Well, that just begs the question, doesn't it? That a decision was made
in the past does not logically demonstrate that said decision was correct.
>
> I maybe did not express my point clearly enough, if this is merely a
> matter of adding Freemarker support for political reasons, its a waste
> of time.
Look, you don't have to look very far for non-political reasons to
support FreeMarker in addition to Velocity. For starters, FreeMarker is
a much more powerful tool. I pointed to a list of features that bears
this out. Not only that, but Velocity is basically a dead project. To
all intents and purposes, nobody has committed any new code there for a
year. Bug reports are ignored. Feature requests are dismissed with
rather specious arguments. Anybody who realizes the state of that
project could well be given pause by the fact that Turbine offers no
alternative. At this stage, it is likely to cause you to lose potential
users.
But, even besides all of that, it is simply better to offer a choice!
Choice is clearly advantageous. I might always vote for the same
political party but that does not mean that I am in favor of a one-party
state!
Since choice is clearly beneficial and adds value, it is the *removal*
of FreeMarker and Webmacro as options that seems easier to characterize
as "political" than vice versa. Giving users *more* options tends to add
value and there is no particular reason to infer political motivations.
> Not just the developers, but all of ours. The simple fact is
> I do not remember any amount of clamor over the decision to withdraw
> support of FM and WM. When the decision was announced to the list, my
> stance was that having support for these technologies was good for
> Turbine but it didnt make sense if no one was using them. If there were
> enough users to justify the work, then I dont think that support would
> have been withdrawn.
Well, Henning also trotted out this thing about nobody using FreeMarker.
I'm sure it's true, but OTOH, c'mon, it's really something of a half-truth.
You see, there was only support for a very obsolete version of
FreeMarker, 1.5.2 IIRC. Nobody interested in using FreeMarker would
gravitate towards a framework that only supported 1.5.2. As of this
writing, the current stable version of FM is 2.2 and the development
version is 2.3. So that means we've gone through a 2.0, a 2.1, and 2.2
release cycles. And take a look at all the features that have been added.
It's really like supporting the use of java, but by supporting JDK
1.0.2. Now, obviously, nobody uses that java support, because nobody
interested in using Java wants to code to 1.0.2. They all want to use a
more up-to-date version. Nonetheless, you say that nobody is using java,
so obviously nobody is interested in Java.
By the same token, nobody interested in FreeMarker would gravitate
towards a product that only supports FM 1.5.2.
Even aside from that, another obvious reason everybody would use
Velocity is that it was set up as the default. Anybody who understands
this industry understands the power of being the "default". This is the
"secret" behind the success of Microsoft products. They are positioned
as the default in their space.
And, of course, when you realize the positioning involved, where
Velocity is a fellow Jakarta/Apache project...
To be able to say in a good-faithed manner that nobody was interested in
FM and WM, you would have had to present the various solutions on at
least somewhat equal footing and let people make their choice. I'm quite
sure that never happened. You would have to be supporting up-to-date
versions of the tools. So, what you're talking about is the result of a
completely rigged experiment. "We gave people the option and nobody was
interested".
C'mon, guys....
But that's all water under the bridge anyway. At this stage of history,
certainly, given FreeMarker's current lead over Velocity technically, it
is hard to imagine that the two could be offered on a reasonably equal
footing and that everybody would opt for Velocity. Many people would
compare and opt for FM.
>
> If I understand the current path of Turbine, its continuing development
> is targeted at eventually moving users to Avalon. I assume that as this
> transition takes place, services will be built more view independent.
> So I dont think it makes a lot of sense to devote resources to reversing
> the previous decision in the current Turbine code.
>
> I am not a Velocity proponent, the decision to use Velocity was made
> before I came to this company. Velocity would not have been my choice.
>
> All that being said, I have nothing against Freemarker, but I have no
> intention of supporting a decision to re-support a technology that
> doesnt seem to be used by the community, and will cause everyone in the
> community to perform a migration.
Well, I don't know all the internals of Turbine, and I don't really care
to, but if you can't add FM support in such a way that it causes no
inconvenience to existing users who want to continue with Vel, it just
means that Turbine is rather poorly architected.
Now, as a final note, I have been reluctant to be in this conversation.
I do not want to give the impression that I care very much whether
Turbine supports FM or not. Because I don't. Still, I was curious what
was going on with this discussion, and there were certain things said,
arguments made, to which I could not help but reply, as I did above.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarke.org/fmVsVel.html
Velocity->FreeMarker template conversion tool,
http://freemarker.org/usCavalry.html
>
> Just my $.02
>
>
>
> On Wed, 2003-06-18 at 10:47, Jonathan Revusky wrote:
>
>>Bill wrote:
>>
>>>Henning
>>>
>>>I think working on Freemarker support would be a waste of the developers
>>>valuable time.
>>
>>Bill,
>>
>>I'm curious. Have you made some kind of point estimate on how long it
>>would take developers to put back in the FM support?
>>
>>Surely, it being a waste of time depends on how much time it actually
>>is, doesn't it?
>>
>>
>>
>>>However, divorcing Turbine from Velocity to allow more
>>>flexibility not only seems like a good idea, it seems absolutely
>>>necessary if the I understand the path to Avalonization.
>>
>>What is Avalonization?
>>
>>Regards,
>>
>>Jonathan Revusky
>>--
>>lead developer, FreeMarker project, http://freemarker.org/
>>FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
>>FreeMarker 2.3pre4 is out!
>>
>>
>>
>>
>>>-b
>>>
>>>
>>>
>>>On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
>>>
>>>
>>>>Jonathan Revusky <jo...@revusky.com> writes:
>>>>
>>>>
>>>>
>>>>>Henning P. Schmiedehausen wrote:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>>>>
>>>>>I believe the question should maybe be rephrased:
>>>>
>>>>>Is any one of you needing or missing decimal number support in Velocity?
>>>>
>>>>Ok,
>>>>
>>>>Folks, is anyone of you missing <insert your feature here that FM
>>>>supports and Velocity does not> from the View portion of Turbine?
>>>>
>>>>You will find a feature complete list on http://www.freemarker.org for
>>>>FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
>>>>
>>>>If yes, would you consider a switch from Velocity to FreeMarker as
>>>>View for Turbine or would you get a pull tool to support this feature?
>>>>
>>>>The reason for this (and Jonathans' response): On the Velocity lists,
>>>>there has been some rumbling about the current development state of
>>>>Velocity and talking about alternatives to it. As we (Turbine) did
>>>>remove the (quite aged and not actively maintained) FreeMarker support
>>>>post Turbine-2.2, there have been some accusations of doing this
>>>>because of "political reasons". As I was not really involved in the FM
>>>>stuff or its removal, I'm trying to collect opinions from the Turbine
>>>>users about getting FM support back into Turbine. However, if noone
>>>>wants to use it, it wouldn't make much sense and the change itself is
>>>>(IMHO) quite a major one to support FM really good.
>>>>
>>>>Jonathan, some technical information (which you as a non-Turbine guy
>>>>might not have seen yet): Unfortunately the o.a.velocity.Context is
>>>>buried pretty deep in the Turbine code (this is legacy of the original
>>>>turbine developers). So we will have to replace this in every place
>>>>with an Adapter class with plugs either onto the Velocity Context or a
>>>>similar class in every other view solution (FreeMarker, WebMacro
>>>>etc.).
>>>>
>>>>Doing so, it would be necessary for all of our users to change the
>>>>imports in their self-written classes (Action, Screen), because the
>>>>Context is part of the signature of the methods which are overloaded
>>>>by user classes.
>>>>
>>>>If we don't do this but just 'bolt FM support on' by using different
>>>>classes, there wouldn't be much won, because people would still use
>>>>VelocityScreen, VelocityPage etc. just as in all the example code
>>>>around and the FM code would start to rot (again). I don't want this,
>>>>because it wouldn't buy much for the Turbine users.
>>>>So we would need some major core changes to allow developers to simply
>>>>switch views without having to rewrite all of their classes later.
>>>>
>>>>If we want to have engine-independent view support which is equal for
>>>>all templating solutions (and not heavily Velocity based as the
>>>>current view is, which is one of the reasons why noone really uses FM
>>>>and/or WebMacro with Turbine and the code started to rot), we will
>>>>have to make this (major) change. This is something that affects all
>>>>of our users and we will listen to them.
>>>>
>>>>
>>>>
>>>>>Is anybody missing any of those features?
>>>>
>>>>Please send opinions to this list. Turbine 2.3 is pretty much in
>>>>feature-freeze state and I want to put out an RC until the end of next
>>>>week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
>>>>already starting to collect ideas for 2.4-dev. However, moving to the
>>>>pipeline and towards Avalon will (for me) stay top priority.
>>>>
>>>> Regards
>>>> Henning
>>
>>
>>
>>---------------------------------------------------------------------
>>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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Bill <bh...@collaborativefusion.com>.
Jonathan
Based on this:
>>Jonathan, some technical information (which you as a non-Turbine guy
> >>might not have seen yet): Unfortunately the o.a.velocity.Context is
> >>buried pretty deep in the Turbine code (this is legacy of the original
> >>turbine developers). So we will have to replace this in every place
> >>with an Adapter class with plugs either onto the Velocity Context or a
> >>similar class in every other view solution (FreeMarker, WebMacro
> >>etc.).
> >>
> >>Doing so, it would be necessary for all of our users to change the
> >>imports in their self-written classes (Action, Screen), because the
> >>Context is part of the signature of the methods which are overloaded
> >>by user classes.
> >>
> >>If we don't do this but just 'bolt FM support on' by using different
> >>classes, there wouldn't be much won, because people would still use
> >>VelocityScreen, VelocityPage etc. just as in all the example code
> >>around and the FM code would start to rot (again). I don't want this,
> >>because it wouldn't buy much for the Turbine users.
> >>So we would need some major core changes to allow developers to simply
> >>switch views without having to rewrite all of their classes later.
In addition, I based my point on the fact that the current developers
obviously already made such a determination when they made the decision
to stop supporting it.
I maybe did not express my point clearly enough, if this is merely a
matter of adding Freemarker support for political reasons, its a waste
of time. Not just the developers, but all of ours. The simple fact is
I do not remember any amount of clamor over the decision to withdraw
support of FM and WM. When the decision was announced to the list, my
stance was that having support for these technologies was good for
Turbine but it didnt make sense if no one was using them. If there were
enough users to justify the work, then I dont think that support would
have been withdrawn.
If I understand the current path of Turbine, its continuing development
is targeted at eventually moving users to Avalon. I assume that as this
transition takes place, services will be built more view independent.
So I dont think it makes a lot of sense to devote resources to reversing
the previous decision in the current Turbine code.
I am not a Velocity proponent, the decision to use Velocity was made
before I came to this company. Velocity would not have been my choice.
All that being said, I have nothing against Freemarker, but I have no
intention of supporting a decision to re-support a technology that
doesnt seem to be used by the community, and will cause everyone in the
community to perform a migration.
Just my $.02
On Wed, 2003-06-18 at 10:47, Jonathan Revusky wrote:
> Bill wrote:
> > Henning
> >
> > I think working on Freemarker support would be a waste of the developers
> > valuable time.
>
> Bill,
>
> I'm curious. Have you made some kind of point estimate on how long it
> would take developers to put back in the FM support?
>
> Surely, it being a waste of time depends on how much time it actually
> is, doesn't it?
>
>
> > However, divorcing Turbine from Velocity to allow more
> > flexibility not only seems like a good idea, it seems absolutely
> > necessary if the I understand the path to Avalonization.
>
> What is Avalonization?
>
> Regards,
>
> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
> FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
> FreeMarker 2.3pre4 is out!
>
>
>
> >
> > -b
> >
> >
> >
> > On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
> >
> >>Jonathan Revusky <jo...@revusky.com> writes:
> >>
> >>
> >>>Henning P. Schmiedehausen wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
> >>
> >>>I believe the question should maybe be rephrased:
> >>
> >>>Is any one of you needing or missing decimal number support in Velocity?
> >>
> >>Ok,
> >>
> >>Folks, is anyone of you missing <insert your feature here that FM
> >>supports and Velocity does not> from the View portion of Turbine?
> >>
> >>You will find a feature complete list on http://www.freemarker.org for
> >>FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
> >>
> >>If yes, would you consider a switch from Velocity to FreeMarker as
> >>View for Turbine or would you get a pull tool to support this feature?
> >>
> >>The reason for this (and Jonathans' response): On the Velocity lists,
> >>there has been some rumbling about the current development state of
> >>Velocity and talking about alternatives to it. As we (Turbine) did
> >>remove the (quite aged and not actively maintained) FreeMarker support
> >>post Turbine-2.2, there have been some accusations of doing this
> >>because of "political reasons". As I was not really involved in the FM
> >>stuff or its removal, I'm trying to collect opinions from the Turbine
> >>users about getting FM support back into Turbine. However, if noone
> >>wants to use it, it wouldn't make much sense and the change itself is
> >>(IMHO) quite a major one to support FM really good.
> >>
> >>Jonathan, some technical information (which you as a non-Turbine guy
> >>might not have seen yet): Unfortunately the o.a.velocity.Context is
> >>buried pretty deep in the Turbine code (this is legacy of the original
> >>turbine developers). So we will have to replace this in every place
> >>with an Adapter class with plugs either onto the Velocity Context or a
> >>similar class in every other view solution (FreeMarker, WebMacro
> >>etc.).
> >>
> >>Doing so, it would be necessary for all of our users to change the
> >>imports in their self-written classes (Action, Screen), because the
> >>Context is part of the signature of the methods which are overloaded
> >>by user classes.
> >>
> >>If we don't do this but just 'bolt FM support on' by using different
> >>classes, there wouldn't be much won, because people would still use
> >>VelocityScreen, VelocityPage etc. just as in all the example code
> >>around and the FM code would start to rot (again). I don't want this,
> >>because it wouldn't buy much for the Turbine users.
> >>So we would need some major core changes to allow developers to simply
> >>switch views without having to rewrite all of their classes later.
> >>
> >>If we want to have engine-independent view support which is equal for
> >>all templating solutions (and not heavily Velocity based as the
> >>current view is, which is one of the reasons why noone really uses FM
> >>and/or WebMacro with Turbine and the code started to rot), we will
> >>have to make this (major) change. This is something that affects all
> >>of our users and we will listen to them.
> >>
> >>
> >>>Is anybody missing any of those features?
> >>
> >>Please send opinions to this list. Turbine 2.3 is pretty much in
> >>feature-freeze state and I want to put out an RC until the end of next
> >>week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
> >>already starting to collect ideas for 2.4-dev. However, moving to the
> >>pipeline and towards Avalon will (for me) stay top priority.
> >>
> >> Regards
> >> Henning
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
Bill <bh...@collaborativefusion.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Bill wrote:
> Henning
>
> I think working on Freemarker support would be a waste of the developers
> valuable time.
Bill,
I'm curious. Have you made some kind of point estimate on how long it
would take developers to put back in the FM support?
Surely, it being a waste of time depends on how much time it actually
is, doesn't it?
> However, divorcing Turbine from Velocity to allow more
> flexibility not only seems like a good idea, it seems absolutely
> necessary if the I understand the path to Avalonization.
What is Avalonization?
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
FreeMarker 2.3pre4 is out!
>
> -b
>
>
>
> On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
>
>>Jonathan Revusky <jo...@revusky.com> writes:
>>
>>
>>>Henning P. Schmiedehausen wrote:
>>>
>>>>Hi,
>>>>
>>>>is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>>
>>>I believe the question should maybe be rephrased:
>>
>>>Is any one of you needing or missing decimal number support in Velocity?
>>
>>Ok,
>>
>>Folks, is anyone of you missing <insert your feature here that FM
>>supports and Velocity does not> from the View portion of Turbine?
>>
>>You will find a feature complete list on http://www.freemarker.org for
>>FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
>>
>>If yes, would you consider a switch from Velocity to FreeMarker as
>>View for Turbine or would you get a pull tool to support this feature?
>>
>>The reason for this (and Jonathans' response): On the Velocity lists,
>>there has been some rumbling about the current development state of
>>Velocity and talking about alternatives to it. As we (Turbine) did
>>remove the (quite aged and not actively maintained) FreeMarker support
>>post Turbine-2.2, there have been some accusations of doing this
>>because of "political reasons". As I was not really involved in the FM
>>stuff or its removal, I'm trying to collect opinions from the Turbine
>>users about getting FM support back into Turbine. However, if noone
>>wants to use it, it wouldn't make much sense and the change itself is
>>(IMHO) quite a major one to support FM really good.
>>
>>Jonathan, some technical information (which you as a non-Turbine guy
>>might not have seen yet): Unfortunately the o.a.velocity.Context is
>>buried pretty deep in the Turbine code (this is legacy of the original
>>turbine developers). So we will have to replace this in every place
>>with an Adapter class with plugs either onto the Velocity Context or a
>>similar class in every other view solution (FreeMarker, WebMacro
>>etc.).
>>
>>Doing so, it would be necessary for all of our users to change the
>>imports in their self-written classes (Action, Screen), because the
>>Context is part of the signature of the methods which are overloaded
>>by user classes.
>>
>>If we don't do this but just 'bolt FM support on' by using different
>>classes, there wouldn't be much won, because people would still use
>>VelocityScreen, VelocityPage etc. just as in all the example code
>>around and the FM code would start to rot (again). I don't want this,
>>because it wouldn't buy much for the Turbine users.
>>So we would need some major core changes to allow developers to simply
>>switch views without having to rewrite all of their classes later.
>>
>>If we want to have engine-independent view support which is equal for
>>all templating solutions (and not heavily Velocity based as the
>>current view is, which is one of the reasons why noone really uses FM
>>and/or WebMacro with Turbine and the code started to rot), we will
>>have to make this (major) change. This is something that affects all
>>of our users and we will listen to them.
>>
>>
>>>Is anybody missing any of those features?
>>
>>Please send opinions to this list. Turbine 2.3 is pretty much in
>>feature-freeze state and I want to put out an RC until the end of next
>>week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
>>already starting to collect ideas for 2.4-dev. However, moving to the
>>pipeline and towards Avalon will (for me) stay top priority.
>>
>> Regards
>> Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Decimal Number support
Posted by Quinton McCombs <qm...@nequalsone.com>.
> -----Original Message-----
> From: Bill [mailto:bhalpin@collaborativefusion.com]
> Sent: Wednesday, June 18, 2003 8:15 AM
> To: Henning P. Schmiedehausen
> Cc: turbine-user
> Subject: Re: Decimal Number support
>
>
> Henning
>
> I think working on Freemarker support would be a waste of the
> developers valuable time.
It would not be a waste of time is people are interested in using it.
> However, divorcing Turbine from
> Velocity to allow more flexibility not only seems like a good
> idea, it seems absolutely necessary if the I understand the
> path to Avalonization.
I agree with you that the flexibility would be a very good thing.
Our view architecture is really not very plugable. The problem is that
once you start writing your actions and screen classes which accept
RunData and Context as parameters, you are become tied to the view
implementation. This was very much a shortcoming of the core design of
Turbine.
Hennings idea to create a proxy class to represent the context type
object of the underlying view is indeed a good way to solve this
problem. It would require deprecating the methods that everyone
normally overrides in the screen and action classes. The replacement
would be virtually the same interface replacing Context with the new
class.
Even if we do not decide to support FreeMarker, I think that it would be
in our best interests to implement the proxy class for the context.
Right now, if your view is JSP and you want to switch to Velocity or
visa-versa, you must modify all of your action and screen classes. Not
fun.
> -b
>
>
>
> On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
> > Jonathan Revusky <jo...@revusky.com> writes:
> >
> > >Henning P. Schmiedehausen wrote:
> > >> Hi,
> > >>
> > >> is anyone of you needing or missing FreeMarker Support
> in Turbine
> > >> 2.2?
> >
> > >I believe the question should maybe be rephrased:
> >
> > >Is any one of you needing or missing decimal number support in
> > >Velocity?
> >
> > Ok,
> >
> > Folks, is anyone of you missing <insert your feature here that FM
> > supports and Velocity does not> from the View portion of Turbine?
> >
> > You will find a feature complete list on
> http://www.freemarker.org for
> > FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
> >
> > If yes, would you consider a switch from Velocity to FreeMarker as
> > View for Turbine or would you get a pull tool to support
> this feature?
> >
> > The reason for this (and Jonathans' response): On the
> Velocity lists,
> > there has been some rumbling about the current development state of
> > Velocity and talking about alternatives to it. As we (Turbine) did
> > remove the (quite aged and not actively maintained)
> FreeMarker support
> > post Turbine-2.2, there have been some accusations of doing this
> > because of "political reasons". As I was not really
> involved in the FM
> > stuff or its removal, I'm trying to collect opinions from
> the Turbine
> > users about getting FM support back into Turbine. However, if noone
> > wants to use it, it wouldn't make much sense and the change
> itself is
> > (IMHO) quite a major one to support FM really good.
> >
> > Jonathan, some technical information (which you as a
> non-Turbine guy
> > might not have seen yet): Unfortunately the o.a.velocity.Context is
> > buried pretty deep in the Turbine code (this is legacy of
> the original
> > turbine developers). So we will have to replace this in every place
> > with an Adapter class with plugs either onto the Velocity
> Context or a
> > similar class in every other view solution (FreeMarker, WebMacro
> > etc.).
> >
> > Doing so, it would be necessary for all of our users to change the
> > imports in their self-written classes (Action, Screen), because the
> > Context is part of the signature of the methods which are
> overloaded
> > by user classes.
> >
> > If we don't do this but just 'bolt FM support on' by using
> different
> > classes, there wouldn't be much won, because people would still use
> > VelocityScreen, VelocityPage etc. just as in all the example code
> > around and the FM code would start to rot (again). I don't
> want this,
> > because it wouldn't buy much for the Turbine users. So we
> would need
> > some major core changes to allow developers to simply switch views
> > without having to rewrite all of their classes later.
> >
> > If we want to have engine-independent view support which is
> equal for
> > all templating solutions (and not heavily Velocity based as the
> > current view is, which is one of the reasons why noone
> really uses FM
> > and/or WebMacro with Turbine and the code started to rot), we will
> > have to make this (major) change. This is something that
> affects all
> > of our users and we will listen to them.
> >
> > >Is anybody missing any of those features?
> >
> > Please send opinions to this list. Turbine 2.3 is pretty much in
> > feature-freeze state and I want to put out an RC until the
> end of next
> > week (Colin, don't worry, your Intake changes will be in
> :-) ) and I'm
> > already starting to collect ideas for 2.4-dev. However,
> moving to the
> > pipeline and towards Avalon will (for me) stay top priority.
> >
> > Regards
> > Henning
> --
> Bill <bh...@collaborativefusion.com>
>
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Bill <bh...@collaborativefusion.com>.
Henning
I think working on Freemarker support would be a waste of the developers
valuable time. However, divorcing Turbine from Velocity to allow more
flexibility not only seems like a good idea, it seems absolutely
necessary if the I understand the path to Avalonization.
-b
On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
> Jonathan Revusky <jo...@revusky.com> writes:
>
> >Henning P. Schmiedehausen wrote:
> >> Hi,
> >>
> >> is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>
> >I believe the question should maybe be rephrased:
>
> >Is any one of you needing or missing decimal number support in Velocity?
>
> Ok,
>
> Folks, is anyone of you missing <insert your feature here that FM
> supports and Velocity does not> from the View portion of Turbine?
>
> You will find a feature complete list on http://www.freemarker.org for
> FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
>
> If yes, would you consider a switch from Velocity to FreeMarker as
> View for Turbine or would you get a pull tool to support this feature?
>
> The reason for this (and Jonathans' response): On the Velocity lists,
> there has been some rumbling about the current development state of
> Velocity and talking about alternatives to it. As we (Turbine) did
> remove the (quite aged and not actively maintained) FreeMarker support
> post Turbine-2.2, there have been some accusations of doing this
> because of "political reasons". As I was not really involved in the FM
> stuff or its removal, I'm trying to collect opinions from the Turbine
> users about getting FM support back into Turbine. However, if noone
> wants to use it, it wouldn't make much sense and the change itself is
> (IMHO) quite a major one to support FM really good.
>
> Jonathan, some technical information (which you as a non-Turbine guy
> might not have seen yet): Unfortunately the o.a.velocity.Context is
> buried pretty deep in the Turbine code (this is legacy of the original
> turbine developers). So we will have to replace this in every place
> with an Adapter class with plugs either onto the Velocity Context or a
> similar class in every other view solution (FreeMarker, WebMacro
> etc.).
>
> Doing so, it would be necessary for all of our users to change the
> imports in their self-written classes (Action, Screen), because the
> Context is part of the signature of the methods which are overloaded
> by user classes.
>
> If we don't do this but just 'bolt FM support on' by using different
> classes, there wouldn't be much won, because people would still use
> VelocityScreen, VelocityPage etc. just as in all the example code
> around and the FM code would start to rot (again). I don't want this,
> because it wouldn't buy much for the Turbine users.
> So we would need some major core changes to allow developers to simply
> switch views without having to rewrite all of their classes later.
>
> If we want to have engine-independent view support which is equal for
> all templating solutions (and not heavily Velocity based as the
> current view is, which is one of the reasons why noone really uses FM
> and/or WebMacro with Turbine and the code started to rot), we will
> have to make this (major) change. This is something that affects all
> of our users and we will listen to them.
>
> >Is anybody missing any of those features?
>
> Please send opinions to this list. Turbine 2.3 is pretty much in
> feature-freeze state and I want to put out an RC until the end of next
> week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
> already starting to collect ideas for 2.4-dev. However, moving to the
> pipeline and towards Avalon will (for me) stay top priority.
>
> Regards
> Henning
--
Bill <bh...@collaborativefusion.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Matt Koranda <ma...@orkan.no>.
I only use velocity and use pull tools for anything else.....
Matt
----- Original Message -----
From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
Newsgroups: hometree.jakarta.turbine.users
To: <tu...@jakarta.apache.org>
Sent: Wednesday, June 18, 2003 12:41 PM
Subject: Re: Decimal Number support
> Jonathan Revusky <jo...@revusky.com> writes:
>
> >Henning P. Schmiedehausen wrote:
> >> Hi,
> >>
> >> is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>
> >I believe the question should maybe be rephrased:
>
> >Is any one of you needing or missing decimal number support in Velocity?
>
> Ok,
>
> Folks, is anyone of you missing <insert your feature here that FM
> supports and Velocity does not> from the View portion of Turbine?
>
> You will find a feature complete list on http://www.freemarker.org for
> FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
>
> If yes, would you consider a switch from Velocity to FreeMarker as
> View for Turbine or would you get a pull tool to support this feature?
>
> The reason for this (and Jonathans' response): On the Velocity lists,
> there has been some rumbling about the current development state of
> Velocity and talking about alternatives to it. As we (Turbine) did
> remove the (quite aged and not actively maintained) FreeMarker support
> post Turbine-2.2, there have been some accusations of doing this
> because of "political reasons". As I was not really involved in the FM
> stuff or its removal, I'm trying to collect opinions from the Turbine
> users about getting FM support back into Turbine. However, if noone
> wants to use it, it wouldn't make much sense and the change itself is
> (IMHO) quite a major one to support FM really good.
>
> Jonathan, some technical information (which you as a non-Turbine guy
> might not have seen yet): Unfortunately the o.a.velocity.Context is
> buried pretty deep in the Turbine code (this is legacy of the original
> turbine developers). So we will have to replace this in every place
> with an Adapter class with plugs either onto the Velocity Context or a
> similar class in every other view solution (FreeMarker, WebMacro
> etc.).
>
> Doing so, it would be necessary for all of our users to change the
> imports in their self-written classes (Action, Screen), because the
> Context is part of the signature of the methods which are overloaded
> by user classes.
>
> If we don't do this but just 'bolt FM support on' by using different
> classes, there wouldn't be much won, because people would still use
> VelocityScreen, VelocityPage etc. just as in all the example code
> around and the FM code would start to rot (again). I don't want this,
> because it wouldn't buy much for the Turbine users.
> So we would need some major core changes to allow developers to simply
> switch views without having to rewrite all of their classes later.
>
> If we want to have engine-independent view support which is equal for
> all templating solutions (and not heavily Velocity based as the
> current view is, which is one of the reasons why noone really uses FM
> and/or WebMacro with Turbine and the code started to rot), we will
> have to make this (major) change. This is something that affects all
> of our users and we will listen to them.
>
> >Is anybody missing any of those features?
>
> Please send opinions to this list. Turbine 2.3 is pretty much in
> feature-freeze state and I want to put out an RC until the end of next
> week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
> already starting to collect ideas for 2.4-dev. However, moving to the
> pipeline and towards Avalon will (for me) stay top priority.
>
> 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
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jonathan Revusky <jo...@revusky.com> writes:
>Henning P. Schmiedehausen wrote:
>> Hi,
>>
>> is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>I believe the question should maybe be rephrased:
>Is any one of you needing or missing decimal number support in Velocity?
Ok,
Folks, is anyone of you missing <insert your feature here that FM
supports and Velocity does not> from the View portion of Turbine?
You will find a feature complete list on http://www.freemarker.org for
FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
If yes, would you consider a switch from Velocity to FreeMarker as
View for Turbine or would you get a pull tool to support this feature?
The reason for this (and Jonathans' response): On the Velocity lists,
there has been some rumbling about the current development state of
Velocity and talking about alternatives to it. As we (Turbine) did
remove the (quite aged and not actively maintained) FreeMarker support
post Turbine-2.2, there have been some accusations of doing this
because of "political reasons". As I was not really involved in the FM
stuff or its removal, I'm trying to collect opinions from the Turbine
users about getting FM support back into Turbine. However, if noone
wants to use it, it wouldn't make much sense and the change itself is
(IMHO) quite a major one to support FM really good.
Jonathan, some technical information (which you as a non-Turbine guy
might not have seen yet): Unfortunately the o.a.velocity.Context is
buried pretty deep in the Turbine code (this is legacy of the original
turbine developers). So we will have to replace this in every place
with an Adapter class with plugs either onto the Velocity Context or a
similar class in every other view solution (FreeMarker, WebMacro
etc.).
Doing so, it would be necessary for all of our users to change the
imports in their self-written classes (Action, Screen), because the
Context is part of the signature of the methods which are overloaded
by user classes.
If we don't do this but just 'bolt FM support on' by using different
classes, there wouldn't be much won, because people would still use
VelocityScreen, VelocityPage etc. just as in all the example code
around and the FM code would start to rot (again). I don't want this,
because it wouldn't buy much for the Turbine users.
So we would need some major core changes to allow developers to simply
switch views without having to rewrite all of their classes later.
If we want to have engine-independent view support which is equal for
all templating solutions (and not heavily Velocity based as the
current view is, which is one of the reasons why noone really uses FM
and/or WebMacro with Turbine and the code started to rot), we will
have to make this (major) change. This is something that affects all
of our users and we will listen to them.
>Is anybody missing any of those features?
Please send opinions to this list. Turbine 2.3 is pretty much in
feature-freeze state and I want to put out an RC until the end of next
week (Colin, don't worry, your Intake changes will be in :-) ) and I'm
already starting to collect ideas for 2.4-dev. However, moving to the
pipeline and towards Avalon will (for me) stay top priority.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Decimal Number support
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> Hi,
>
> is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
I believe the question should maybe be rephrased:
Is any one of you needing or missing decimal number support in Velocity?
In my sig, there is a link to a page that describes the features that
are available in FreeMarker that are not present in Velocity. This
includes decimal numbers, but many other things as well.
Is anybody missing any of those features?
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
AW: FreeMarker Support
Posted by Miessbrandt Gunter <gu...@gogol-medien.de>.
Not really!
Gunter M.
--------------------------------------------
Gunter Miessbrandt - gogol medien GmbH & Co. KG
e-mail: gunter.miessbrandt@gogol-medien.de
> -----Ursprüngliche Nachricht-----
> Von: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Gesendet: Dienstag, 17. Juni 2003 17:30
> An: turbine-user@jakarta.apache.org
> Betreff: FreeMarker Support
>
> Hi,
>
> is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
>
> 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
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org