You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Rickard Öberg <ri...@xpedio.com> on 2001/08/08 10:53:37 UTC
#include and servlets :-)
Dear WebWorkers,
(velocity-user in CC)
As I outlined in a post yesterday to the Velocity list it is essential
that the #include Velocity directive can handle servlet includes (i.e.
what the webwork:include JSP tag handles in WebWork today) so that
hierarchical MVC can be used.
I will outline an example to show why this is important. In a top page
one would have this:
<HTML>
<BODY>
<!-- Render page -->
<TABLE>
<TR><TD>
<!-- Menu -->
<#include "menu.action">
</TD></TR>
<TR><TD>
<!-- Input form or processing results -->
<#include "viewdata.action?">
</TD></TR>
<!-- Login name or login form -->
<TR><TD COLSPAN=2>
<#include "loginstatus.action">
</TD></TR>
</BODY>
</HTML>
--
Each of these actions have other .vm templates as Views, which in turn
may use #include to (re-)use other "components" (where component=action
class+set of template Views). This is where the hierarchical aspect
comes in.
"menu.action" will just have menu.vm as view. "viewdata.action" will
have either "viewdataform.vm" and "viewdataresults.vm" as view. Which
one is used is dependent on if proper input has been given to
viewdata.action (either directly through the URL query, or through the
form). "loginstatus.action" have templates as views that either show the
users name (if logged in) or a login form.
This general approach allows for arbitrarily complex pages that are
built up of components that are independent and can be reused on any
number of pages. If "cardpane.action" is used as the "main body" action
then there is also the case that there will only be one top template/JSP
for the entire application: what is shown in the main body depends on
what "card" is being displayed (see java.awt.CardLayout for the general
idea. same principle applies here).
So, this is cool stuff, but it requires #include to mimic servlet
includes, i.e. it must support #include "somepage.jsp" properly.
I have now implemented this by simply creating a new ResourceLoader,
called ServletResourceLoader. Instead of reading stuff from a file or
database as the current ones do, it will do a servlet include using
RequestDispatcher.include. The only tricky part was to create an
outputstream for the include that was buffered and then used as the
basis for the InputStream returned by the ResourceLoader. But it works
now anyway, and quite well too.
Since it uses WebWork specific stuff (to access the request/response) I
will put this in WebWork CVS, and I doubt that it is possible to make
this generic enough to put in Velocity CVS.
With this, and all the other goodness of WebWork, if you want to use
Velocity on the web I think WebWork will be the preferred way to do so.
In my very humble and biased opinion of course :-) Time will tell, as
usual.
regards,
Rickard
ps. Not yet in WebWork CVS, but will be soon. I'll ping the WebWork list
when it's done.
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: #include and servlets :-)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
>
> "Geir Magnusson Jr." wrote:
> > > As I outlined in a post yesterday to the Velocity list it is essential
> > > that the #include Velocity directive can handle servlet includes (i.e.
> > > what the webwork:include JSP tag handles in WebWork today) so that
> > > hierarchical MVC can be used.
> >
> > Why? I don't understand why you want to / have to effectively overload
> > the existing behavior of #include()
> >
> > Why not just make a tool that does it - $include.do("menu.action") ???
>
> Good point. I have now refactored the above code int the WebWorkUtil
> class instead, so to use it you write:
> $webwork.include("menu.action")
> or using the macro:
> #includeservlet("menu.action")
>
> Thanks for the idea. Of course this is how it should be.
That's excellent. I assume
#macro( includeservlet $foo )
$webwork.include( $foo )
#end
?
>
> > Er, there also is that thing called Turbine...
>
> Yes, that's one way to do it. I just expressed my humble opinion that I
> think WebWork will be/is a better tool to do similar things. :-)
I'll be in the bunker if you need me...
:)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: #include and servlets :-)
Posted by Rickard Öberg <ri...@xpedio.com>.
"Geir Magnusson Jr." wrote:
> > As I outlined in a post yesterday to the Velocity list it is essential
> > that the #include Velocity directive can handle servlet includes (i.e.
> > what the webwork:include JSP tag handles in WebWork today) so that
> > hierarchical MVC can be used.
>
> Why? I don't understand why you want to / have to effectively overload
> the existing behavior of #include()
>
> Why not just make a tool that does it - $include.do("menu.action") ???
Good point. I have now refactored the above code int the WebWorkUtil
class instead, so to use it you write:
$webwork.include("menu.action")
or using the macro:
#includeservlet("menu.action")
Thanks for the idea. Of course this is how it should be.
> Er, there also is that thing called Turbine...
Yes, that's one way to do it. I just expressed my humble opinion that I
think WebWork will be/is a better tool to do similar things. :-)
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: rickard@xpedio.com
Re: #include and servlets :-)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> Let me also point out that if you do decide to go down that route, you will
> be re-inventing the wheel. :-) Oh wait, you already are... :-)
I have dibs on 'fire(tm)'....
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: #include and servlets :-)
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/8/01 3:25 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> With this, and all the other goodness of WebWork, if you want to use
>> Velocity on the web I think WebWork will be the preferred way to do so.
>> In my very humble and biased opinion of course :-) Time will tell, as
>> usual.
>>
>
> Er, there also is that thing called Turbine...
Let me also point out that I think that Turbine's design with this regards
is a lot better. My biased opinion of course.
We already discussed this in detail on this list (or the -dev list) a few
months ago. Look for discussion on "layouts" in the archives.
Rickard, I highly suggest that you look into doing layouts Turbine's way. It
is better than simply emulating <jsp:include> which is a terrible kludge.
Let me also point out that if you do decide to go down that route, you will
be re-inventing the wheel. :-) Oh wait, you already are... :-)
-jon
Re: #include and servlets :-)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
>
> Dear WebWorkers,
>
> (velocity-user in CC)
>
> As I outlined in a post yesterday to the Velocity list it is essential
> that the #include Velocity directive can handle servlet includes (i.e.
> what the webwork:include JSP tag handles in WebWork today) so that
> hierarchical MVC can be used.
Why? I don't understand why you want to / have to effectively overload
the existing behavior of #include()
Why not just make a tool that does it - $include.do("menu.action") ???
> I will outline an example to show why this is important. In a top page
> one would have this:
> <HTML>
> <BODY>
>
> <!-- Render page -->
> <TABLE>
> <TR><TD>
> <!-- Menu -->
> <#include "menu.action">
> </TD></TR>
> <TR><TD>
> <!-- Input form or processing results -->
> <#include "viewdata.action?">
> </TD></TR>
> <!-- Login name or login form -->
> <TR><TD COLSPAN=2>
> <#include "loginstatus.action">
> </TD></TR>
> </BODY>
> </HTML>
> --
>
> Each of these actions have other .vm templates as Views, which in turn
> may use #include to (re-)use other "components" (where component=action
> class+set of template Views). This is where the hierarchical aspect
> comes in.
Ok. Still, I would think that a context tool would solve this?
> "menu.action" will just have menu.vm as view. "viewdata.action" will
> have either "viewdataform.vm" and "viewdataresults.vm" as view. Which
> one is used is dependent on if proper input has been given to
> viewdata.action (either directly through the URL query, or through the
> form). "loginstatus.action" have templates as views that either show the
> users name (if logged in) or a login form.
>
> This general approach allows for arbitrarily complex pages that are
> built up of components that are independent and can be reused on any
> number of pages. If "cardpane.action" is used as the "main body" action
> then there is also the case that there will only be one top template/JSP
> for the entire application: what is shown in the main body depends on
> what "card" is being displayed (see java.awt.CardLayout for the general
> idea. same principle applies here).
>
> So, this is cool stuff, but it requires #include to mimic servlet
> includes, i.e. it must support #include "somepage.jsp" properly.
>
> I have now implemented this by simply creating a new ResourceLoader,
> called ServletResourceLoader. Instead of reading stuff from a file or
> database as the current ones do, it will do a servlet include using
> RequestDispatcher.include. The only tricky part was to create an
> outputstream for the include that was buffered and then used as the
> basis for the InputStream returned by the ResourceLoader. But it works
> now anyway, and quite well too.
>
> Since it uses WebWork specific stuff (to access the request/response) I
> will put this in WebWork CVS, and I doubt that it is possible to make
> this generic enough to put in Velocity CVS.
>
> With this, and all the other goodness of WebWork, if you want to use
> Velocity on the web I think WebWork will be the preferred way to do so.
> In my very humble and biased opinion of course :-) Time will tell, as
> usual.
>
Er, there also is that thing called Turbine...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: rekindled Struts + Velocity?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tim Colson wrote:
>
> Geir slipped this bit:
> > help in the struts integration efforts that have recently been
> > rekindled...
>
> Ooooh, cool! Have I mentioned how much I'm not fond of JSP? ;-)
>
> Please, define 'rekindled'?
re·kin·dle (r-kndl) : tr.v. re·kin·dled, re·kin·dling, re·kin·dles - To
revive or renew as in "...rekindled an old interest in the Struts..."
:)
There has been some interest again in this - the more the merrier,
especially if you are a Struts user as you will benefit directly from
the success...
> After a bit much head-scratching last night with some JSP compile-time error
> in a custom taglib nonsense... I started looking through the source of the
> Velocity + Struts example app with serious intent. Began pondering if
> there's a real need for the Designer to know about different scopes or not,
> and if so/not how it might best be handled by the VelocityServlet.
I personally believe that there is no reason for the notion of 'scope'
to the designer. As far as I can tell, it's a necessary infrastructure
bit for session/application persistance in the container, but it should
be normalized by the controller. The user model should be independant
of the storage mechanism - therefore, it shouldn't matter to the
designer if you use scope or db or files or gerbils for storage...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
Re: rekindled Struts + Velocity?
Posted by Jon Stevens <jo...@latchkey.com>.
on 8/8/01 9:22 AM, "Tim Colson" <tc...@cisco.com> wrote:
> Began pondering if
> there's a real need for the Designer to know about different scopes or not,
I wondered the same thing.
<http://jakarta.apache.org/velocity/ymtd/ymtd-javabeans.html>
> and if so/not how it might best be handled by the VelocityServlet.
<http://jakarta.apache.org/turbine/pullmodel.html>
<http://jakarta.apache.org/turbine/services/pull-service.html>
> (Yes Jon, I know Turbine is probably better, but for various reasons we're
> using Struts for this particular project...so being able to use Velocity
> rather than JSP is at least half the battle. <grin>)
We have separated out most of the services from within Turbine into another
project/cvs repo called Turbine-Fulcrum. The Pull Service is not there yet,
but you should be able to soon integrate the Pull Service into your Struts
application. Help make that sooner. :-)
Thanks!
-jon
RE: rekindled Struts + Velocity?
Posted by Tim Colson <tc...@cisco.com>.
Geir slipped this bit:
> help in the struts integration efforts that have recently been
> rekindled...
Ooooh, cool! Have I mentioned how much I'm not fond of JSP? ;-)
Please, define 'rekindled'?
After a bit much head-scratching last night with some JSP compile-time error
in a custom taglib nonsense... I started looking through the source of the
Velocity + Struts example app with serious intent. Began pondering if
there's a real need for the Designer to know about different scopes or not,
and if so/not how it might best be handled by the VelocityServlet.
(Yes Jon, I know Turbine is probably better, but for various reasons we're
using Struts for this particular project...so being able to use Velocity
rather than JSP is at least half the battle. <grin>)
Cheers,
Timothy
IT Engineer
Re: #include and servlets :-)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Rickard Öberg wrote:
> So, this is cool stuff, but it requires #include to mimic servlet
> includes, i.e. it must support #include "somepage.jsp" properly.
>
> I have now implemented this by simply creating a new ResourceLoader,
> called ServletResourceLoader. Instead of reading stuff from a file or
> database as the current ones do, it will do a servlet include using
> RequestDispatcher.include. The only tricky part was to create an
> outputstream for the include that was buffered and then used as the
> basis for the InputStream returned by the ResourceLoader. But it works
> now anyway, and quite well too.
Another thought on this - this is cool, but wouldn't it more more
broadly useful as a context tool? I know I could use it, and it might
help in the struts integration efforts that have recently been
rekindled...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb