You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Victor Salaman <vs...@hotmail.com> on 2001/12/06 00:20:14 UTC

Redundancy...Struts/Velocity integration

I don't usually rant about discussions which seem to have no merit but here 
it goes...

My opinion is that if Struts wants to integrate to Velocity, it should be 
done in the struts side, not on the velocity side... Velocity is a generic 
templating system (and I stress 'System' and not 'Engine'). So why should 
Velocity be bloated with this stuff...

I've recently seen on the lists proposals to do very insane things and add 
them to the core. Please don't.

Not to be rude, but in many circles, Apache is known for being the Microsoft 
of open source. In other words, take a perfectly good running project that 
gets donated to them, bloat it to the point of making it unusable. This is 
not my opinion of course, otherwise I would not be here.... but recent 
happenings kind of explain that believe.

There are a few projects that don't manifest this feature, and velocity is 
one of them... It's a simple system that doesn't try to do everything for 
everyone, it's fast and easy to learn.

I just don't see why people need to integrate stuff to the core, and not 
just make external plugins to velocity....

I have been following the "Struts/Velocity" integration and I have to admit 
that I had not laughed so hard in quite a while, from the solutions some of 
the people have proposed.

The reallity is that Velocity doesn't need to make hacks to integrate to 
Struts, but the other way around...

... for example ...

I come from a jsp background... and in jsp you have the concept of 
bodycontent.. We have achieved some nice stuff like Caching and Decoration 
tags in projects such as OSCache and OSSitemesh (www.opensymphony.com) ... 
For this reason I always avoided velocity like the plague because i had 
stuff that depended on all this advanced behaviour...

I was always upset with velocity since it didn't let me do what I wanted.. I 
said "I needed to modify the core" , so I opened up the source, and then I 
saw that I could just create userdirectives!

So I wrote two directives, #decorate and #cache ...

so I can do

#cache('time=3600')
#decorate('panel')
<sitemesh-property name="width" value="200">
<html>
<head>
<title>This is a panel</title>
<body>
This is the body of my panel..
$fetchFromDBSomeData()
</body>
</html>
#end
#end

This will efectively create a panel for me with all the layout from a 
template called "panel", and it will be cached for an hour...

I could have just said "Let me write a proposal for Velocity to make it look 
more like jsp" ... but I extended velocity outside the box, and it came out 
better...

.....

<rant>
instead of trying to copy features from webwork and putting them in the 
core, let's USE webwork :) after all , webwork is not a templating system 
and velocity is not a web framework.
</rant>

<rant>
Why try to integrate heaven and hell together? -- Let the lower dungeons of 
hell take care of the infidels.
</rant>

<evil-rant>
Whoever is still using Struts, has not used webwork, or is an XXXXXX lapdog. 
:)
</evil-rant>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Redundancy...Struts/Velocity integration

Posted by Rickard Öberg <ri...@xpedio.com>.
Victor Salaman wrote:

> So I wrote two directives, #decorate and #cache ...
> 
> so I can do
> 
> #cache('time=3600')
> #decorate('panel')
> <sitemesh-property name="width" value="200">
> <html>
> <head>
> <title>This is a panel</title>
> <body>
> This is the body of my panel..
> $fetchFromDBSomeData()
> </body>
> </html>
> #end
> #end

Excellent! Is this in OSCache/SiteMesh now??

/R

-- 
Rickard Öberg


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Redundancy...Struts/Velocity integration

Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 12/5/01 6:20 PM, "Victor Salaman" <vs...@hotmail.com> wrote:

> I don't usually rant about discussions which seem to have no merit but here
> it goes...
> 
> My opinion is that if Struts wants to integrate to Velocity, it should be
> done in the struts side, not on the velocity side... Velocity is a generic
> templating system (and I stress 'System' and not 'Engine'). So why should
> Velocity be bloated with this stuff...
> 
> I've recently seen on the lists proposals to do very insane things and add
> them to the core. Please don't.
> 
> Not to be rude, but in many circles, Apache is known for being the Microsoft
> of open source. In other words, take a perfectly good running project that
> gets donated to them, bloat it to the point of making it unusable. This is
> not my opinion of course, otherwise I would not be here.... but recent
> happenings kind of explain that believe.
> 

I don't think you have been actually reading.

There will be *no* new code in velocity for this.  It *is* a struts thing,
but we are interested here so this community is going to do it with the help
of interested people in the Struts community.

Development seems to be going to be hosted at sourceforge (which should give
you the hint that its not here...)

> There are a few projects that don't manifest this feature, and velocity is
> one of them... It's a simple system that doesn't try to do everything for
> everyone, it's fast and easy to learn.
> 

And it wont.

> I just don't see why people need to integrate stuff to the core, and not
> just make external plugins to velocity....
> 
> I have been following the "Struts/Velocity" integration and I have to admit
> that I had not laughed so hard in quite a while, from the solutions some of
> the people have proposed.
> 
> The reallity is that Velocity doesn't need to make hacks to integrate to
> Struts, but the other way around...

I don¹t think anyone has suggested that anything be added to the core.  If
they did, I missed it, because I would have put the kibosh on that
immediately.
 
> ... for example ...
> 
> I come from a jsp background... and in jsp you have the concept of
> bodycontent.. We have achieved some nice stuff like Caching and Decoration
> tags in projects such as OSCache and OSSitemesh (www.opensymphony.com) ...
> For this reason I always avoided velocity like the plague because i had
> stuff that depended on all this advanced behaviour...
> 
> I was always upset with velocity since it didn't let me do what I wanted.. I
> said "I needed to modify the core" , so I opened up the source, and then I
> saw that I could just create userdirectives!
> 
> So I wrote two directives, #decorate and #cache ...
> 
> so I can do
> 
> #cache('time=3600')
> #decorate('panel')
> <sitemesh-property name="width" value="200">
> <html>
> <head>
> <title>This is a panel</title>
> <body>
> This is the body of my panel..
> $fetchFromDBSomeData()
> </body>
> </html>
> #end
> #end
> 
> This will efectively create a panel for me with all the layout from a
> template called "panel", and it will be cached for an hour...
> 
> I could have just said "Let me write a proposal for Velocity to make it look
> more like jsp" ... but I extended velocity outside the box, and it came out
> better...
> 
> .....
> 
> <rant>
> instead of trying to copy features from webwork and putting them in the
> core, let's USE webwork :) after all , webwork is not a templating system
> and velocity is not a web framework.
> </rant>
> 
> <rant>
> Why try to integrate heaven and hell together? -- Let the lower dungeons of
> hell take care of the infidels.
> </rant>
> 
> <evil-rant>
> Whoever is still using Struts, has not used webwork, or is an XXXXXX lapdog.
> :)
> </evil-rant>
> 
> 

Ok...

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>