You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Andrew (Tver)" <a...@etver.com> on 2000/08/31 10:13:15 UTC
Re[6]: parser technology
Hello Jon,
Thursday, August 31, 2000, 11:34:06 AM, you wrote:
JS> on 8/31/2000 12:30 AM, "Andrew (Tver)" <a...@etver.com> wrote:
>> The metamata site is still unavailable for me (I try agian and again -
>> zero) - I have no ideas why.
>> So my mail-box is open for you regardless the attachments size :-)
>> I'l be waiting. Thanks!
JS> try:
JS> http://199.182.58.58/javacc/
JS> if you still can't get to it, then you should switch ISP's. :-)
JS> -jon
Jon, it is not funny for me, you can see:
tracert 199.182.58.58 --->
...
...
12 431 ms 421 ms 440 ms Hssi1-0.BR1.PSK1.ALTER.NET [137.39.100.29]
13 441 ms 440 ms 431 ms sprint-nap.netcom.net [192.157.69.38]
14 440 ms 431 ms 451 ms h4-0.nwk-nj-gw1.icg.net [163.179.232.218]
15 501 ms 591 ms 491 ms a11-0-0-4.chw-il-gw1.icg.net [163.179.235.77]
16 471 ms 491 ms 481 ms a0-0-0-3.dnv-co-gw1.icg.net [163.179.235.18]
17 511 ms 531 ms 511 ms a2-0-0-1.sji-ca-gw1.icg.net [163.179.235.45]
18 511 ms 2303 ms 581 ms h2-0.hay-ca-gw1.icg.net [165.236.177.94]
19 * * * Request timed out.
20 gw.internet-is.com [199.182.58.1] reports: Destination net unreachable.
Trace complete.
Usually I have no any problems with my ISP :-)
--
Best regards,
Andrew mailto:a@etver.com
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
I can't officially confirm that this evaluation is underway, but you can
say that I am working at a large dot.com in Palo Alto that serves 100 million
pages a day and that you saw me post a very interesting template to the list :-)
Justin
On Fri, Sep 01, 2000 at 11:44:46AM +0200, Leon Messerschmidt wrote:
> Hi Justin,
>
>
> > ps: I don't mind posting the page to the list, the secret is
> > basically out already, but you probably ought not to include
> > this exact HTML in your distribution testbed.
>
>
> At the moment we're using Turbine with WM with great success. We'd like to
> do some marketing locally (South Africa) - can I mention that this
> evaluation is taking place or is the information sensitive?
>
> ~ Leon
>
Re: benchmarking velocity
Posted by Leon Messerschmidt <le...@opticode.co.za>.
Hi Justin,
> ps: I don't mind posting the page to the list, the secret is
> basically out already, but you probably ought not to include
> this exact HTML in your distribution testbed.
At the moment we're using Turbine with WM with great success. We'd like to
do some marketing locally (South Africa) - can I mention that this
evaluation is taking place or is the information sensitive?
~ Leon
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
I tried that, switching to {}'s didn't work. At the top of the page there
is a bunch of CSS junk containing a lot of {}'s so the problem is likely
something in there, but who knows.
Justin
On Fri, Sep 01, 2000 at 12:17:59AM -0700, Jon Stevens wrote:
> on 9/1/2000 12:22 AM, "Justin Wells" <jr...@semiotek.com> wrote:
>
> > I was only able to get it to work with the #foreach loops removed.
>
> I don't think that velocity supports the #begin/#end syntax that is used in
> your #foreach statement in the file. It just isn't needed with Velocity
> since {} works.
>
> -jon
>
> --
> http://scarab.tigris.org/ | http://noodle.tigris.org/
> http://java.apache.org/ | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/ | http://www.sourcexchange.com/
>
>
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 1:01 PM, "Justin Wells" <jr...@semiotek.com> wrote:
> A regx class would do it. You won't get many complaints about this stuff
> while Velocity is still alpha. If we try to switch 2000 WM users over without
> some kind of automatic process trust me, they'll whine :-)
>
> Justin
Of course. This is also part of the reason why I was responsible for adding
not only one, but TWO regex packages to Jakarta. :-) I do have a master
plan, I'm just not telling anyone what it is...including myself. :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
On Fri, Sep 01, 2000 at 11:56:38AM -0700, Jon Stevens wrote:
> Right, but WHY was it made the preferred syntax? As far as I can tell
> (please correct me if I'm wrong), it was only because the parser couldn't
> handle Javascript. Since Velocity handles Javascript without problems, this
> isn't an issue.
CSS stylesheets also use {, and many people at the time argued that the
#begin and #end sytnax was visually clearer for non-programmers. I
still use both.
> It details the differences and changes. I didn't get one single complaint.
A regx class would do it. You won't get many complaints about this stuff
while Velocity is still alpha. If we try to switch 2000 WM users over without
some kind of automatic process trust me, they'll whine :-)
Justin
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 2:25 PM, "Marc Palmer" <ma...@anyware.co.uk> wrote:
> That may be the case. It does not undermine the value of the alternative
> syntax. We are allowed to discover cool things by accident.
Of course.
> You said it should go to a vote. However from the words above it sounds
> like you've already decided the outcome.
No. I'm just expressing my opinion! Geez, am I not allowed to do that
anymore?
> Scanning through the mails I have received so far on this list about
> this, we have three +1s and two -1s, so it's a balance of +1 at the
> moment.
three +1's and two -1's for what?
3 +1 for having #begin/#end or the other way around? Also, the voting can
only come active developers. So far, the only active developers that I have
seen post on this topic is myself.
A single -1 with a good reason is enough to prevent it from happening. So
far, I think I have given pretty good reasons.
> I don't know anything about JavaCC and AST but perhaps your resistance to
> this is because there would be problems adding support for both { } and
> #begin #end using this parser technology? If this is the case please say
> so. If it is not the case, and it is easy to implement, why bother with
> all this arguing it's wasting all our time. Democracy is on the side of
> #begin at the moment.
We don't know one way or another yet since we haven't tried. :-)
> Too much flexibility? I wouldn't go that far.
>
> I do think that LEGACY=true is pretty ugly and does not clearly define
> what "legacy" is. If it MUST be optional due to some performance cost or
> something, let us know. Why the resistance apart from your personal
> dislike for it? (Which only figures for a 1 in the scoring system eh!)
I have already given my ideas for why I am resisting it that are beyond my
personal dislike for it.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Fri, 1 Sep 2000, Marc Palmer wrote:
> I don't know anything about JavaCC and AST but perhaps your resistance to
> this is because there would be problems adding support for both { } and
> #begin #end using this parser technology? If this is the case please say
> so. If it is not the case, and it is easy to implement, why bother with
> all this arguing � it's wasting all our time. Democracy is on the side of
> #begin at the moment.
It is not a problem to add anything, the grammar is very
flexible. And It can certainly be implemented if that
is the general desire, but from a language standpoint
it's inconsistent. Most other languages don't have
multiple constructs for block structures.
The overhead in looking for either {} or #begin/#end
is neglible, and can be allowable syntax. I think
Justin would agree the use of #begin/#end arose
from the need to solve a parsing problem. I don't
think he would have included it otherwise.
It can by all means be supported. The test template
I received from Justin #begin/#end in there so I am
using that as a reference for parsing. I am re-writing
the JavaCC grammar for the parser now and I am
going to include #begin/#end. I am also starting
a SableCC grammar. Terrence Parr, the creator of
Antlr, is also working on a grammar.
The Velocity parser is pluggable, and will work
with any parser that delivers an AST of some sort.
An interface and some adapter classes will allow
a choice of parsers. I've almost complete the
JavaCC one, Terrence Parr will probably finish
before his before I do. And I'm talking to someone about
helping me, or doing the SableCC grammar.
So we will more then likely have three very good
back end parsers. A JavaCC one, an Antlr one, and
a SableCC one. I would like to compare them all.
I am working on gathering the desing I have
for Velocity into a presentable form now.
I don't know how long it will take me to
finish, I am hoping in the next few days, but
I will have all the interfaces described,
class diagrams, possibly some collabortion
diagrams and a rather lengthly document
describing the whole process.
The design is what should be evaluated, what
is in CVS represents almost nothing of the
whole plan. I have spent most of my time on
the parser, the rest of the code really isn't
worth looking and is not representative of what
Velocity is or will be. When I'm finished everything
I will commit everything to CVS. All my UML diagrams were
created with Argo UML, but I believe the
XMI format is portable to other modelling
tools.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: benchmarking velocity
Posted by Marc Palmer <ma...@anyware.co.uk>.
------ Original Message ------
On 01/09/00, 19:56:38, Jon Stevens <jo...@latchkey.com> wrote regarding Re:
benchmarking velocity:
> on 9/1/2000 11:45 AM, "Justin Wells" <jr...@semiotek.com> wrote:
> > Since the #begin and #end sytnax has been represented as the preferred
syntax
> > for WebMacro it probably should be supported. Note that in the
> > current WM the {'s are considered legacy and can be turned off in
> > the config file.
> Right, but WHY was it made the preferred syntax? As far as I can tell
> (please correct me if I'm wrong), it was only because the parser couldn't
> handle Javascript. Since Velocity handles Javascript without problems,
this
> isn't an issue.
That may be the case. It does not undermine the value of the alternative
syntax. We are allowed to discover cool things by accident.
> > Velocity could reverse that decision
> We already have, right? :-)
> >, but should probably support users who
> > rewrote their templates in the recommended way.
> The support will be through a regex class or a set of documentation that
> describes what needs to change between products. For example, I wrote
this
> document for JServ...
You said it should go to a vote. However from the words above it sounds
like you've already decided the outcome.
Scanning through the mails I have received so far on this list about
this, we have three +1s and two -1s, so it's a balance of +1 at the
moment.
I don't know anything about JavaCC and AST but perhaps your resistance to
this is because there would be problems adding support for both { } and
#begin #end using this parser technology? If this is the case please say
so. If it is not the case, and it is easy to implement, why bother with
all this arguing it's wasting all our time. Democracy is on the side of
#begin at the moment.
> <http://java.apache.org/jserv/upgrade.html>
> It details the differences and changes. I didn't get one single
complaint.
I'm sure you didn't.
> > One useful approach would be to have a "LEGACY=true" setting in the
config
> > file that turns on some behavior that a lot of people use but which you
> > intend to drop. That behavior could then disapper completely in a 3.0
> > release.
> I would be against that as it is to much flexibility.
Too much flexibility? I wouldn't go that far.
I do think that LEGACY=true is pretty ugly and does not clearly define
what "legacy" is. If it MUST be optional due to some performance cost or
something, let us know. Why the resistance apart from your personal
dislike for it? (Which only figures for a 1 in the scoring system eh!)
> A joke: Should we also include a JSP=true parser as well to support all
> those legacy JSP pages? :-)
Haha ;-)
Please take this post in good humour Jon. Have a good weekend!
Cheers
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/2/2000 12:37 AM, "Leon Messerschmidt" <le...@opticode.co.za> wrote:
> Just a question - I don't intend to step on anybody's toes.
>
> Can this be handled in Vel?
>
> #if ($foo)
> {
> Alert ("any number of { or }}}}}} - just a silly example")
> }
>
> We use javascript fairly often in Turbine (combined with WM). I just don't
> want
> any nasty surprises if we switched to Vel.
>
> ~ Leon
Now, that is a great example of it not working. :-)
I think that Jason has it on his list to fix.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Leon Messerschmidt <le...@opticode.co.za>.
Hi,
> if ($foo) {
> }
> }
>
> Is it just \} escaped? If so that makes including JavaScript very ugly.
Just a question - I don't intend to step on anybody's toes.
Can this be handled in Vel?
#if ($foo)
{
Alert ("any number of { or }}}}}} - just a silly example")
}
We use javascript fairly often in Turbine (combined with WM). I just don't want
any nasty surprises if we switched to Vel.
~ Leon
Re: benchmarking velocity
Posted by Travis Low <tr...@dawnstar.org>.
Thanks, David. That makes sense. Now I have the warm feeling I needed to move
into a new direction.
Travis
David Warnock wrote:
>
> > I find it REALLY hard to believe that a graphic designer would want to see all
> > that WebMacro stuff. I quote: "Things that you don't care about should get out
> > of your face." I believe your view is too engineering-centric. I have the
> > impression that engineers make these templates, then dump them on designers, who
> > are stuck with maintaining them. Is that not usually the case?
>
> Travis,
>
> My belief is that using html syntax for a template language is a
> mistake. There are hundreds of html editors out there that will not know
> what to do with the extra tags. No browser will know what to do with
> them so they most probably will not get displayed. Then the designer
> will
>
> a) be unable to add new velocity tags (because they are invisible)
> b) be unable to see the ones that are already there and so will probably
> insert their markup in the wrong place, or will accidently delete the
> tags.
>
> To me the best answer is a combination of 3 things
>
> 1. Use a template tagigng system that will not be interpreted as markup
> by the html editor (and browser) so the tags can always be seen.
>
> 2. Provide the designer with a simple tool that will take the template
> and test data in a text file, process them and return the resulting
> expanded version for them to look at in either their design tool and/or
> their browser.
>
> Finally remember that although WebMacro and Velocity both emphasise html
> templates they can be used for other file types as well (eg we have used
> them on rtf). In particular JTemplater has very strong independance from
> both html and servlets making it a very general purpose templating tool.
>
> Regards
>
> Dave
Re: benchmarking velocity
Posted by David Warnock <da...@sundayta.co.uk>.
> I find it REALLY hard to believe that a graphic designer would want to see all
> that WebMacro stuff. I quote: "Things that you don't care about should get out
> of your face." I believe your view is too engineering-centric. I have the
> impression that engineers make these templates, then dump them on designers, who
> are stuck with maintaining them. Is that not usually the case?
Travis,
My belief is that using html syntax for a template language is a
mistake. There are hundreds of html editors out there that will not know
what to do with the extra tags. No browser will know what to do with
them so they most probably will not get displayed. Then the designer
will
a) be unable to add new velocity tags (because they are invisible)
b) be unable to see the ones that are already there and so will probably
insert their markup in the wrong place, or will accidently delete the
tags.
To me the best answer is a combination of 3 things
1. Use a template tagigng system that will not be interpreted as markup
by the html editor (and browser) so the tags can always be seen.
2. Provide the designer with a simple tool that will take the template
and test data in a text file, process them and return the resulting
expanded version for them to look at in either their design tool and/or
their browser.
Finally remember that although WebMacro and Velocity both emphasise html
templates they can be used for other file types as well (eg we have used
them on rtf). In particular JTemplater has very strong independance from
both html and servlets making it a very general purpose templating tool.
Regards
Dave
Re: benchmarking velocity
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
>
> I really really really don't like the fake HTML syntax. Also, you can't
> review a template in the browser because you loose all the logic.
Depends on what you're reviewing...
> Take a WM template and open it with your web browser. See all that nice WM
> code all over the place? See how easy it is to see what is happening?
...and if you're an engineer that would be very handy. If you're a designer,
then perhaps you'd rather see what the page is going to LOOK LIKE, not THE LOGIC
OF HOW IT GETS THERE. With FreeMarker-style syntax, I can just browse the
template file and see what it's going to look like.
> This is something that the starwars.com guys (and myself!) really like and I'm
> not going to give up on this issue. :-)
Okay. :-) But are those starwars.com guys engineers or designers?
> Another problem with fake HTML syntax is if you try to load it in
> Dreamweaver, you are going to get a page that has all sorts of errors on it.
> That certainly isn't friendly to web designers who don't even know HTML.
A substantive criticism, thanks! But is Dreamweaver configurable? Can you tell
it to ignore those tags?
I find it REALLY hard to believe that a graphic designer would want to see all
that WebMacro stuff. I quote: "Things that you don't care about should get out
of your face." I believe your view is too engineering-centric. I have the
impression that engineers make these templates, then dump them on designers, who
are stuck with maintaining them. Is that not usually the case?
As always, correct me if I'm wrong. Don't be shy! :-)
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: benchmarking velocity
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
> That is why people at least tried to be SGML/HTML compliant by adding the <%
> %> to the syntax.
Then perhaps a modified <%FM%> syntax might be better than the existing WM
syntax.
Okay, I'll shut up now.
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/3/2000 12:08 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> I really really really don't like the fake HTML syntax.
Another problem with fake HTML syntax is if you try to load it in
Dreamweaver, you are going to get a page that has all sorts of errors on it.
That certainly isn't friendly to web designers who don't even know HTML.
That is why people at least tried to be SGML/HTML compliant by adding the <%
%> to the syntax.
FYI, Justin Wells has a big XML/SGML background. I'm going to follow his
lead there.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/3/2000 7:29 AM, "Travis Low" <tr...@dawnstar.org> wrote:
> This "problem" exists because programmers created it. FreeMarker-style
> syntax:
>
> <if foo>
>
> </if>
>
> o Doesn't help people who want #begin/#end, sorry.
> o Curly braces were never a problem and will never be a problem.
> o Language is nice and clean resembles something designers already use.
> o Designers can review their templates in a browser.
>
> This is a recording.
Huh? I'm confused.
I really really really don't like the fake HTML syntax. Also, you can't
review a template in the browser because you loose all the logic.
Take a WM template and open it with your web browser. See all that nice WM
code all over the place? See how easy it is to see what is happening? This
is something that the starwars.com guys (and myself!) really like and I'm
not going to give up on this issue. :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
> We have been discussing in #velocity about removing them all together.
>
> #if ($foo)
>
> #end
>
> I'm 100% +1 on such a proposal. It solves the following problems:
>
> o people who want #begin/#end get half of what they want (ie: #end). :-)
> o curly braces aren't a problem anymore.
> o the language is nice and clean and easy for designers.
This "problem" exists because programmers created it. FreeMarker-style syntax:
<if foo>
</if>
o Doesn't help people who want #begin/#end, sorry.
o Curly braces were never a problem and will never be a problem.
o Language is nice and clean resembles something designers already use.
o Designers can review their templates in a browser.
This is a recording.
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/2/2000 8:06 PM, "Jason Hunter" <jh...@collab.net> wrote:
> But I remain curious how
> unmatched curly braces are handled.
>
> -jh-
We have been discussing in #velocity about removing them all together.
#if ($foo)
#end
I'm 100% +1 on such a proposal. It solves the following problems:
o people who want #begin/#end get half of what they want (ie: #end). :-)
o curly braces aren't a problem anymore.
o the language is nice and clean and easy for designers.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by David Warnock <da...@sundayta.co.uk>.
> So we have
>
> elseif () ... #else ... #end
Sorry, this should have been
#if()...#elseif()...#else...#end
Dave
Re: benchmarking velocity
Posted by David Warnock <da...@sundayta.co.uk>.
> #if () ... ##if ($noCurlies)
>
> Oh where are my curlies?
>
> #else
>
> This will never be reached with this grammar.
>
> #end
This is the approach that we have followed with JTemplater (another
WebMacro replacement). It works very well for all parties.
So we have
elseif () ... #else ... #end
The only commands that vary are #rem .. #endrem and #noparse ...
#endnoparse so that both of these can enclose arbitary numbers of #end
This style of language is widely praised in Steve McConnal's Code
Complete as a first class block structure which avoids all those code
indentation arguments (where does the { go?).
However, if you only support this then compatibility with WebMacro is
severely reduced. I suspect that you need to support all 3 options (ie
{...}, #begin..#end and no block markers) otherwise you will break every
template and that makes it a major hassle upgrade.
ly demarcated and lexically.
>
> This is obviously not compatible with WM. But
> a stronger lexing version could be made of
> the parsing that would render the same intermediary
> product could be made to allow multiple syntaxes.
> So you could parse Tea templates or other types
> of template that use the reflection API.
>
> Terrence had many useful suggestion, and has
> a lifetime of experience dealing with these
> things. He has sent me a document that I will
> post to the mailing list shortly.
>
> Hope that answers your question :)
>
> jvz.
>
> --
>
> Jason van Zyl
> jvanzyl@periapt.com
Re: benchmarking velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Sun, 3 Sep 2000, Jason Hunter wrote:
> > on 9/1/2000 7:45 PM, "Jason Hunter" <jh...@collab.net> wrote:
> >
> > > What was the answer to my (previously private) question about how
> > > Velocity can have an if block that includes only a "}" if the expression
> > > evals to true?
> > >
> > > if ($foo) {
> > > }
> > > }
> >
> > Jason, I answered you. It breaks.
> >
> > This is on jvz's todo list to fix.
> >
> > alpha code. alpha code. alpha code.
>
> I didn't ask *if* it would work in today's code, Jon! We already
> confirmed privately it didn't. I asked *how* Velocity can have such an
> if block. It was a question of design. Saying "alpha code" three times
> at me doesn't tell me the answer.
>
> > > Is it just \} escaped? If so that makes including JavaScript very ugly.
> >
> > Can you give me an example of how it would make including JavaScript very
> > ugly?
>
> If you included 10 lines of JavaScript and all the curly braces in the
> JS needed to be escaped, then that would be ugly. I see jvz said that
> matched curly braces in the JS wouldn't cause confusion, so that answers
> part of my question and with a good answer. But I remain curious how
> unmatched curly braces are handled.
A normal rule which I have in the grammar cannot handle the unmatched
brace by itself with some intervention: some strong lexing. You would
have to intervene and catch a parsing exception when it craps out on
an unmatched curly and backtrack to find out where it came. Find it
and change the token type to text instead of curly token.
But in my most recent discussions wit Terrence Parr (Antlr creator)
we tossed the idea out of removing curlies from the syntax all
together! It makes the parsing much easier, faster it there is
no chance that it would interfere with source i.e.
#if ($noCurlies)
Oh where are my curlies?
#else
This will never be reached with this grammar.
#end
The curlies actually serve no purpose other then eye-candy.
This may be purpose enough, but this was just one idea
thrown around among many. You'll also notice the #end.
Terrence suggested clearly demarcating the directives
visually as well as lexically. The curlies provide
a visual demarcation but are hard to lex given that
unmatched curlies are allowed in templates (the rule
that I used in lexing the templates would work
for C/C++ ... because unmatched braces are not allowed).
But having the #end indicating the end of a directive
is both visually demarcated and lexically.
This is obviously not compatible with WM. But
a stronger lexing version could be made of
the parsing that would render the same intermediary
product could be made to allow multiple syntaxes.
So you could parse Tea templates or other types
of template that use the reflection API.
Terrence had many useful suggestion, and has
a lifetime of experience dealing with these
things. He has sent me a document that I will
post to the mailing list shortly.
Hope that answers your question :)
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: benchmarking velocity
Posted by Jason Hunter <jh...@collab.net>.
> on 9/1/2000 7:45 PM, "Jason Hunter" <jh...@collab.net> wrote:
>
> > What was the answer to my (previously private) question about how
> > Velocity can have an if block that includes only a "}" if the expression
> > evals to true?
> >
> > if ($foo) {
> > }
> > }
>
> Jason, I answered you. It breaks.
>
> This is on jvz's todo list to fix.
>
> alpha code. alpha code. alpha code.
I didn't ask *if* it would work in today's code, Jon! We already
confirmed privately it didn't. I asked *how* Velocity can have such an
if block. It was a question of design. Saying "alpha code" three times
at me doesn't tell me the answer.
> > Is it just \} escaped? If so that makes including JavaScript very ugly.
>
> Can you give me an example of how it would make including JavaScript very
> ugly?
If you included 10 lines of JavaScript and all the curly braces in the
JS needed to be escaped, then that would be ugly. I see jvz said that
matched curly braces in the JS wouldn't cause confusion, so that answers
part of my question and with a good answer. But I remain curious how
unmatched curly braces are handled.
-jh-
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 7:45 PM, "Jason Hunter" <jh...@collab.net> wrote:
> What was the answer to my (previously private) question about how
> Velocity can have an if block that includes only a "}" if the expression
> evals to true?
>
> if ($foo) {
> }
> }
Jason, I answered you. It breaks.
This is on jvz's todo list to fix.
alpha code. alpha code. alpha code.
> Is it just \} escaped? If so that makes including JavaScript very ugly.
Can you give me an example of how it would make including JavaScript very
ugly?
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Summary of technical issues (long)
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Travis Low wrote:
> > 4.2.2) Using multiple inconsitent legacy templates simultaneously would require
> > something like #syntax directive (ouch!)
>
> Why "ouch"? Because of the work involved? I imagine that anyone wanting to
> migrate (like me) would be willing to do the work. As soon as I can figure out
> how, that is. :-(
Yes, it would require more work, make codebase more complex, and encourage
keeping a mix of inconsistent templates in your system , which is bad I believe.
As Jon said, writing a script that uses regexps to convert old templates to
new syntax is easy enough.
Rafal
Re: Summary of technical issues (long)
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/4/2000 8:55 PM, "Travis Low" <tr...@dawnstar.org> wrote:
> BTW, I like the 'automagic' begin syntax the best:
>
> #if $foo
> // something
> #end
>
> It's the simplest, one of the main reasons I chose FreeMarker way back when.
yes, i think this is the route we will end up going...although, it will be:
#if ($foo)
//
#end
with the ()'s cause it is better for parsing.
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Summary of technical issues (long)
Posted by Travis Low <tr...@dawnstar.org>.
Rafal, thanks for the informative summary. A question:
Rafal Krzewski wrote:
> -------------------------------------------------------------------------------
> 4) allowing multiple syntax options
>
> 4.1) Pros
>
> 4.1.1) Makes easier to upgrade from WM because existing templates work
>
> 4.2) Cons
>
> 4.2.1) Can result with bloated system
>
> 4.2.2) Using multiple inconsitent legacy templates simultaneously would require
> something like #syntax directive (ouch!)
Why "ouch"? Because of the work involved? I imagine that anyone wanting to
migrate (like me) would be willing to do the work. As soon as I can figure out
how, that is. :-(
BTW, I like the 'automagic' begin syntax the best:
#if $foo
// something
#end
It's the simplest, one of the main reasons I chose FreeMarker way back when.
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: Summary of technical issues (long)
Posted by Justin Wells <jr...@semiotek.com>.
Of course to have access to those years of knowledge we will have to
merge the two projects. Otherwise you will just be walking over the
same ground again without the insights that were gained from the first
cross over that ground.
Justin
On Mon, Sep 04, 2000 at 12:30:43PM -0700, Jon Stevens wrote:
> That is an idea that WebMacro implemented and now, we are going to take that
> idea and re-implement it based on years of learned knowledge and make it
> better.
Re: Summary of technical issues (long)
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Malcolm Davis wrote:
> I've never seen anything in a 'MVC' design
> about limiting the view to if/else logic (till now).
The view is not limited to if/else. If is just two-layered.
The first layer (a Java class) accesses the model, and
queries it for data to be presented. Then it passes the
data to the second layer, wihch is Velocity template,
to build HTML/XML/WML markup.
> When I see bundles of if/else, the last thing I
> think of is OO, the first thing I think of is
> 'how did I screw this up?'
First, Velocity is *very* object oriented, thanks to
extensive use of introspection on the objects that
are passed between java class and the template.
Second, using the system like Velocity actually
prevents people from screwing up, by separating
code from HTML/whatever markup.
Rafal
RE: Summary of technical issues (long)
Posted by Malcolm Davis <ma...@nuearth.com>.
I've never seen anything in a 'MVC' design
about limiting the view to if/else logic (till now).
When I see bundles of if/else, the last thing I
think of is OO, the first thing I think of is
'how did I screw this up?'
Just a thought, I could be wrong as norm.
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@e-point.pl]
> Sent: Monday, September 04, 2000 3:38 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Summary of technical issues (long)
>
>
> Malcolm Davis wrote:
> >
> > I should be turned on by if/else logic?
>
> Yes, in this particular context having
> only if/else & foreach is 'the right thing'.
> This is the conclusion that Justin Wells came to
> long time ago, and we agree with him on that.
>
> Rafal
Re: Summary of technical issues (long)
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Malcolm Davis wrote:
>
> I should be turned on by if/else logic?
Yes, in this particular context having
only if/else & foreach is 'the right thing'.
This is the conclusion that Justin Wells came to
long time ago, and we agree with him on that.
Rafal
RE: Summary of technical issues (long)
Posted by Malcolm Davis <ma...@nuearth.com>.
I should be turned on by if/else logic?
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@e-point.pl]
> Sent: Monday, September 04, 2000 3:25 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: Summary of technical issues (long)
>
>
> Malcolm Davis wrote:
>
> > I'm not turned on by if/else logic.
>
> You should. WebMacro/Velocity have much better
> grasp at MVC issues that any other tool available.
> Simplicity of the language, and separtation of
> logic and presentation were primary goals of
> these projects.
>
> Rafal
Re: Summary of technical issues (long)
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Malcolm Davis wrote:
> I'm not turned on by if/else logic.
You should. WebMacro/Velocity have much better
grasp at MVC issues that any other tool available.
Simplicity of the language, and separtation of
logic and presentation were primary goals of
these projects.
Rafal
Re: Summary of technical issues (long)
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/4/2000 1:14 PM, "Malcolm Davis" <ma...@nuearth.com> wrote:
> You are most likely correct.
>
> "Just use this simple little language
> to get what you need and nothing more"
> That sounds like what Microsoft said about VB many years ago.
> Some PERL developers believe everything should/could
> be built with PERL.
gag. that would work if VB and Perl were simple little languages. They are
not. I don't think we have any intentions of going that route.
> I hope you wouldn't re-invent JSP. JSP and Servlet
> abstraction is a good thing, and using a different
> syntax might heighten the point. But using a different
> syntax is the same reason I wouldn't use it.
We definitely will NOT re-invent JSP. We are essentially re-inventing WM.
:-)
> Struts approach uses the JSP tag and allows you
> define new tags for the interface developer.
> I'm not turned on by if/else logic.
Struts is a good thing for JSP, but it doesn't do anything to solve the
overall larger issues with the design of JSP.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
RE: Summary of technical issues (long)
Posted by Malcolm Davis <ma...@nuearth.com>.
Jon,
You are most likely correct.
"Just use this simple little language
to get what you need and nothing more"
That sounds like what Microsoft said about VB many years ago.
Some PERL developers believe everything should/could
be built with PERL.
I hope you wouldn't re-invent JSP. JSP and Servlet
abstraction is a good thing, and using a different
syntax might heighten the point. But using a different
syntax is the same reason I wouldn't use it.
Struts approach uses the JSP tag and allows you
define new tags for the interface developer.
I'm not turned on by if/else logic.
>
> > Is velocity a non-programmer abstraction or a programmer abstraction?
> > Decide on the intent NOW. Don't try to eat your cake and have it to.
> >
> > If velocity is just WebMacro for Tomcat, then keep it as is.
> >
> > If velocity is applying concepts and ideas from WebMacro
> > and others, change it to be constant with Java.
>
> Huh? You are mixing your issues together.
>
> Velocity is for web designers and programmers. It is the marriage between
> the two. One side is nice and easy for Java engineers (just put stuff into
> the Context) and the other side is easy for web designers (just use this
> simple little language to get what you need and nothing more).
>
> That is an idea that WebMacro implemented and now, we are going
> to take that
> idea and re-implement it based on years of learned knowledge and make it
> better.
>
> As for making the syntax like Java, that would be silly and pointless and
> counter productive for all of the obvious reasons. We are not trying to
> re-implement JSP.
>
> As for what servlet engine it runs in, that is irrelevant since
> this is all
> just Java code.
>
> -jon
>
> --
> http://scarab.tigris.org/ | http://noodle.tigris.org/
> http://java.apache.org/ | http://java.apache.org/turbine/
> http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
> http://www.collab.net/ | http://www.sourcexchange.com/
>
>
Re: Summary of technical issues (long)
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/4/2000 12:15 PM, "Malcolm Davis" <ma...@nuearth.com> wrote:
> Is velocity a non-programmer abstraction or a programmer abstraction?
> Decide on the intent NOW. Don't try to eat your cake and have it to.
>
> If velocity is just WebMacro for Tomcat, then keep it as is.
>
> If velocity is applying concepts and ideas from WebMacro
> and others, change it to be constant with Java.
Huh? You are mixing your issues together.
Velocity is for web designers and programmers. It is the marriage between
the two. One side is nice and easy for Java engineers (just put stuff into
the Context) and the other side is easy for web designers (just use this
simple little language to get what you need and nothing more).
That is an idea that WebMacro implemented and now, we are going to take that
idea and re-implement it based on years of learned knowledge and make it
better.
As for making the syntax like Java, that would be silly and pointless and
counter productive for all of the obvious reasons. We are not trying to
re-implement JSP.
As for what servlet engine it runs in, that is irrelevant since this is all
just Java code.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
RE: Summary of technical issues (long)
Posted by Malcolm Davis <ma...@nuearth.com>.
Hmm...
I haven't been keeping up with all of it. But, here is my 2-cents.
Is velocity a non-programmer abstraction or a programmer abstraction?
Decide on the intent NOW. Don't try to eat your cake and have it to.
If velocity is just WebMacro for Tomcat, then keep it as is.
If velocity is applying concepts and ideas from WebMacro
and others, change it to be constant with Java.
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@e-point.pl]
> Sent: Monday, September 04, 2000 1:57 PM
> To: velocity-user@jakarta.apache.org
> Subject: Summary of technical issues (long)
>
>
> Hello.
>
> I was away for the weekend, and now I find there is a serious flamewar
> going on. I'm not going to go into the issues of offending people, or
> giving users what they want vs. giving what is good for them.
>
> I tried to summarize main issues from technical point of view.
> Some of the points are gathered from the list, some are my own opinions.
> Note: I don't want to keep this thread running forever, I hope to help
> the developers to make a wise decision.
>
> ------------------------------------------------------------------
> -------------
> 1) curly brace syntax
>
> #if $foo {
> // something
> }
>
> 1.1) Pros
>
> 1.1.1) consistent with C and *Java*, which is nice for programers
> (Real Programers don't use Pascal, remember?)
>
> 1.1.2) concise (less typing)
>
> 1.2) Cons
>
> 1.2.1) can cause problems with JavaScript
> Velocity parser handles {} much better than WM parser, and
> will work correctly with JavaScript without any modification
> of the parser nor the js code. Velocity is counting opening
> and closing braces, therefore the following will work with
> no problems
>
> if() {
> // js block
> }
> #if () {
> // wm block
> }
>
> #if () {
> if() {
> #if() {
> while() {
> // and so on.
> // Velocity keeps track of which {} are which
> }
> }
> }
> }
>
> Notice that in a valid JS program, the number of opening and
> closing braces must match. Further, inside a web macro block
> the number of opening and closing braces must match also.
> Consider the following example:
>
> // some js code
> #if $condition {
> // some code with balanced braces
> } else {
> // some code with unbalanced braces
> }
> // some js code
>
> No matter what you put before and after the statement, this would
> generate invalid JS program in one of the cases.
>
> // some js code
> #foreach $obj in $list {
> // some code with unbalanced braces
> }
>
> Would generate invalid JS program if the list has any elements.
>
> My point here is: Don't put an unmatched brace inside Velocity
> block because it won't do any good.
>
> I managed to find a case where our approach would fail:
>
> if(something) {
> #foreach $condition in list {
> // do something
> } else if($condition) {
> }
>
> The braces appear in wrong order, therefore you would have
> to escape
> them, to make it work.
>
> There is another problem: When braces appear inside JS comments,
> they may be unblanced, and the progrm will still be valid.
>
> I think it's fair enough to require those unbalanced braces to
> be escaped, because it will happen rarely in real-life usage.
>
> 1.2.2) May be less obvius than begin/end for people with no programming
> background
>
> ------------------------------------------------------------------
> -------------
> 2) #begin/#end stntax
>
> #if $foo
> #begin
> // something
> #end
>
> 2.1) Pros
>
> 2.1.1) Is currently the default way of doing things in WebMacro
>
> 2.1.2) Is orthogonal to JavaScript, and most probably all other languages
> you would like to use in the templates (think templated Java code)
>
> 2.1.3) Looks consitent with other WebMacro special tokens (directives)
>
> 2.1.4) May be more obvious for non programers
>
> 2.2) Cons
>
> 2.2.1) sparse (more typing), makes templates look 'heavy'
>
> ------------------------------------------------------------------
> -------------
> 3) 'automagic' begin syntax
> #if $foo
> // something
> #end
>
> #if $foo
> // something
> #elseif $bar
> // somethig different
> #else
> // yet another thing
> #end
>
> 3.1) Pros
>
> 3.1.1) concise
>
> 3.1.2) more error proof (avoids missing/mismatched block markers)
>
> 3.2) Cons
>
> 3.2.1) Incompatibilie with WebMacro
>
> ------------------------------------------------------------------
> -------------
> 4) allowing multiple syntax options
>
> 4.1) Pros
>
> 4.1.1) Makes easier to upgrade from WM because existing templates work
>
> 4.2) Cons
>
> 4.2.1) Can result with bloated system
>
> 4.2.2) Using multiple inconsitent legacy templates simultaneously
> would require
> something like #syntax directive (ouch!)
> ------------------------------------------------------------------
> -------------
>
> Rafal
Re: Notes on WM and Velocity
Posted by Justin Wells <jr...@semiotek.com>.
On Thu, Sep 07, 2000 at 02:56:10AM -0400, Jason van Zyl wrote:
> You can say whatever you want now, but the fact is you
> never voiced your opinion that you were going to
> donate your code to the ASF until Velocity was
> announced. So how we're we supposed to know, after
> five months of negotiatiation of nothing changing
> that this was your view? How we're we supposed to
> know. Extract that artifact from you?
Jason, it's obvious you've been told a bunch of lies. I'm sorry
to have to put it that strongly, but it's true.
"five months of negotiation of nothing changing"---where did you
get that from? I revised the SPL 27 times during that five months,
resolving every single concern raised by the ASF about it during
that time. I'd hardly say nothing changedd: it changed radically.
It's pretty clear that I was willing to adapt to whatever needs
the ASF had. I demonstrated a willingness to co-operate and bend
at *every* turn.
That process of me showing a willingness to negotiate and bend
has simply continued in public following the release of Velocity.
If someone told you that I was inflexible and unwilling to change
my position or my license then you were simply lied to.
Suggesting that I was somehow inflexible or unwilling to change at
any point is a huge misrepresentation of the facts. I think I've
proven both in public and in private that I've been, at every
point, willing to consider all kinds of alternatives.
> Now that the license
> has changed very recently you seem to be trying
> to shift the blame toward us.
I'm not shifting the blame towards anyone, but you have to accept
at least half of it. The license has been changing almost
continuously for six months now.
I should have looked into Turbine more closely and realized that
you could not wait another couple of months for a licensing fix.
Jon left me under the impression that WM was not integral to
Turbine but simply one template system that could be plugged
into it. If that had been true, then fixing the licensing for
WM would not have been an urgent matter as Turbine users could
use the GPL'd version if they liked, or use a different system
in the meantime. The eventual resolution to the license issue
(and it was clearly eventual) would have been enough.
As it turns out that wasn't the situation: WM is used heavily
in Turbine and it was holding up the release. That's something
that nobody told me, and it's probably my fault that I didn't
go and investigate and find it out for myself.
If you want to apportion blame then the ASF has to accept some
blame for not contacting me immediately upon the creation of
the Velocity project. In retrospect I was clearly willing to
work with the ASF and place WM under the Apache license. We
simply wouldn't be here if that one step had been taken.
> Velocity was started for valid reasons
I'd say, it was started for what must have seemed like valid
reasons at the time, given the misconceptions flying at the ASF
about the situation with WM.
Now we have to resolve this and it seems that the best way is
to view the two projects as a single project with an experimental
tree investigating new ideas. That means you will have to adjust
your thinking and view Velocity that way. Giving you a 2.0 number
allows you to break the syntax in some ways, but putting it
under the same project does require you to take a more active
interest in working with the existing code base.
It's a two way street, core WM people will also be expected to
contribute ideas to the Velocity project.
> Both points above you are viewing that WM was an option. But
> it wasn't. In your opinion it was, in the ASF's it wasn't.
WM was an option, you simply didn't realize it. And let's not
beat around the bush: the ASF made whatever decisions it made
on the basis of the information people provided to it. Wrong
decisions result from wrong information.
Brian's interest in resolving this I think to some extent
reflects his concern over this. He was aware of the license
problem brewing and I think feels he should have done something
sooner to resolve the issue. In retrospect, it very clearly
was a resolvable issue.
> > There can be multiple implementations but right now we are looking at
> > a community split. People say things like "Oh, I don't know whether I
> > should use something like WM, there are all kinds of different versions
> > and I might wind up using one that doesn't catch on."
>
> When has indecision never been present when choosing a product?
> And who in their right mind would feel comfortable selecting
> a product who only had one vendor?
You need more experience working with commercial developers, it doesn't
work quite like you are supposing. I can put the multiple vendor
spin on it, but the whole thing is making people uncomfortable.
Unless the projects are really merged there's the possibility of
divergence, and that really concerns people.
Standards are really not a substitute for a merged team. It's very
difficult to specify things so exactly that an application can
migrate fluidly between two implementations--it's a huge effort,
and it'll put a serious dent in our progress if we have to go
that route rather than a merger.
> Program to an interface. I don't see what's wrong. The parser is
> definitely something that needs to be re-written, and how fast
> would you have asked for a new parser based on JavaCC if
> Velocity hadn't shown up. Who knows? But it more then likely
> wouldn't have been a couple of days ago! You don't seem
> interested in using our parser because you asked someone
> to re-implement it.
I'm interested in using your parser. The re-implmentation might
make most sense as an adaptation of what you've done. Your parser
will have to be modified to meet WM's full requirements, such
as pluggable directives.
> What if in trying to recreate the introspection engine
> I find five things that you never considered. Is that
> impossible, I don't think so.
Sure, but we've spent a lot of time educating you on the ten
things you never realized that we've known for a long time.
Starting completely from scratch is a net loss. Re-inventing
the wheel is not the same thing as improving it.
> They were not identically licensed at the time I started. And
> you continually twist this fact to your advantage.
I'm twisting nothing. I was always interested in seeing the
license adapted in whatever way it had to be to enable the ASF
to use it, and I made that clear for five months. It shouldn't
have been a surprise to you that I was willing to change the
license.
I have the CVS commit logs to prove that by the way. I also have
the email logs with Jon as well, but that's private stuff that
I can't repost here.
There's really no excuse for the ASF thinking that I was unwilling
to adapt to meet its needs.
> I started Velocity to solve a problem that wasn't resolved.
> Why it wasn't resolved may be the fault of multiple parties,
> but the fact remained it was unresolved.
But now it is resolved, and that changes a lot of things.
> > > Velocity started as an OSS project, and although I
> > > have done a lot of the work, it has been in plain
> > > view the whole time. You have really only started
> > > working in a truly OSS fashion in the last couple
> > > of weeks in order to adhere to the ASF way
> > > of doing things.
> >
> > ?!?!?!?!?!
> >
> > WM has been an OSS project since 1997. What on earth are you talking
> > about? I really think you have no idea...
>
> Listen, you put a GPL license on it.
....
> WM had an opensource license, but wasn't developed in an OSS
> fashion.
And what exactly is an "OSS fashion"? WM has been accepting code
contributions from people since 1997, lots of them. I think you're
being a bit of a bigot and insisting that only an Apache process
is an opensource project.
Since Linux has no CVS archive, and a single person maintaining the
source tree, are you going to maintain that it is not an opensource
project, or not developed in an opensource way?
That's ridiculous.
You can argue that you think an Apache process is better, but you
are going to have to retract the gross misreprentations about WM
not being an opensource project or under an opensource license.
That's just license/process bigotry.
It's true that over the last six months I've been a lot busier
than I had been in the past. If you look in the WM archive, you can
see that I was starting to open up the CVS tree to other people as
a reaction to my being busy. But, prior to that, I ran WM pretty
much the same way Linux is run.
> I didn't say that, or imply that at all. I am asserting
> that the way _you_ ran the project wasn't in the OSS
> spirit. How many people had CVS write access until
> a couple of days ago? As far as Linux goes, of course
> it is an OSS project. The CVS is rock solid, the
> user base is huge. And Linus makes timely responses
> to almost every request.
You simply have no idea what you are talking about. There is no
CVS repository for Linux. There is only Linus's copy, on his
hard disk, which he himself applies patches to, and periodically
releases as a snapshot.
Having an open source repository is not and never has been a
requirement of an OSS process. The requirement is that you accept
changes from other people and merge them in.
Over the last six months I've lost the time to do that properly,
and if you look, over exactly that same period of time I began
opening upt he CVS tree.
In answer to your question, nine people had access to the WM
CVS tree, including Jon Stevens.
It's obvious that you started the Velocity project with a lot
of misinformation about WM. That's too bad.
Justin
Re: Notes on WM and Velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 6 Sep 2000, Justin Wells wrote:
> On Wed, Sep 06, 2000 at 02:06:46PM -0400, Jason van Zyl wrote:
>
> > I'm sure the situation I am in right now is very similiar
> > to when you started WM. You probably did a big chunk of
> > it primarily by yourself. And I would have worked on
> > WM if I could have, but I could never look at the source
> > until recently. I am trying to write as much documentation
> > as I can so others can see what it is I'm trying to do.
>
> When I first wrote WM (1997) there were no template systems available
> for Java, otherwise I would have used one instead of writing a new one.
>
> > Certainly I could have gleaned more from the mailing
> > lists, but if the source code to WM is analagous to
> > a body of scientific literature then yes I did
> > have to ignore it until two weeks ago.
>
> That's not true, you guys never asked me for permission to look at it.
> You ran your project in secret for some reason, and you never told me
> you were starting it otherwise I would have immediately donated WM
> to the Apache group.
Well this is certainly part of the misconception. A single act
of permission is not good enough. It just isn't safe. You give
permission for us to use version X, then for whatever unforseeable
reason you decide to revoke that permission for version Y. That
potentiality was not an acceptable risk however unlikely. WM was not
compatible for for distribution according to the ASF. I am volunteering
my time for the ASF, who am I going to listen to? I only
worked on it for two weeks before we announced it.
You can say whatever you want now, but the fact is you
never voiced your opinion that you were going to
donate your code to the ASF until Velocity was
announced. So how we're we supposed to know, after
five months of negotiatiation of nothing changing
that this was your view? How we're we supposed to
know. Extract that artifact from you?
> The whole thing started effectively out of miscommunication between
> Jon and I, which is a really stupid reason to fork a community. With
> things like JTemplator at least they have some pretty radically
> different ideas about how templating should work (not just differences
> over how things should be implementented.
It was certainly a miscommunication. But you keep asserting
that we are intentionally trying to fork the community.
That is inaccurate: who accomodated a meeting with Jon.
The ASF did, and who is working on the licensing problems
on behalf of you in order to merge these projects. The
ASF. As an ASF project we are not trying to fork the
community. We are trying to help it, that was the
original intent of Velocity. Now that the license
has changed very recently you seem to be trying
to shift the blame toward us. Velocity was
started for valid reasons, and when we started
WM was not under an ASF license (at least not
acceptable to the ASF WRT their interpretation
which is what counts for Velocity project). And
therefore could not consider using it.
> I'm not blaming anyone for the miscommunication, it was as much my
> fault as anyone else--but in retrospect, that's clearly how we got
> to where we are today.
It definitely is how we got here.
> Jon was under some impression that I would never open up the source
> in a useful way. I was under the impression that he could wait while
> we took the time to get the licensing right. We were both wrong.
I can never know the nature of what transpired.
> Now you're caught up in the middle of it.
I'm not caught up in it. I chose to be in the position
I am. Jon didn't force me to do anything. He
isn't to blame for anything. He gave me a way out
several times, but it was my choice to continue.
> > A specification will prevent incompatibilities, I've started
> > a simple BNF and a list of questions to be answered for
> > the drafting of a spec.
>
> The template syntax is pretty trivial,
Yes, but it still needs to be defined.
> the real issues are elsewhere,
> and frequently political rather than technical issues.
They may be, but issues can be decided upon, certain
behaviour accepted practice.
> Many of WM's
> features are there to allow people with different views to work with
> the same code base. That's a political rather than a technical
> lesson, and one that you'll just have to re-learn the hard way
> (and for no good reason) if you just go off completely on your own
> without in some way being a part of the original project.
Political or technical, the resultant behaviour in the tool
can be defined. We're certainly not guessing.
And what was our discussion about earlier on today?
You described in greater detail how WM works, and I
said I would endeavour to implement the features that
allow people with different views to work with the
same tool.
> > run WM templates along side Velocity templates. Our
> > goal is to provide a clean upgrade path not necessarily
> > keep the same syntax. We would definitely like to
> > explore removing the block identifiers i.e.
>
> Yeah sure. The point is that modifications like this make a lot of
> sense in the main WM tree as well. They don't distinguish the
> Velocity project from WM.
>
> You're viewing WM as though it's done and there's no interest in
> improving or extending it, but it's been under almost continuous
> improvement since the day it was created.
Both points above you are viewing that WM was an option. But
it wasn't. In your opinion it was, in the ASF's it wasn't.
I agree that WM has matured steadily. I never disputed that
fact? I simply couldn't use it as decided by the ASF.
> > I think we should start on a BNF and a specification now. If
> > it is true that WM style templating is a competitor to JSP,
> > why can't there be serval implementation of WM style just as
> > there are many JSP implementations?
>
> There can be multiple implementations but right now we are looking at
> a community split. People say things like "Oh, I don't know whether I
> should use something like WM, there are all kinds of different versions
> and I might wind up using one that doesn't catch on."
When has indecision never been present when choosing a product?
And who in their right mind would feel comfortable selecting
a product who only had one vendor? Would you buy a solar
powered car, or a car with a combustion engine? Most people
would by a car with a combustion engine (right now). Solar powered cars
may be better overall, but in the realm of combustion
powered cars there is more experience, more parts, more
information. This is the result of competing bodies,
cooperating as necessary as not to destroy themselves
because the eradication of the combustion engine car
business would be detrimental to all vendors.
So do you think I'm intentionally trying to undermine
the the WM style template engine by trying to implement
it in an independent fashion? Do you think consumers of
a particular technology would feel comfortable with
only a single implementation or vendor. No way!
What if we decided on a spec and there were 10
different implementations of a WM style template
engine? Then we could compete with JSP! Why is
JSP so successful? Because there are numerous
implementations providing the _exact_ same
functionality. They are assured by that simple
fact: they can use another version of the
tool in the _exact_ same fashion. There is
safety in that.
> One big weakness of the Apache group is that you guys have very little
> experience with the way decisions are made by the people who you expect
> to have use your software. Issues like this really matter.
>
> Merging the projects into a single effort is pretty much required if we
> want people to take us seriously.
I think the exact opposite. I think people will notice that "hey, this
technology must be pretty good if another group is trying to
produce an identical implementation". The WM style system is an awesome
idea, I give you total credit for the initial idea! I am
a simple implementor :-)
> Also it seems wrong to me that you would go and implement the same features
> as WM in pretty much equivalent ways. Things like the parser are good to
> rewrite, but things like the introspector are pretty solid.
Program to an interface. I don't see what's wrong. The parser is
definitely something that needs to be re-written, and how fast
would you have asked for a new parser based on JavaCC if
Velocity hadn't shown up. Who knows? But it more then likely
wouldn't have been a couple of days ago! You don't seem
interested in using our parser because you asked someone
to re-implement it. So the competition has been good.
Your users are going to get a more robust parser one
way or another. And as far as the introspection engine
goes (even after admitting to my incorrect analysis) I still think
it could be cut down, information cached better, and
generally improved upon.
What if in trying to recreate the introspection engine
I find five things that you never considered. Is that
impossible, I don't think so.
I think you are taking this far too personally. I
believe in no way have I been a detriment to the
WM community by trying to re-implement the technology
they wish to use. There is safety in diversity.
> I really don't see the point of a duplication of effort between two
> identically licensed projects trying to accomplish the identical things.
> It's sound for you to rework things that aren't done well in WM (like
> the parser) but it's just an academic exercise for you to go and
> rewrite stuff that's solid and working.
They were not identically licensed at the time I started. And
you continually twist this fact to your advantage. I did
NOT start this project at a point in time wher WM was
under an acceptable version of the APL.
And it is certainly not academic to re-implement a
technology. You say they work well (intro engine ...) , but what kind
of valid reason is that to halt velocity. What if
Velcocity ends up being a better implementation, then
it will certainly have been worth it. And if it ends
up being a poorer implementation then you have
verification that the initial implementation
was good and that your assertions are true. But
right now they are simply assertions.
> Is that kind of rework, just for fun, something the ASF should support?
> The opinion at the meeting between Brian Behlendorf, Jon Stevens, myself,
> and Brian Goetz was that it was not.
Or course it is fun for me! But to imply, incorrectly, that
this is merely for my entertainment is incorrect. The
framing of Velocity in that light is unfair and untrue.
I started Velocity to solve a problem that wasn't resolved.
Why it wasn't resolved may be the fault of multiple parties,
but the fact remained it was unresolved.
> What the ASF does want to support, as I understand it, is experiments to
> see if something can be improved via a different approach. That's not
> quite the same as "I just feel like doing it myself, just because."
>
> > Velocity started as an OSS project, and although I
> > have done a lot of the work, it has been in plain
> > view the whole time. You have really only started
> > working in a truly OSS fashion in the last couple
> > of weeks in order to adhere to the ASF way
> > of doing things.
>
> ?!?!?!?!?!
>
> WM has been an OSS project since 1997. What on earth are you talking
> about? I really think you have no idea...
Listen, you put a GPL license on it. But! You are notorious
for not answering promptly to email regarding WM, that I
found from reading the WM archives. The CVS has been
spotty and responses to requests not being made. I found
evidence of all this on the mailing list. WM had an
opensource license, but wasn't developed in an OSS
fashion. That is strictly my opinion. But that
will change if our projects merge because WM
will be housed at Jakarta. No spotty CVS service,
and a larger user base for better response to
problems because you will have a wider audience:
the WM and Velocity community combined.
> Are you asserting that anything that is not run Apache style is not
> opensource? For example, Linux would not be opensource according to
> you because, like WM, Linux has one person in control of the entire
> code base?
>
> That's just a little too shrill and religious for me to accept.
I didn't say that, or imply that at all. I am asserting
that the way _you_ ran the project wasn't in the OSS
spirit. How many people had CVS write access until
a couple of days ago? As far as Linux goes, of course
it is an OSS project. The CVS is rock solid, the
user base is huge. And Linus makes timely responses
to almost every request.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Notes on WM and Velocity
Posted by Justin Wells <jr...@semiotek.com>.
On Wed, Sep 06, 2000 at 02:06:46PM -0400, Jason van Zyl wrote:
> I'm sure the situation I am in right now is very similiar
> to when you started WM. You probably did a big chunk of
> it primarily by yourself. And I would have worked on
> WM if I could have, but I could never look at the source
> until recently. I am trying to write as much documentation
> as I can so others can see what it is I'm trying to do.
When I first wrote WM (1997) there were no template systems available
for Java, otherwise I would have used one instead of writing a new one.
> Certainly I could have gleaned more from the mailing
> lists, but if the source code to WM is analagous to
> a body of scientific literature then yes I did
> have to ignore it until two weeks ago.
That's not true, you guys never asked me for permission to look at it.
You ran your project in secret for some reason, and you never told me
you were starting it otherwise I would have immediately donated WM
to the Apache group.
The whole thing started effectively out of miscommunication between
Jon and I, which is a really stupid reason to fork a community. With
things like JTemplator at least they have some pretty radically
different ideas about how templating should work (not just differences
over how things should be implemented).
I'm not blaming anyone for the miscommunication, it was as much my
fault as anyone else--but in retrospect, that's clearly how we got
to where we are today.
Jon was under some impression that I would never open up the source
in a useful way. I was under the impression that he could wait while
we took the time to get the licensing right. We were both wrong.
Now you're caught up in the middle of it.
> A specification will prevent incompatibilities, I've started
> a simple BNF and a list of questions to be answered for
> the drafting of a spec.
The template syntax is pretty trivial, the real issues are elsewhere,
and frequently political rather than technical issues. Many of WM's
features are there to allow people with different views to work with
the same code base. That's a political rather than a technical
lesson, and one that you'll just have to re-learn the hard way
(and for no good reason) if you just go off completely on your own
without in some way being a part of the original project.
> run WM templates along side Velocity templates. Our
> goal is to provide a clean upgrade path not necessarily
> keep the same syntax. We would definitely like to
> explore removing the block identifiers i.e.
Yeah sure. The point is that modifications like this make a lot of
sense in the main WM tree as well. They don't distinguish the
Velocity project from WM.
You're viewing WM as though it's done and there's no interest in
improving or extending it, but it's been under almost continuous
improvement since the day it was created.
> I think we should start on a BNF and a specification now. If
> it is true that WM style templating is a competitor to JSP,
> why can't there be serval implementation of WM style just as
> there are many JSP implementations?
There can be multiple implementations but right now we are looking at
a community split. People say things like "Oh, I don't know whether I
should use something like WM, there are all kinds of different versions
and I might wind up using one that doesn't catch on."
One big weakness of the Apache group is that you guys have very little
experience with the way decisions are made by the people who you expect
to have use your software. Issues like this really matter.
Merging the projects into a single effort is pretty much required if we
want people to take us seriously.
Also it seems wrong to me that you would go and implement the same features
as WM in pretty much equivalent ways. Things like the parser are good to
rewrite, but things like the introspector are pretty solid.
I really don't see the point of a duplication of effort between two
identically licensed projects trying to accomplish the identical things.
It's sound for you to rework things that aren't done well in WM (like
the parser) but it's just an academic exercise for you to go and
rewrite stuff that's solid and working.
Is that kind of rework, just for fun, something the ASF should support?
The opinion at the meeting between Brian Behlendorf, Jon Stevens, myself,
and Brian Goetz was that it was not.
What the ASF does want to support, as I understand it, is experiments to
see if something can be improved via a different approach. That's not
quite the same as "I just feel like doing it myself, just because."
> Velocity started as an OSS project, and although I
> have done a lot of the work, it has been in plain
> view the whole time. You have really only started
> working in a truly OSS fashion in the last couple
> of weeks in order to adhere to the ASF way
> of doing things.
?!?!?!?!?!
WM has been an OSS project since 1997. What on earth are you talking
about? I really think you have no idea...
Are you asserting that anything that is not run Apache style is not
opensource? For example, Linux would not be opensource according to
you because, like WM, Linux has one person in control of the entire
code base?
That's just a little too shrill and religious for me to accept.
Justin
Re: Notes on WM and Velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 6 Sep 2000, Justin Wells wrote:
> On Wed, Sep 06, 2000 at 03:41:55AM -0400, Jason van Zyl wrote:
>
> > I have to go over it first hand in order to understand, no
> > about of reading the mailing lists will substitute
> > for trying to do it myself.
>
> But, the point of an opensource project is that you should not be
> trying to do it yourself. You should be trying to do it in collaboration
> with others, and there are lots of developers on the WM list who have
> already learned the things you have not yet begun to think about in
> the future.
I'm sure the situation I am in right now is very similiar
to when you started WM. You probably did a big chunk of
it primarily by yourself. And I would have worked on
WM if I could have, but I could never look at the source
until recently. I am trying to write as much documentation
as I can so others can see what it is I'm trying to do.
> It's important to experiment with new ideas, but it's also good to have
> some understanding of what everyone already knows.
>
> The situation is the same in science: You don't have to ignore the
> current body of scientific literature in order to have new ideas.
Certainly I could have gleaned more from the mailing
lists, but if the source code to WM is analagous to
a body of scientific literature then yes I did
have to ignore it until two weeks ago.
> > All I want to do is try
> > to get a first implementation of Velocity to see how
> > the whole thing works. I may fully concede if all
> > my assumptions are wrong. I am only trying to
> > learn. You may have discovered certain things,
> > but I always like checking things out for myself.
> > I'm sure you're the same way.
>
> The danger here is that you're going to make implementation decisions
> that are not theoretically significant but take you further and further
> from compatibility with WebMacro, hugely increasing the work we'll have
> to do when everything merges.
A specification will prevent incompatibilities, I've started
a simple BNF and a list of questions to be answered for
the drafting of a spec. The syntax that Velocity will
parse can be configured so there can be one parser that
is WM compatible and at the same time we can work
on ideas for a new cleaner syntax. People should also be able to run
templates with multiple syntaxes. For example we
could write a parser for Tea templates. People could
run WM templates along side Velocity templates. Our
goal is to provide a clean upgrade path not necessarily
keep the same syntax. We would definitely like to
explore removing the block identifiers i.e.
#if ($foo)
#else
#end
And we can experiment with that and at the same
time provide WM compatibility.
> > So you have comparisons of something like Tea vs WebMacro for
> > a similiar template? I will download the archives and read
> > them all.
>
> I have profiles showing that WebMacro represents 5% of a typical page
> hit at AltaVista. For a site like AltaVista, optimizing WebMacro further
> is insignificant. I don't know what kind of site you want to run WM on
> that has more traffic or more scalability requirements than that--there
> really aren't too many that are larger.
>
> Most of the time is consumed by the servlet engine itself; the remainder
> goes into JDBC, accessing other kinds of back-ends, and real processing.
>
> You've described yourself as a performance guy, so you must know that the
> first rule of performance optimization is that you profile first and then
> optimize the stuff that matters.
I agree, I haven't started optimizing anything yet.
> > > Knowing exactly which methods are going to be invoked would
> > > be very, very bad. That strips the programmer of the freedom
> > > to switch the methods around without telling the page designer,
> > > horribly undermining the advantages of an MVC approach to
> > > servlet design.
> >
> > So $foo.Bar.Wonder.Amazement instead of always being
> > interpreted as $foo.getBar().getWonder().getAmazement():
> > any one of those entries could be a key of an object
> > of the entry in front of it. So the programmer could
> > juggle all those around? Do you find that happens
> > a lot?
>
> Yes, it happens all the time. The typical scenario is that the
> programmer has mocked up the back-end data with hashtables and
> lists and is gradually switching to a real implementation.
Fair enough, I will endeavour to add feature.
> > If at the end of this we do merge code, I will know a
> > lot more by asking lots of questions, making some
> > assumptions (sometimes incorrect). I'm not trying
> > to start a fight, I'm just trying to know what you
> > know :-) Once again, my apologies for the incorrect
> > analysis.
>
> We should pretty much start that now, I think. We need to merge
> the two projects and it's not going to work out if we work separately
> for awhile and then all in one day suddenly try to make them a single
> project. It has to happen in steps.
I think we should start on a BNF and a specification now. If
it is true that WM style templating is a competitor to JSP,
why can't there be serval implementation of WM style just as
there are many JSP implementations?
> That means you looking at the WebMacro code base a lot more than you
> have been, and using as much of it as you reasonably can for compatibility
> reasons. It also means WM people helping you out as you do that.
My point is that I shouldn't have to go pouring through
the code. It should adhere to a spec, but I am starting
to look at the code now anyway. If WM style templating is
to become a standard then there should be a spec and there
is no reason why there can't be more then one implementation.
But one example that led me astray
in my analysis was that feeding in lists to WM introspection
engine worked, plus at the top of PropertyOperator the
JavaDoc only indicated straight lists, there was no
indication of the nesting of methods. Plus there is
no real way to dump the syntax to see and if there
is it's not clear in the properties file. In Velocity
the code is young and the docs aren't great but
we have a good documentation system using StyleBook,
and Velocity a configuration file option for dumping
the syntax. So between great docs (very shortly)
and a mechanism whereby the inner workings can be
exposed almost immediately with a config change,
I hope that Velocity becomes more self explanatory,
easier to explain and hopefully attract more
developers because of that fact.
Velocity started as an OSS project, and although I
have done a lot of the work, it has been in plain
view the whole time. You have really only started
working in a truly OSS fashion in the last couple
of weeks in order to adhere to the ASF way
of doing things. I have already eaten my words
a couple of times but that doesn't bother me, poking around
is the only way to really find out how things
work. Rarely are the whole inner workings of
a piece of software laid out clearly, it's difficult
I know and making some conjectures is the
only way to illicit a full response.
I am all for sharing ideas and sharing source.
I may be doing a lot of experimentation and
not really pouring over the WM source, but that
doesn't mean we can't work on a spec together,
share source, or ideas. I'm using your FastWriter,
and you can take one of the parsers when were
done. There will probably be a JavaCC one and
an Antlr one, and John is looking at SableCC.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Notes on WM and Velocity
Posted by Justin Wells <jr...@semiotek.com>.
On Wed, Sep 06, 2000 at 03:41:55AM -0400, Jason van Zyl wrote:
> I have to go over it first hand in order to understand, no
> about of reading the mailing lists will substitute
> for trying to do it myself.
But, the point of an opensource project is that you should not be
trying to do it yourself. You should be trying to do it in collaboration
with others, and there are lots of developers on the WM list who have
already learned the things you have not yet begun to think about in
the future.
It's important to experiment with new ideas, but it's also good to have
some understanding of what everyone already knows.
The situation is the same in science: You don't have to ignore the
current body of scientific literature in order to have new ideas.
> All I want to do is try
> to get a first implementation of Velocity to see how
> the whole thing works. I may fully concede if all
> my assumptions are wrong. I am only trying to
> learn. You may have discovered certain things,
> but I always like checking things out for myself.
> I'm sure you're the same way.
The danger here is that you're going to make implementation decisions
that are not theoretically significant but take you further and further
from compatibility with WebMacro, hugely increasing the work we'll have
to do when everything merges.
> So you have comparisons of something like Tea vs WebMacro for
> a similiar template? I will download the archives and read
> them all.
I have profiles showing that WebMacro represents 5% of a typical page
hit at AltaVista. For a site like AltaVista, optimizing WebMacro further
is insignificant. I don't know what kind of site you want to run WM on
that has more traffic or more scalability requirements than that--there
really aren't too many that are larger.
Most of the time is consumed by the servlet engine itself; the remainder
goes into JDBC, accessing other kinds of back-ends, and real processing.
You've described yourself as a performance guy, so you must know that the
first rule of performance optimization is that you profile first and then
optimize the stuff that matters.
> > Knowing exactly which methods are going to be invoked would
> > be very, very bad. That strips the programmer of the freedom
> > to switch the methods around without telling the page designer,
> > horribly undermining the advantages of an MVC approach to
> > servlet design.
>
> So $foo.Bar.Wonder.Amazement instead of always being
> interpreted as $foo.getBar().getWonder().getAmazement():
> any one of those entries could be a key of an object
> of the entry in front of it. So the programmer could
> juggle all those around? Do you find that happens
> a lot?
Yes, it happens all the time. The typical scenario is that the
programmer has mocked up the back-end data with hashtables and
lists and is gradually switching to a real implementation.
> If at the end of this we do merge code, I will know a
> lot more by asking lots of questions, making some
> assumptions (sometimes incorrect). I'm not trying
> to start a fight, I'm just trying to know what you
> know :-) Once again, my apologies for the incorrect
> analysis.
We should pretty much start that now, I think. We need to merge
the two projects and it's not going to work out if we work separately
for awhile and then all in one day suddenly try to make them a single
project. It has to happen in steps.
That means you looking at the WebMacro code base a lot more than you
have been, and using as much of it as you reasonably can for compatibility
reasons. It also means WM people helping you out as you do that.
Justin
Re: Notes on WM and Velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 6 Sep 2000, Justin Wells wrote:
> On Mon, Sep 04, 2000 at 03:22:50PM -0400, Jason van Zyl wrote:
>
> > $object.Foo.Bar.getItem("param1", "param2").Price
> >
> > The WM parser takes this and creates the following
> > to pass into the introspection engine:
> >
> > (2)
> >
> > { "Foo", "Bar", "getItem", "param1", "param2", "Price" }
>
> That's not quite right, it'll become:
>
> { object, Foo, Bar, { getItem(param1,param2) }, price }
>
> So the important semantics are retained. Also, note that the ()
> stuff is considered a hack and is deprecated whenever possible. It's
> an example of where the WM syntax can break the MVC paradigm. When
> you refer to a method by name you lose the ability to swap it with
> a different implementation of the same property. For example, if
> you write
>
> $foo.Bar
>
> you don't know whether Bar is a hashtable entry or a getBar() method,
> but if you write:
>
> $foo.getBar()
Sorry, I took that from the docs on your site. That something
like $foo.Bar resolves into properties. So "object" is a
Hashtable and "Foo" can be a key?
> then you do know. One reason why the Velocity project really needs
> to merge with WebMacro is that we already have worked through all
> this stuff years ago, and you're just now coming upon the same
> questions we had before.
I don't mind that, this is probably very illuminating for
all the readers: I have obviously misunderstood some
things, and I appreciate your taking the time to
explain.
> The idea of having a merged project with two code trees is that you
> can experiment with new things in the new code tree, but there's also
> just no point in going over some of this ground again.
I have to go over it first hand in order to understand, no
about of reading the mailing lists will substitute
for trying to do it myself. All I want to do is try
to get a first implementation of Velocity to see how
the whole thing works. I may fully concede if all
my assumptions are wrong. I am only trying to
learn. You may have discovered certain things,
but I always like checking things out for myself.
I'm sure you're the same way.
>
> > Now this time saved doesn't _really_ matter
> > if the end result is a compiled template (I'm
> > assuming WM compiles templates down into a class file).
>
> There's no point in compiling to a .class file, the performance
> win would be insignificant compared to what WM does now. This is
> another thing that the WM list determined a long time ago. In fact,
> no amount of optimizing the template language at this point leads
> to any significant difference in performance--the truth is that
> WebMacro represents an insignificant amount of processing on a
> typical servlet page. It's less than 5% of the cost of a typical
> page hit, so reducing the cost of WM to zero would only buy you
> a 5% gain in performance.
So you have comparisons of something like Tea vs WebMacro for
a similiar template? I will download the archives and read
them all.
> My opinion is that there is effectively NO performance issue with WM.
> The parser stuff is interesting because it's been the largest source
> of bugs, not for any performance reason.
>
>
> > But during development the execution
> > while debugging would be significantly less knowing
> > exactly what methods have to be invoked with
> > what parameters instead of having to hammer
> > through (2) every time the page is changed and tested.
>
> Knowing exactly which methods are going to be invoked would
> be very, very bad. That strips the programmer of the freedom
> to switch the methods around without telling the page designer,
> horribly undermining the advantages of an MVC approach to
> servlet design.
So $foo.Bar.Wonder.Amazement instead of always being
interpreted as $foo.getBar().getWonder().getAmazement():
any one of those entries could be a key of an object
of the entry in front of it. So the programmer could
juggle all those around? Do you find that happens
a lot?
After the programmer has agreed with the designer
on a set of macros, how often have you found that
the macros need to change. Provided you given
the designer something relatively flexible.
Can you give me an example of where a macro
hasn't changed but the signature it resolves
to does? Something you've had to do to solve
a problem.
> > The WM introspection engine simply works
> > the way it does because the parsing mechanism
> > is deficient WRT to delivering useful semantic
> > information to the introspection engine.
>
> Sorry, that's just not true. For one thing, WM does have the semantic
> information you're talking about available in its current parser, and
> does store it. The main reason is that the template should NOT have
> any knowledge of how the back end was implemented.
>
> Second, if I'd needed any more information out of the parser I would
> have extended the parser to provide it. It's not like it's a lot of
> code. Bug ridden code maybe, but not a lot of it.
>
> WM's parser is recursive decent just like the parser JavaCC will
> generate for you. It effectively walks a syntax tree just like your
> JavaCC parser will. There are effectively NO theoretical differences
> between the parsing approaches.
>
> The main difference is that hand-written parsers are buggy.
My apologies for the incorrect analysis, but I probably
never would have received such a thorough answer otherwise.
I had to take a crack at it!
So your reasons for not trying know the exact signature
is for back end programmers to be able to change things.
I'm still not entirely clear on this, an example
would be good.
>
> > The other thought Terrence had was the use of #
> > as the directive character. Would this interfere
> > with XML in some way, or does it already. Maybe
> > this is already the best choice, but maybe
> > there is a better one? Any thoughts or suggestions.
> > I personally like the #.
>
> You really should read the WM archives. I come from an SGML/XML
> background, # was chosen because it is not used in XML.
I figured you would answer this :) I know you have an SGML/XML
background. In the past I met with Yuri Rubinski many times :)
If at the end of this we do merge code, I will know a
lot more by asking lots of questions, making some
assumptions (sometimes incorrect). I'm not trying
to start a fight, I'm just trying to know what you
know :-) Once again, my apologies for the incorrect
analysis.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Notes on WM and Velocity
Posted by Justin Wells <jr...@semiotek.com>.
On Mon, Sep 04, 2000 at 03:22:50PM -0400, Jason van Zyl wrote:
> $object.Foo.Bar.getItem("param1", "param2").Price
>
> The WM parser takes this and creates the following
> to pass into the introspection engine:
>
> (2)
>
> { "Foo", "Bar", "getItem", "param1", "param2", "Price" }
That's not quite right, it'll become:
{ object, Foo, Bar, { getItem(param1,param2) }, price }
So the important semantics are retained. Also, note that the ()
stuff is considered a hack and is deprecated whenever possible. It's
an example of where the WM syntax can break the MVC paradigm. When
you refer to a method by name you lose the ability to swap it with
a different implementation of the same property. For example, if
you write
$foo.Bar
you don't know whether Bar is a hashtable entry or a getBar() method,
but if you write:
$foo.getBar()
then you do know. One reason why the Velocity project really needs
to merge with WebMacro is that we already have worked through all
this stuff years ago, and you're just now coming upon the same
questions we had before.
The idea of having a merged project with two code trees is that you
can experiment with new things in the new code tree, but there's also
just no point in going over some of this ground again.
> Now this time saved doesn't _really_ matter
> if the end result is a compiled template (I'm
> assuming WM compiles templates down into a class file).
There's no point in compiling to a .class file, the performance
win would be insignificant compared to what WM does now. This is
another thing that the WM list determined a long time ago. In fact,
no amount of optimizing the template language at this point leads
to any significant difference in performance--the truth is that
WebMacro represents an insignificant amount of processing on a
typical servlet page. It's less than 5% of the cost of a typical
page hit, so reducing the cost of WM to zero would only buy you
a 5% gain in performance.
My opinion is that there is effectively NO performance issue with WM.
The parser stuff is interesting because it's been the largest source
of bugs, not for any performance reason.
> But during development the execution
> while debugging would be significantly less knowing
> exactly what methods have to be invoked with
> what parameters instead of having to hammer
> through (2) every time the page is changed and tested.
Knowing exactly which methods are going to be invoked would
be very, very bad. That strips the programmer of the freedom
to switch the methods around without telling the page designer,
horribly undermining the advantages of an MVC approach to
servlet design.
> The WM introspection engine simply works
> the way it does because the parsing mechanism
> is deficient WRT to delivering useful semantic
> information to the introspection engine.
Sorry, that's just not true. For one thing, WM does have the semantic
information you're talking about available in its current parser, and
does store it. The main reason is that the template should NOT have
any knowledge of how the back end was implemented.
Second, if I'd needed any more information out of the parser I would
have extended the parser to provide it. It's not like it's a lot of
code. Bug ridden code maybe, but not a lot of it.
WM's parser is recursive decent just like the parser JavaCC will
generate for you. It effectively walks a syntax tree just like your
JavaCC parser will. There are effectively NO theoretical differences
between the parsing approaches.
The main difference is that hand-written parsers are buggy.
> The other thought Terrence had was the use of #
> as the directive character. Would this interfere
> with XML in some way, or does it already. Maybe
> this is already the best choice, but maybe
> there is a better one? Any thoughts or suggestions.
> I personally like the #.
You really should read the WM archives. I come from an SGML/XML
background, # was chosen because it is not used in XML.
Justin
Re: Notes on WM and Velocity
Posted by Leon Messerschmidt <le...@opticode.co.za>.
<snip>
> The other thought Terrence had was the use of #
> as the directive character. Would this interfere
> with XML in some way, or does it already. Maybe
> this is already the best choice, but maybe
> there is a better one? Any thoughts or suggestions.
> I personally like the #.
<snip>
We've used WM quite heavily with XML and never had a problem with #. You should
only find problems with the five built-in entities & ' " > <
FWIW, I also like the #
~ Leon
Re: Notes on WM and Velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 4 Sep 2000, Jason van Zyl wrote:
> Hello,
>
> I've been doing some design work, looking over the WM source,
> and talking a lot with Terrence Parr (Antlr dude). Here are
> some of the things I have found:
My apologies to Terence (not Terrence). He corrected
me once already. I'm sorry.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Notes on WM and Velocity
Posted by Jason van Zyl <jv...@periapt.com>.
Hello,
I've been doing some design work, looking over the WM source,
and talking a lot with Terrence Parr (Antlr dude). Here are
some of the things I have found:
WM Parser and Introspection Engine
----------------------------------
I think everyone would definitely agree that the
current parser in WM has some problems. I think
it is generally accepted that tools like JavaCC,
or Antlr are the best approach: the actual grammar
file is fairly short and succinct. And there
are many people who have some familiarity with
these tools. I think adding features to the
current WM parser would be a lot harder then
tinkering with a small grammar and letting the
parser generator do the work. And for the
most part directives could be made configurable
if designed by adding a simple rule to the
grammar and generic processing to the
visitors, or self walking ASTs.
Now Justin has mentioned that the WM parser is pluggable,
and yes this is true and you could plug in a
new parser but this begs the question: where do
the results of parsing go next?
What I have gleaned from looking over the WM source
is that the introspection engine of WM is tied
heavily into the behaviour of the parser. By this
I mean that the limitations of the parser, in that
it retains nothing of the semantics of references,
causes the introspection engine to do a lot of
work that isn't necessary. Let me illustrate with
an example. We'll use this example of a reference:
(1)
$object.Foo.Bar.getItem("param1", "param2").Price
The WM parser takes this and creates the following
to pass into the introspection engine:
(2)
{ "Foo", "Bar", "getItem", "param1", "param2", "Price" }
Using $object found in the context as the root of introspection.
What has happened here is that all semantic information
has been lost (or what is more true is that the WM parser
never found it in the first place), and the WM introspection
engine uses a brute force approach to figure out what
the original signature of (1) was. Well, we can tell by
looking at it what the signature is. And so can a
parser that has been constructed correctly.
What you should end up with is something like the
following:
(3)
Property -- Foo
|
Property -- Bar
|
Method -- getItem
| |
| "param1" -- "param2"
|
Property -- Price
This isn't an exact representation but you get the idea:
the semantic information is kept intact in the AST
resulting from the parse. With this structure there
is no searching for the right signature. You already
know what it is.
Knowing what the signature is will save time
when using the reflection API. Instead
of collecting all the method names, and parameter
types for those methods and pounding through (2)
looking for a matching signature,
we just try and resolve getFoo because it is
a property. And if there is no getFoo then we
can safely report an error. Then we move through
the rest of the tree.
Now this time saved doesn't _really_ matter
if the end result is a compiled template (I'm
assuming WM compiles templates down into a class file).
But during development the execution
while debugging would be significantly less knowing
exactly what methods have to be invoked with
what parameters instead of having to hammer
through (2) every time the page is changed and tested.
But what is most important is that the introspection
engine in WM, which is roughly 1400 lines of
code, can probably be reduced to a tenth of
it's size resulting in a much cleaner and
easier to understand tool.
The WM introspection engine simply works
the way it does because the parsing mechanism
is deficient WRT to delivering useful semantic
information to the introspection engine.
So as far as I'm concerned the parser and
the introspection/reflection aspects of Velocity
should probably try to avoid this type
of parsing and introspection behaviour for
maximum performance and code clarity.
I certainly give credit to Justin for
getting where he did with the hand written
parser, it is a particularly nasty problem
WRT to extractly semantic info. I have a parser
working with JavaCC but it incorporates
a lot of lookahead. Incorporating a mechanism like
lookahead in a hand written parser
would be incredibly tedious, but appears
to be required to extract the semantic
info.
Possible Language Changes
-------------------------
I've been talking with Terrence Parr about how to
make the language as simple as possible and as
orthoginal as possible WRT all potential content
like XML and/or Javascript.
Here's a little example we came up with:
#if ($foo)
I am $foo!
#elseif ($bar)
I am $bar!
#else
I am not sure :(
#end
#foreach $element in $list
This is the $element!
#end
Here first of all we get rid of the {} pairs, they serve
no purpose other then a supplementary visual cue (eye candy)
and in removing them from the language we get a greater
degree of orthoginality with programming languages
that use {} pairs. JavaScript would no longer be a problem,
and unmatched "{" "}" wouldn't be a problem either.
Second there is a clear beginning and end to #directives.
Both visually and lexically. The #foreach and #end are clear
and would be trivial to lex into tokens. And therefore easy to
parse as a directive because there are clear
begin and end tokens (lexers parse characters
into tokens, parsers parse those tokens created
by the lexer).
The other thought Terrence had was the use of #
as the directive character. Would this interfere
with XML in some way, or does it already. Maybe
this is already the best choice, but maybe
there is a better one? Any thoughts or suggestions.
I personally like the #.
These are all suggestions, but it is probably
best to clean up any and all problems with the
WM template language now before there are
a vast number of users of WebMacro/Velocity :)
So right now I'm cleaning up the JavaCC version
of the parser, the first version didn't do
methods very well. This new version delivers the
correct semantic information. Next I'm going to
try a making a very small introspection engine
to work with what the parser produces. It should
be extremely compact and do everything that's
required.
That's all for now, any discussion is welcome.
If there are any aspects of my analysis that
are incorrect, please let me know.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: Summary of technical issues (long)
Posted by Jon Stevens <jo...@latchkey.com>.
Excellent write up Rafal!
on 9/4/2000 11:56 AM, "Rafal Krzewski" <Ra...@e-point.pl> wrote:
> 3) 'automagic' begin syntax
> #if $foo
> // something
> #end
>
> #if $foo
> // something
> #elseif $bar
> // somethig different
> #else
> // yet another thing
> #end
>
> 3.1) Pros
>
> 3.1.1) concise
>
> 3.1.2) more error proof (avoids missing/mismatched block markers)
>
> 3.2) Cons
>
> 3.2.1) Incompatibilie with WebMacro
I don't see this as entirely a con because Velocity's goal was never to be
100% syntax compatible with WM. The only goal that I think that Jason and I
laid out was to be able to use regex to convert old templates to new
templates. Given that it would be easy to simply regex through a template
and remove the {} and/or the #begin/#end, I don't see this as a con at all.
Some current users of WM who do not wish to change their syntax can also
certainly continue to stay with the current version of WM. People who want
to switch to or start with using Velocity can certainly do so as well. I
think that this choice is good for everyone and also doesn't tax our
available resources.
----------------------------------------------------------------------------
--> -
> 4) allowing multiple syntax options
>
> 4.1) Pros
>
> 4.1.1) Makes easier to upgrade from WM because existing templates work
>
> 4.2) Cons
>
> 4.2.1) Can result with bloated system
>
> 4.2.2) Using multiple inconsitent legacy templates simultaneously would
> require
> something like #syntax directive (ouch!)
The other con with this is support and I don't think we currently have
enough volunteers to support this from both a mailing list support POV as
well as a code POV. For now, I think that we should focus on just getting a
product with one language done with the expressed implication that in the
future we can support multiple languages in the parser easily. Then, people
who have that itch can volunteer to scratch it. Suggestions for the
different languages are useful, but unless you are going to actually do the
work, I doubt it will get done.
I also think that 20/20 hindsight will show that the language that we
develop for Velocity will be excellent because we are simply taking the
culmination of many years of experience and placing that into one location
without the associated baggage that goes along with developing a product
from scratch. That is very nice for once if you ask me. :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
RE: Summary of technical issues (long)
Posted by Malcolm Davis <ma...@nuearth.com>.
If velocity is just WebMacro for Tomcat, then keep it as is.
If velocity is appling concepts and ideas from WebMacro
and others, change it to be consitant with Java.
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@e-point.pl]
> Sent: Monday, September 04, 2000 1:57 PM
> To: velocity-user@jakarta.apache.org
> Subject: Summary of technical issues (long)
>
>
> Hello.
>
> I was away for the weekend, and now I find there is a serious flamewar
> going on. I'm not going to go into the issues of offending people, or
> giving users what they want vs. giving what is good for them.
>
> I tried to summarize main issues from technical point of view.
> Some of the points are gathered from the list, some are my own opinions.
> Note: I don't want to keep this thread running forever, I hope to help
> the developers to make a wise decision.
>
> ------------------------------------------------------------------
> -------------
> 1) curly brace syntax
>
> #if $foo {
> // something
> }
>
> 1.1) Pros
>
> 1.1.1) consistent with C and *Java*, which is nice for programers
> (Real Programers don't use Pascal, remember?)
>
> 1.1.2) concise (less typing)
>
> 1.2) Cons
>
> 1.2.1) can cause problems with JavaScript
> Velocity parser handles {} much better than WM parser, and
> will work correctly with JavaScript without any modification
> of the parser nor the js code. Velocity is counting opening
> and closing braces, therefore the following will work with
> no problems
>
> if() {
> // js block
> }
> #if () {
> // wm block
> }
>
> #if () {
> if() {
> #if() {
> while() {
> // and so on.
> // Velocity keeps track of which {} are which
> }
> }
> }
> }
>
> Notice that in a valid JS program, the number of opening and
> closing braces must match. Further, inside a web macro block
> the number of opening and closing braces must match also.
> Consider the following example:
>
> // some js code
> #if $condition {
> // some code with balanced braces
> } else {
> // some code with unbalanced braces
> }
> // some js code
>
> No matter what you put before and after the statement, this would
> generate invalid JS program in one of the cases.
>
> // some js code
> #foreach $obj in $list {
> // some code with unbalanced braces
> }
>
> Would generate invalid JS program if the list has any elements.
>
> My point here is: Don't put an unmatched brace inside Velocity
> block because it won't do any good.
>
> I managed to find a case where our approach would fail:
>
> if(something) {
> #foreach $condition in list {
> // do something
> } else if($condition) {
> }
>
> The braces appear in wrong order, therefore you would have
> to escape
> them, to make it work.
>
> There is another problem: When braces appear inside JS comments,
> they may be unblanced, and the progrm will still be valid.
>
> I think it's fair enough to require those unbalanced braces to
> be escaped, because it will happen rarely in real-life usage.
>
> 1.2.2) May be less obvius than begin/end for people with no programming
> background
>
> ------------------------------------------------------------------
> -------------
> 2) #begin/#end stntax
>
> #if $foo
> #begin
> // something
> #end
>
> 2.1) Pros
>
> 2.1.1) Is currently the default way of doing things in WebMacro
>
> 2.1.2) Is orthogonal to JavaScript, and most probably all other languages
> you would like to use in the templates (think templated Java code)
>
> 2.1.3) Looks consitent with other WebMacro special tokens (directives)
>
> 2.1.4) May be more obvious for non programers
>
> 2.2) Cons
>
> 2.2.1) sparse (more typing), makes templates look 'heavy'
>
> ------------------------------------------------------------------
> -------------
> 3) 'automagic' begin syntax
> #if $foo
> // something
> #end
>
> #if $foo
> // something
> #elseif $bar
> // somethig different
> #else
> // yet another thing
> #end
>
> 3.1) Pros
>
> 3.1.1) concise
>
> 3.1.2) more error proof (avoids missing/mismatched block markers)
>
> 3.2) Cons
>
> 3.2.1) Incompatibilie with WebMacro
>
> ------------------------------------------------------------------
> -------------
> 4) allowing multiple syntax options
>
> 4.1) Pros
>
> 4.1.1) Makes easier to upgrade from WM because existing templates work
>
> 4.2) Cons
>
> 4.2.1) Can result with bloated system
>
> 4.2.2) Using multiple inconsitent legacy templates simultaneously
> would require
> something like #syntax directive (ouch!)
> ------------------------------------------------------------------
> -------------
>
> Rafal
Summary of technical issues (long)
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Hello.
I was away for the weekend, and now I find there is a serious flamewar
going on. I'm not going to go into the issues of offending people, or
giving users what they want vs. giving what is good for them.
I tried to summarize main issues from technical point of view.
Some of the points are gathered from the list, some are my own opinions.
Note: I don't want to keep this thread running forever, I hope to help
the developers to make a wise decision.
-------------------------------------------------------------------------------
1) curly brace syntax
#if $foo {
// something
}
1.1) Pros
1.1.1) consistent with C and *Java*, which is nice for programers
(Real Programers don't use Pascal, remember?)
1.1.2) concise (less typing)
1.2) Cons
1.2.1) can cause problems with JavaScript
Velocity parser handles {} much better than WM parser, and
will work correctly with JavaScript without any modification
of the parser nor the js code. Velocity is counting opening
and closing braces, therefore the following will work with
no problems
if() {
// js block
}
#if () {
// wm block
}
#if () {
if() {
#if() {
while() {
// and so on.
// Velocity keeps track of which {} are which
}
}
}
}
Notice that in a valid JS program, the number of opening and
closing braces must match. Further, inside a web macro block
the number of opening and closing braces must match also.
Consider the following example:
// some js code
#if $condition {
// some code with balanced braces
} else {
// some code with unbalanced braces
}
// some js code
No matter what you put before and after the statement, this would
generate invalid JS program in one of the cases.
// some js code
#foreach $obj in $list {
// some code with unbalanced braces
}
Would generate invalid JS program if the list has any elements.
My point here is: Don't put an unmatched brace inside Velocity
block because it won't do any good.
I managed to find a case where our approach would fail:
if(something) {
#foreach $condition in list {
// do something
} else if($condition) {
}
The braces appear in wrong order, therefore you would have to escape
them, to make it work.
There is another problem: When braces appear inside JS comments,
they may be unblanced, and the progrm will still be valid.
I think it's fair enough to require those unbalanced braces to
be escaped, because it will happen rarely in real-life usage.
1.2.2) May be less obvius than begin/end for people with no programming
background
-------------------------------------------------------------------------------
2) #begin/#end stntax
#if $foo
#begin
// something
#end
2.1) Pros
2.1.1) Is currently the default way of doing things in WebMacro
2.1.2) Is orthogonal to JavaScript, and most probably all other languages
you would like to use in the templates (think templated Java code)
2.1.3) Looks consitent with other WebMacro special tokens (directives)
2.1.4) May be more obvious for non programers
2.2) Cons
2.2.1) sparse (more typing), makes templates look 'heavy'
-------------------------------------------------------------------------------
3) 'automagic' begin syntax
#if $foo
// something
#end
#if $foo
// something
#elseif $bar
// somethig different
#else
// yet another thing
#end
3.1) Pros
3.1.1) concise
3.1.2) more error proof (avoids missing/mismatched block markers)
3.2) Cons
3.2.1) Incompatibilie with WebMacro
-------------------------------------------------------------------------------
4) allowing multiple syntax options
4.1) Pros
4.1.1) Makes easier to upgrade from WM because existing templates work
4.2) Cons
4.2.1) Can result with bloated system
4.2.2) Using multiple inconsitent legacy templates simultaneously would require
something like #syntax directive (ouch!)
-------------------------------------------------------------------------------
Rafal
Re: benchmarking velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Sat, 2 Sep 2000, Jason Hunter wrote:
> > > Since the #begin and #end sytnax has been represented as the preferred syntax
> > > for WebMacro it probably should be supported. Note that in the
> > > current WM the {'s are considered legacy and can be turned off in
> > > the config file.
> >
> > Right, but WHY was it made the preferred syntax? As far as I can tell
> > (please correct me if I'm wrong), it was only because the parser couldn't
> > handle Javascript. Since Velocity handles Javascript without problems, this
> > isn't an issue.
>
> What was the answer to my (previously private) question about how
> Velocity can have an if block that includes only a "}" if the expression
> evals to true?
>
> if ($foo) {
> }
> }
>
> Is it just \} escaped? If so that makes including JavaScript very ugly.
No, the version in CVS won't handle an unmatched "}", it handles
JavaScript without escaping because it only consists of matched "{}".
I'm fixing the unmatched case in the parser I'm working on now.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: benchmarking velocity
Posted by Jason Hunter <jh...@collab.net>.
> > Since the #begin and #end sytnax has been represented as the preferred syntax
> > for WebMacro it probably should be supported. Note that in the
> > current WM the {'s are considered legacy and can be turned off in
> > the config file.
>
> Right, but WHY was it made the preferred syntax? As far as I can tell
> (please correct me if I'm wrong), it was only because the parser couldn't
> handle Javascript. Since Velocity handles Javascript without problems, this
> isn't an issue.
What was the answer to my (previously private) question about how
Velocity can have an if block that includes only a "}" if the expression
evals to true?
if ($foo) {
}
}
Is it just \} escaped? If so that makes including JavaScript very ugly.
-jh-
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 11:45 AM, "Justin Wells" <jr...@semiotek.com> wrote:
> Since the #begin and #end sytnax has been represented as the preferred syntax
> for WebMacro it probably should be supported. Note that in the
> current WM the {'s are considered legacy and can be turned off in
> the config file.
Right, but WHY was it made the preferred syntax? As far as I can tell
(please correct me if I'm wrong), it was only because the parser couldn't
handle Javascript. Since Velocity handles Javascript without problems, this
isn't an issue.
> Velocity could reverse that decision
We already have, right? :-)
>, but should probably support users who
> rewrote their templates in the recommended way.
The support will be through a regex class or a set of documentation that
describes what needs to change between products. For example, I wrote this
document for JServ...
<http://java.apache.org/jserv/upgrade.html>
It details the differences and changes. I didn't get one single complaint.
> One useful approach would be to have a "LEGACY=true" setting in the config
> file that turns on some behavior that a lot of people use but which you
> intend to drop. That behavior could then disapper completely in a 3.0
> release.
I would be against that as it is to much flexibility.
A joke: Should we also include a JSP=true parser as well to support all
those legacy JSP pages? :-)
> On the other hand:
>
>> #set foo = "bar"
>
> This is dumb, it should really be $foo and other uses can be considered
> to be deprecated in WebMacro. I don't have any objection to fixing this
> one in the 1.0 WebMacro.
As I said, it is already fixed in Velocity.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
Since the #begin and #end sytnax has been represented as the preferred syntax
for WebMacro it probably should be supported. Note that in the
current WM the {'s are considered legacy and can be turned off in
the config file.
Velocity could reverse that decision, but should probably support users who
rewrote their templates in the recommended way.
One useful approach would be to have a "LEGACY=true" setting in the config
file that turns on some behavior that a lot of people use but which you
intend to drop. That behavior could then disapper completely in a 3.0
release.
On the other hand:
> #set foo = "bar"
This is dumb, it should really be $foo and other uses can be considered
to be deprecated in WebMacro. I don't have any objection to fixing this
one in the 1.0 WebMacro.
Justin
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 5:38 AM, "Marc Palmer" <ma...@anyware.co.uk> wrote:
> It may not be needed per se, but to maintain an upgrade path from WM it
> would be essential. I use #begin...#end everywhere because I like the
> clarity it affords and the confusion it avoids. Having to change every
> template we have would be a no-no.
It would be VERY easy to write a regex or do a find/replace in all your
documents that change #begin -> { and #end -> }. It isn't a no no to break
compatibility in ways that can be easily fixed. There are several minor
differences between WM and Velocity that are being documented on the website
already. For example, #set is now like this:
#set $foo = "bar"
instead of
#set foo = "bar"
This is something that Justin even agreed on when we were talking when we
met in person. The point of Velocity is to clean up the cruft that WM is
legacy stuck with and also why it will be a 2.0 instead of a 1.0. It gives
us the chance to make those changes.
> In my experience it's programmers who like "simpler" syntax like { and },
> and other people (such as HTML authors) prefer things a little more
> "english" like #begin...#end. It's the old Pascal vs. C syntax thing and
> I know it's a pain typing begin and end but people should have the
> choice, as they do now in WebMacro.
Ok, we can put it up for a vote. But my argument that you are going to have
to beat is that #begin and #end were only fairly recent additions to WM and
were really only added because the parser sucks, not because it was easier
on designers.
thanks,
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Marc Palmer <ma...@anyware.co.uk>.
------ Original Message ------
On 01/09/00, 08:17:59, Jon Stevens <jo...@latchkey.com> wrote regarding Re:
benchmarking velocity:
> on 9/1/2000 12:22 AM, "Justin Wells" <jr...@semiotek.com> wrote:
> > I was only able to get it to work with the #foreach loops removed.
> I don't think that velocity supports the #begin/#end syntax that is used
in
> your #foreach statement in the file. It just isn't needed with Velocity
> since {} works.
It may not be needed per se, but to maintain an upgrade path from WM it
would be essential. I use #begin...#end everywhere because I like the
clarity it affords and the confusion it avoids. Having to change every
template we have would be a no-no.
In my experience it's programmers who like "simpler" syntax like { and },
and other people (such as HTML authors) prefer things a little more
"english" like #begin...#end. It's the old Pascal vs. C syntax thing and
I know it's a pain typing begin and end but people should have the
choice, as they do now in WebMacro.
Cheers
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/1/2000 12:22 AM, "Justin Wells" <jr...@semiotek.com> wrote:
> I was only able to get it to work with the #foreach loops removed.
I don't think that velocity supports the #begin/#end syntax that is used in
your #foreach statement in the file. It just isn't needed with Velocity
since {} works.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
Jason,
I've attached the template that causes the trouble. It has a lot
of weird {'s in it so that may be causing the problem. If you can
get it working that would be great, since this is the page that
I'm always benchmarking these days--I know exactly what kind of
performance I can get out of this one. (You'll realize why once
you see what it is.)
I was only able to get it to work with the #foreach loops removed.
I'm gonna be back in Toronto all week next week, I'd like to hook
up with you either there or in Guelph and go out and have dinner
or something. I'll be back in Palo Alto again the week after
that so we should decide pretty soon when/where would be good.
I'll send you my cell# in private email if you don't have it.
Also, I've opened up WM to take on core developers and you're
welcome to join the project if you like. We might as well start
working together now :-)
Justin
ps: I don't mind posting the page to the list, the secret is
basically out already, but you probably ought not to include
this exact HTML in your distribution testbed.
Re: benchmarking velocity
Posted by Jason van Zyl <jv...@periapt.com>.
No problem, you're probably the first person to
try and run a web benchmark. That's good! We'll
see what Dave's up to and we'll try and get
a decent setup going in the next little while.
jvz.
On Thu, 31 Aug 2000, Justin Wells wrote:
> By the way, I am honestly trying to run a fair benchmark so
> I want to get it set up right. I have not posted anything
> about this to the WM list because I'm sure that I've got
> something set up incorrectly and I don't want to do anything
> that would look like FUD.
>
> I should probably use an alias since, given who I am, you
> probably think I am just being difficult but I really want
> to get this running properly.
>
> Justin
>
>
> On Thu, Aug 31, 2000 at 06:09:46AM -0400, Justin Wells wrote:
> >
> > I tried to benchmark velocity but I didn't get very far.
> >
> > First, I had to remove the #foreach directives from my
> > templates. Velocity reported some kind of parsing error
> > so long as they remained in the template, complaining
> > that it still expected to see something when it reached
> > the end of the file. I'm not sure why. The templates
> > contained fairly complex HTML so I figured there must
> > be something confusing Velocity there.
> >
> > Anyway, I removed the #foreach directives and continued
> > on trying to benchmark. Velocity worked at this point, but
> > it didn't work very well.
> >
> > I was able to view the page in my browser, but every time
> > I tried to hammer it with Apache Benchmark it got really
> > unhappy. A couple of times I got Out of Memory errors, and
> > Apache Benchmark reports lots of bad connections.
> >
> > I think I must be using it wrong. Any ideas what happened?
> >
> > Justin
> >
> >
>
--
Jason van Zyl
jvanzyl@periapt.com
Re: benchmarking velocity
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/31/2000 3:18 AM, "Justin Wells" <jr...@semiotek.com> wrote:
> I should probably use an alias since, given who I am, you
> probably think I am just being difficult but I really want
> to get this running properly.
>
> Justin
I don't think it is constructive to make statements like this. We (at least
I) are not going to assume the worst first. Asking why a benchmark is
failing isn't "being difficult".
Although, this is the user list so you should probably be posting to the
development list since this is a development issue, not a user issue.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
By the way, I am honestly trying to run a fair benchmark so
I want to get it set up right. I have not posted anything
about this to the WM list because I'm sure that I've got
something set up incorrectly and I don't want to do anything
that would look like FUD.
I should probably use an alias since, given who I am, you
probably think I am just being difficult but I really want
to get this running properly.
Justin
On Thu, Aug 31, 2000 at 06:09:46AM -0400, Justin Wells wrote:
>
> I tried to benchmark velocity but I didn't get very far.
>
> First, I had to remove the #foreach directives from my
> templates. Velocity reported some kind of parsing error
> so long as they remained in the template, complaining
> that it still expected to see something when it reached
> the end of the file. I'm not sure why. The templates
> contained fairly complex HTML so I figured there must
> be something confusing Velocity there.
>
> Anyway, I removed the #foreach directives and continued
> on trying to benchmark. Velocity worked at this point, but
> it didn't work very well.
>
> I was able to view the page in my browser, but every time
> I tried to hammer it with Apache Benchmark it got really
> unhappy. A couple of times I got Out of Memory errors, and
> Apache Benchmark reports lots of bad connections.
>
> I think I must be using it wrong. Any ideas what happened?
>
> Justin
>
>
Re: benchmarking velocity
Posted by Jason van Zyl <jv...@periapt.com>.
On Thu, 31 Aug 2000, Justin Wells wrote:
>
> I tried to benchmark velocity but I didn't get very far.
>
> First, I had to remove the #foreach directives from my
> templates.
#foreach $item in [ ... ]
in your templates possibly. I haven't put that in
the parser yet.
> Velocity reported some kind of parsing error
> so long as they remained in the template, complaining
> that it still expected to see something when it reached
> the end of the file. I'm not sure why. The templates
> contained fairly complex HTML so I figured there must
> be something confusing Velocity there.
Can I see the templates? Just mail them to me. There are
things still not implemented, but I'll take everything
that broke and stick it in the testbed.
> Anyway, I removed the #foreach directives and continued
> on trying to benchmark. Velocity worked at this point, but
> it didn't work very well.
I have only run tests just straight parsing. Haven't
looked at the servlet. Dave is working on that, and
he's waiting for me to implement some things. And he's
turned the caching off, again he's waiting for me to
fix things in the parser.
> I was able to view the page in my browser, but every time
> I tried to hammer it with Apache Benchmark it got really
> unhappy. A couple of times I got Out of Memory errors, and
> Apache Benchmark reports lots of bad connections.
That's what you get for four weeks of the block :)
> I think I must be using it wrong.
Probably not. I'm focusing on the parser right now (this
is the third incarnation of the parser). But I'll look
at the templates.
Any ideas what happened?
Note sure. Probably a combo of unimplemented directives
and some unimplemented syntax. I'm actually surprise it even sort
of worked in your browser! I'll be working on the parser
tomorrow so the best thing is to send the template and
I'll keep at it.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
RE: benchmarking velocity
Posted by Malcolm Davis <ma...@nuearth.com>.
Benchmark?
That's an interesting concept.
I was taught to get it running first,
worry about performance later.
Performance is one of those things
you can always make better, look at the JVM's. :)
> -----Original Message-----
> From: Justin Wells [mailto:jread@semiotek.com]
> Sent: Thursday, August 31, 2000 5:10 AM
> To: velocity-user@jakarta.apache.org
> Subject: benchmarking velocity
>
>
>
> I tried to benchmark velocity but I didn't get very far.
>
> First, I had to remove the #foreach directives from my
> templates. Velocity reported some kind of parsing error
> so long as they remained in the template, complaining
> that it still expected to see something when it reached
> the end of the file. I'm not sure why. The templates
> contained fairly complex HTML so I figured there must
> be something confusing Velocity there.
>
> Anyway, I removed the #foreach directives and continued
> on trying to benchmark. Velocity worked at this point, but
> it didn't work very well.
>
> I was able to view the page in my browser, but every time
> I tried to hammer it with Apache Benchmark it got really
> unhappy. A couple of times I got Out of Memory errors, and
> Apache Benchmark reports lots of bad connections.
>
> I think I must be using it wrong. Any ideas what happened?
>
> Justin
>
>
benchmarking velocity
Posted by Justin Wells <jr...@semiotek.com>.
I tried to benchmark velocity but I didn't get very far.
First, I had to remove the #foreach directives from my
templates. Velocity reported some kind of parsing error
so long as they remained in the template, complaining
that it still expected to see something when it reached
the end of the file. I'm not sure why. The templates
contained fairly complex HTML so I figured there must
be something confusing Velocity there.
Anyway, I removed the #foreach directives and continued
on trying to benchmark. Velocity worked at this point, but
it didn't work very well.
I was able to view the page in my browser, but every time
I tried to hammer it with Apache Benchmark it got really
unhappy. A couple of times I got Out of Memory errors, and
Apache Benchmark reports lots of bad connections.
I think I must be using it wrong. Any ideas what happened?
Justin
Re: Re[6]: parser technology
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/31/2000 1:13 AM, "Andrew (Tver)" <a...@etver.com> wrote:
> Usually I have no any problems with my ISP :-)
ok, here is two from totally different networks. it makes it through, but
that last hop isn't real friendly.
traceroute to 199.182.58.1 (199.182.58.1), 30 hops max, 40 byte packets
1 pile-drivers-dock-wharf-builders-union-local-34.collab.net
(63.211.145.1) 0.292 ms 0.201 ms 0.171 ms
2 collab-gate.collab.net (209.246.26.177) 0.414 ms 0.388 ms 0.543 ms
3 gigaethernet5-0.core1.SanFrancisco1.Level3.net (209.244.14.41) 0.439 ms
0.457 ms 0.390 ms
4 so-4-0-0.mp1.SanFrancisco1.level3.net (209.247.10.225) 0.769 ms 0.735
ms 0.717 ms
5 209.247.8.226 (209.247.8.226) 2.275 ms 2.281 ms 2.254 ms
6 209.247.11.6 (209.247.11.6) 2.010 ms 2.526 ms 1.987 ms
7 pos3-0-0.edge1.fix-west1.level3.net (209.244.3.182) 3.069 ms 3.029 ms
3.046 ms
8 mae-west.netcom.net (198.32.136.15) 4.167 ms 4.354 ms 4.625 ms
9 p9-0-0.sji-ca-gw1.icg.net (163.179.136.21) 4.983 ms 4.271 ms 4.459 ms
10 h2-0.hay-ca-gw1.icg.net (165.236.177.94) 7.621 ms 8.070 ms 7.412 ms
11 hay-ca-gw2.icg.net (163.179.191.9) 8.535 ms 8.289 ms 7.983 ms
12 gw.internet-is.com (199.182.58.1) 14.293 ms !X * 14.764 ms !X
traceroute: Warning: Multiple interfaces found; using 205.227.191.15 @ hme0
traceroute to 199.182.58.1 (199.182.58.1), 30 hops max, 40 byte packets
1 cr1-fe0-0.wc-ca.clearink.net (205.227.191.2) 1.010 ms 0.815 ms 0.773
ms
2 * gw1-inet-e0.wc-ca.clearink.net (205.227.191.1) 2.824 ms 2.988 ms
3 s12-0-0-20-0.oakland-cr2.bbnplanet.net (4.0.71.77) 17.093 ms 72.426 ms
129.181 ms
4 f0-0.oakland-br2.bbnplanet.net (4.0.16.17) 5.330 ms 25.317 ms 5.179
ms
5 h3-0.sanjose1-br1.bbnplanet.net (4.0.6.129) 6.175 ms 6.468 ms 6.124
ms
6 p2-0.sanjose1-nbr1.bbnplanet.net (4.0.3.193) 6.854 ms 12.733 ms 6.943
ms
7 mae-west-atm-gtei.netcom.net (4.24.145.34) 7.074 ms 7.116 ms 6.861 ms
8 p9-0-0.sji-ca-gw1.icg.net (163.179.136.21) 7.100 ms 7.457 ms 7.204 ms
9 h2-0.hay-ca-gw1.icg.net (165.236.177.94) 11.635 ms 9.769 ms 9.885 ms
10 hay-ca-gw2.icg.net (163.179.191.9) 11.798 ms 11.171 ms 10.475 ms
11 gw.internet-is.com (199.182.58.1) 16.891 ms !X * 30.147 ms !X
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/