You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Jason van Zyl <jv...@periapt.com> on 2000/08/29 08:27:35 UTC
Re: WebMacro code integration
On Mon, 28 Aug 2000, Daniel L. Rall wrote:
> I don't think that the current WebMacro code base itself has a great
> deal to offer to Velocity. It's been over engineered. I hope Justin
> decides to contribute his experience to the design ideas that we're
> currently discussing, but I would like to recommend that we don't try to
> emulate the design used in WebMacro--it's more convoluted than it needs
> to be.
I agree, there are bits that I might like to use, and I think
it would take a couple of days to pull them out and
stick them into Velocity. But for the most part I
don't think there's much in there I'm keen on using
anyway.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: WebMacro code integration
Posted by "Daniel L. Rall" <dl...@collab.net>.
Rafal Krzewski wrote:
>
> "Daniel L. Rall" wrote:
> > I'm not at all in favor of that service provider framework it's got
> > going on--it's a *templating* engine, right? Let's keep Velocity
> > focused on templating, and leave things like a resource provider
> > framework in Turbine (where they belong).
>
> Yeah, InfoBus framework that is present in WebMacro is totally unrelated
> to template generation. Velocity will do just fine without it from
> our (Turbine) perspective. On the other hand some of "Mr. Wells' clients"
> that could be using that are using WM as all-around servlet framework
> may depend on that. Removing it would disqualify Velocit as drop-in replacement
> for WebMacro. Of course it's bad that two unrelated (albeit nice) things
> were stuck into single software package in the first place...
>
> My vote is to leave InfoBus (Broker/Provider) architecture out of Velocity.
> If someone is interested in it, they could fork another project from WM.
They can always use Turbine + Velocity. ;)
--
Daniel Rall <dl...@collab.net>
http://collab.net/ | open source | do the right thing
Re: WebMacro code integration
Posted by Rafal Krzewski <Ra...@e-point.pl>.
"Daniel L. Rall" wrote:
> I'm not at all in favor of that service provider framework it's got
> going on--it's a *templating* engine, right? Let's keep Velocity
> focused on templating, and leave things like a resource provider
> framework in Turbine (where they belong).
Yeah, InfoBus framework that is present in WebMacro is totally unrelated
to template generation. Velocity will do just fine without it from
our (Turbine) perspective. On the other hand some of "Mr. Wells' clients"
that could be using that are using WM as all-around servlet framework
may depend on that. Removing it would disqualify Velocit as drop-in replacement
for WebMacro. Of course it's bad that two unrelated (albeit nice) things
were stuck into single software package in the first place...
My vote is to leave InfoBus (Broker/Provider) architecture out of Velocity.
If someone is interested in it, they could fork another project from WM.
Rafal
Re: WebMacro code integration
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> On Mon, 28 Aug 2000, Daniel L. Rall wrote:
>
> > I don't think that the current WebMacro code base itself has a great
> > deal to offer to Velocity. It's been over engineered. I hope Justin
> > decides to contribute his experience to the design ideas that we're
> > currently discussing, but I would like to recommend that we don't try to
> > emulate the design used in WebMacro--it's more convoluted than it needs
> > to be.
>
> I agree, there are bits that I might like to use, and I think
> it would take a couple of days to pull them out and
> stick them into Velocity. But for the most part I
> don't think there's much in there I'm keen on using
> anyway.
Okay, good. :)
I'm not at all in favor of that service provider framework it's got
going on--it's a *templating* engine, right? Let's keep Velocity
focused on templating, and leave things like a resource provider
framework in Turbine (where they belong).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: #while directive
Posted by Frank Conradie <fr...@opticode.co.za>.
> It's just a negated #if:
>
> #set $isFrobbing = false
> #unless ($isFrobbing)
> {
> El queso es verde y mouldy.
> }
>
> Shows:
>
> El queso es verde y mouldy.
>
>
> I think it reads better than:
> #if (! $isFrobbing)
> {
> ...
> }
>
> But that's just my opinion.
Yes please! And while we're busy "demanding" stuff ;-) - I could REALLY use
some kind of a case/switch thingy - nested if's suck! I know we have to keep
the templating simple, but just in case you want to discuss this.
Frank
Re: thread safety
Posted by Jason van Zyl <jv...@periapt.com>.
On Tue, 29 Aug 2000, dave wrote:
> On Tue, 29 Aug 2000, you wrote:
> > I was looking at some of the code last night and a few thread safety
> > problems are in the code. I think jvz addressed their existence at some
> > point, but would it not be better to remove them early?
> >
> > e.g. things like:
> >
> > template.setContext(ctx)
> > template.parse()
> >
> > can easily be written as
> > template.parse(ctx)
> >
> > And other code will not get written that expects Template to have a Context
> > attribute.
> >
> > Another one is setting a VisitorProcessor in preParse. And then using it in
> > parse.
> >
>
> Yes John you are right. We talked about this a little over the weekend.
> My suggestion was to move the reference to context out of Template and
> Visitor and just pass the context trhough as you suggest. However there
> was other discussion about custom parsers etc...
>
> Jason - what's your thoughts about moving the context reference? Do you
> have another plan?
I haven't looked at yet, but I think Bob's thoughts were correct.
I think he has dealt with this in iSpock. I didn't
really pay much attention to thread saftey becasue there
is so little code and figured the context/template would
be reworked quite a bit anyway. But I'm thinking about
it now though!
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: thread safety
Posted by dave <da...@miceda-data.com>.
On Tue, 29 Aug 2000, you wrote:
> I was looking at some of the code last night and a few thread safety
> problems are in the code. I think jvz addressed their existence at some
> point, but would it not be better to remove them early?
>
> e.g. things like:
>
> template.setContext(ctx)
> template.parse()
>
> can easily be written as
> template.parse(ctx)
>
> And other code will not get written that expects Template to have a Context
> attribute.
>
> Another one is setting a VisitorProcessor in preParse. And then using it in
> parse.
>
Yes John you are right. We talked about this a little over the weekend.
My suggestion was to move the reference to context out of Template and
Visitor and just pass the context trhough as you suggest. However there
was other discussion about custom parsers etc...
Jason - what's your thoughts about moving the context reference? Do you
have another plan?
--
dave
daveb@miceda-data.com
----------------------
Re: thread safety
Posted by Jason van Zyl <jv...@periapt.com>.
On Tue, 29 Aug 2000, John McNally wrote:
> I was looking at some of the code last night and a few thread safety
> problems are in the code. I think jvz addressed their existence at some
> point, but would it not be better to remove them early?
>
> e.g. things like:
>
> template.setContext(ctx)
> template.parse()
>
> can easily be written as
> template.parse(ctx)
>
> And other code will not get written that expects Template to have a Context
> attribute.
>
> Another one is setting a VisitorProcessor in preParse. And then using it in
> parse.
Thanks! I'll take a look at that.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
thread safety
Posted by John McNally <jo...@clearink.com>.
I was looking at some of the code last night and a few thread safety
problems are in the code. I think jvz addressed their existence at some
point, but would it not be better to remove them early?
e.g. things like:
template.setContext(ctx)
template.parse()
can easily be written as
template.parse(ctx)
And other code will not get written that expects Template to have a Context
attribute.
Another one is setting a VisitorProcessor in preParse. And then using it in
parse.
John McNally
Re: user def directives
Posted by Jason van Zyl <jv...@periapt.com>.
On Tue, 29 Aug 2000, Daniel L. Rall wrote:
> Jason van Zyl wrote:
> >
> > And certainly limiting the creation of
> > directives will optimization easier.
> > That's one part of webmacro I'm not keen
> > on is the user defined directives. Although
> > for compatibility with WM it might be
> > necessary. Though I would like to do a
> > proper survey (We need a Turbine based
> > survey app!) or see if addition that people
> > have made can be accomodated with methods
> > or properties.
>
> I say to hell with user defined directives.
I honestly don't think they're very useful.
But I would like to support them for WM
users if it's a popular strategy. I would
really like to do a survey. If less then 20%
of WM users don't use that feature then I agree,
lets just ditch that idea. It just makes
debugging harder, and as a group how are
we really supposed to help with
#incorrectly_implemented_directive $busted
There's no point. Extend with macros not directives!
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: user def directives
Posted by "Daniel L. Rall" <dl...@collab.net>.
Jason van Zyl wrote:
>
> And certainly limiting the creation of
> directives will optimization easier.
> That's one part of webmacro I'm not keen
> on is the user defined directives. Although
> for compatibility with WM it might be
> necessary. Though I would like to do a
> proper survey (We need a Turbine based
> survey app!) or see if addition that people
> have made can be accomodated with methods
> or properties.
I say to hell with user defined directives.
--
Daniel Rall <dl...@collab.net>
http://collab.net/ | open source | do the right thing
Re: New directives vote
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Jason van Zyl wrote:
> #unless
+1 can make certain constructs much cleaner
> #while
-1 little use in templates
> #if/#elseif/#else
+1 saves a lot of nested ifs
> #switch ($var)
> {
> #case 1
> {
> }
> #case 2
> {
> }
> }
-1 too complicated, can be handled fine by chained
#if #elseif #elseif #elseif #else (wolud that
work?)
Rafal
Re: New directives vote
Posted by Tomasz Skutnik <sc...@e-point.pl>.
>
> #unless
>
-1
> #while
>
no opinion
> #if/#elseif/#else
>
+1
> #switch ($var)
> {
> #case 1
> {
> }
> #case 2
> {
> }
> }
-1 #if/#elsif/#else is good enough
Scooter
Re: New directives vote
Posted by Frank Conradie <fr...@opticode.co.za>.
> > #switch ($var)
> > {
> > #case 1
> > {
> > }
> > #case 2
> > {
> > }
> > }
>
> -1. same as first reason for #while.
Darn... serves me right for being a programmer doing web design :-( Back to
the (ugleeee) nested if/then's for me ;-)
Frank
Re: New directives vote
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/29/2000 11:57 AM, "Daniel L. Rall" <dl...@collab.net> wrote:
> Yeah, as much as I like these directives, perhaps they don't really have
> a place in this context. ;P
exactly. we need to put ourselves in the shoes of a non-programmer when
thinking about new directives for velocity. think in terms of the reason why
we chose velocity over other tools like JSP and Tea...we don't want to give
people the gun (the tool) and bullets (the language syntax) to shoot
themselves in the foot.
the whole point of these MVC tools is that we are not the ones working on
the templates, it is the non-programmers who are working on them. lets do
what we do best...write java code and let the non-programmers do their jobs.
-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: New directives vote
Posted by "Daniel L. Rall" <dl...@collab.net>.
Jon Stevens wrote:
>
> on 8/29/2000 10:56 AM, "Jason van Zyl" <jv...@periapt.com> wrote:
>
> > #unless
>
> -1. This gets as confusing as the problem we are trying to solve:
>
> #unless (!$foo)
>
> > #while
>
> -1. to complex for web designers who are our primary target. we don't need
> anything more than #foreach.
>
> > #if/#elseif/#else
>
> +1
>
> > #switch ($var)
> > {
> > #case 1
> > {
> > }
> > #case 2
> > {
> > }
> > }
>
> -1. same as first reason for #while.
Yeah, as much as I like these directives, perhaps they don't really have
a place in this context. ;P
--
Daniel Rall <dl...@collab.net>
http://collab.net/ | open source | do the right thing
Re: New directives vote
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/29/2000 10:56 AM, "Jason van Zyl" <jv...@periapt.com> wrote:
> #unless
-1. This gets as confusing as the problem we are trying to solve:
#unless (!$foo)
> #while
-1. to complex for web designers who are our primary target. we don't need
anything more than #foreach.
> #if/#elseif/#else
+1
> #switch ($var)
> {
> #case 1
> {
> }
> #case 2
> {
> }
> }
-1. same as first reason for #while.
-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: New directives vote
Posted by Dave Bryson <da...@hot.useractive.com>.
dave
daveb@miceda-data.com
On Tue, 29 Aug 2000, Jason van Zyl wrote:
>
> #unless
>
> #while
>
> #if/#elseif/#else
>
> #switch ($var)
> {
> #case 1
> {
> }
> #case 2
> {
> }
> }
>
> (is that how you saw this leon?)
>
> Who wants these things. I'll work on them
> today if we can come to a decision. I'd
> like to get all possibly desired directives
> out of the way. Then I can start cleaning
> up the parser/visitors.
>
I like them all except #unless. I don't get
how you'd use it...
New directives vote
Posted by Jason van Zyl <jv...@periapt.com>.
#unless
#while
#if/#elseif/#else
#switch ($var)
{
#case 1
{
}
#case 2
{
}
}
(is that how you saw this leon?)
Who wants these things. I'll work on them
today if we can come to a decision. I'd
like to get all possibly desired directives
out of the way. Then I can start cleaning
up the parser/visitors.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: #while directive
Posted by Jason van Zyl <jv...@periapt.com>.
Thanks Bob!
jvz.
On Tue, 29 Aug 2000, bob wrote:
> > #elseif (not sure)
>
> fwiw, the way I've handled this in the past, is actually
> 1 level higher than the parser.
>
> Parse out #elseif just like any normal #if statement.
> You might end up with a block that looks like this, due
> to newlines (text) between the statements:
>
> #if()
> {
> }
> #elseif()
> {
> }
> #else
> {
> }
>
> Yields:
>
> Block
> IfStatement
> Text
> ElseifStatement
> Text
> ElseStatement
>
> Then, 'normalize' your tree, removinging any whitespace-only Text
> nodes between If/Elseif/Else nodes. And then normalize a 2nd pass
> to attach and Elseif/Else statements to the preceeding If/Elseif
> statement.
>
> Normalization needs to be recursive, because the IfStatement can certain
> contain more cascading IfStatements.
>
> Round 1 produces:
>
> Block
> IfStatement
> ElseifStatement
> ElseStatement
>
> Round 2 then gives you what you'd expect
>
> Block
> IfStatement -> ElseifStatement -> ElseStatement
>
> -bob
>
>
--
Jason van Zyl
jvanzyl@periapt.com
Re: #while directive
Posted by bob <bo...@accurev.com>.
> #elseif (not sure)
fwiw, the way I've handled this in the past, is actually
1 level higher than the parser.
Parse out #elseif just like any normal #if statement.
You might end up with a block that looks like this, due
to newlines (text) between the statements:
#if()
{
}
#elseif()
{
}
#else
{
}
Yields:
Block
IfStatement
Text
ElseifStatement
Text
ElseStatement
Then, 'normalize' your tree, removinging any whitespace-only Text
nodes between If/Elseif/Else nodes. And then normalize a 2nd pass
to attach and Elseif/Else statements to the preceeding If/Elseif
statement.
Normalization needs to be recursive, because the IfStatement can certain
contain more cascading IfStatements.
Round 1 produces:
Block
IfStatement
ElseifStatement
ElseStatement
Round 2 then gives you what you'd expect
Block
IfStatement -> ElseifStatement -> ElseStatement
-bob
Re: #while directive
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
Ok so we have
#while (easy to implement)
#unless (easy to implement)
#elseif (not sure)
What does everyone think of these. Do we want to
add these. The syntax will never be set in
stone, but if we get this sorted out then
we can really move ahead quickly.
And certainly limiting the creation of
directives will optimization easier.
That's one part of webmacro I'm not keen
on is the user defined directives. Although
for compatibility with WM it might be
necessary. Though I would like to do a
proper survey (We need a Turbine based
survey app!) or see if addition that people
have made can be accomodated with methods
or properties.
jvz.
Jason van Zyl
jvanzyl@periapt.com
Re: #while directive
Posted by John McNally <jo...@clearink.com>.
while your at it. I would like to speak up for #elseif. This construct is
not much more complicated than if-else. And it really cleans up some code
where you would have to nest conditionals.
I think a designer would have a much easier time sorting out/writing a
if-elseif-elseif-else than a
if
{
}
else
{
if
{
}
else
{
}
if
{
}
else
{
}
}
}
Who wants to play IRC!
Posted by Jason van Zyl <jv...@periapt.com>.
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: #while directive
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> On Mon, 28 Aug 2000, Daniel L. Rall wrote:
>
> > Jason van Zyl wrote:
> > >
> > > Hi,
> > >
> > > I'm playing around with the parser so I was thinking of
> > > adding #while.
> >
> > I like it.
> >
> > > How do we want this to work? Stictly evaluate to
> > > boolean values?
> >
> > Yeah...the #foreach directive already takes care of the only other case
> > that I could think of for that sort of pre-execution evaluation. While
> > you at it, I'm rather partial to #unless as well... ;)
>
> Can you give us some example?
It's just a negated #if:
#set $isFrobbing = false
#unless ($isFrobbing)
{
El queso es verde y mouldy.
}
Shows:
El queso es verde y mouldy.
I think it reads better than:
#if (! $isFrobbing)
{
...
}
But that's just my opinion.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: #while directive
Posted by Jason van Zyl <jv...@periapt.com>.
On Mon, 28 Aug 2000, Daniel L. Rall wrote:
> Jason van Zyl wrote:
> >
> > Hi,
> >
> > I'm playing around with the parser so I was thinking of
> > adding #while.
>
> I like it.
>
> > How do we want this to work? Stictly evaluate to
> > boolean values?
>
> Yeah...the #foreach directive already takes care of the only other case
> that I could think of for that sort of pre-execution evaluation. While
> you at it, I'm rather partial to #unless as well... ;)
Can you give us some example?
jvz.
--
Jason van Zyl
jvanzyl@periapt.com
Re: #while directive
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Jason van Zyl wrote:
>
> Hi,
>
> I'm playing around with the parser so I was thinking of
> adding #while.
I like it.
> How do we want this to work? Stictly evaluate to
> boolean values?
Yeah...the #foreach directive already takes care of the only other case
that I could think of for that sort of pre-execution evaluation. While
you at it, I'm rather partial to #unless as well... ;)
--
Daniel Rall <dl...@finemaltcoding.com>
#while directive
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
I'm playing around with the parser so I was thinking of
adding #while.
How do we want this to work? Stictly evaluate to
boolean values?
jvz.
--
Jason van Zyl
jvanzyl@periapt.com