You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Marinó A. Jónsson" <ma...@centrum.is> on 2003/10/16 21:11:00 UTC
TilesTool - support for alternative view technologies (was Tiles tools)
It actually seems to be working :D
The new version of the TilesTool utilizes the RequestDispatcher to correctly
render alternative view technologies, such as JSPs. Thus it is now possible
to let tiles definitions that are based on a velocity layout to include
responses from these technologies.
Check it out on the Wiki:
http://nagoya.apache.org/wiki/apachewiki.cgi?NewTilesTool
IMO this opens the door for a proper ImportTool, based on the Import tag
from JSTL, that can take in Absolute URLs using streams, URLs with
parameters and so on and so forth :)
whatdayathink?
cheers,
Marinó
> -----Original Message-----
> From: Marinó A. Jónsson [mailto:marinoj@centrum.is]
> Sent: 15. október 2003 18:34
> To: 'Velocity Developers List'
> Subject: RE: Tiles tools
>
>
> Nathan said:
>
> > not true!
> >
> > $tool.someVoidSetMethod("foo")
> > is equivalent to
> > $tool.methodThatReturnsAnEmptyString()
>
> > you only need quiet notation for when the method returns null, not
> > when
> it's void.
>
> boy is my face red! ... must've been pretty damn sleepy last
> night :P the reason I posted this in the first place was that
> I got a ReferenceException when I changed the get() method to
> void and used the $tiles.foo notation ( as opposed to
> $tiles.get("foo") ) to refer to it. apparently I wasn't
> thinking straight :)
>
> I'm currently checking out the JSTL's import tag ... it seems
> all hope is not lost for Velocity Tiles definitions using JSP
> resources. I'll keep you posted.
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> Nathan said:
...
> > one doesn't accept arbitrary, absolute
> > URLs, and the other will primarily (if not only!) take
> > arbitrary, absolute URLs.
>
> no ... not only :)
oh. okay.
> > the only overlap might be between doing #include(
> > '/mydoc.bar' ) with the URLResourceLoader and doing
> > $import.read( 'http://foo.com/mydoc.bar' ) with the ImportTool.
>
> actually the corresponding call would be $import.read('/mydoc.bar'),
> but the other call should work too ... btw. nice touch on the method
> renaming.
...
i was working on the assumption ImportTool would be primarily for absolute
URLs. my mistake. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
yes, ImportTool definitely belongs in VelocityView. :)
Nathan Bubna
nathan@esha.com
----- Original Message -----
From: "Marinó A. Jónsson" <ma...@centrum.is>
...
heh I don't know ... I was working on it in conjunction with the tiles tool
so I inadvertently put it in the struts package - it probably belongs in the
view.tools package :)
what do you mean by "a tiles version for the view tools"?
Marinó
> -----Original Message-----
> From: Claude Brisson [mailto:claude@savoirweb.com]
...
> Why does the import tool appear as a struts tool ? It doesn't
> rely on struts at all, apparently.
>
> That may me think a tiles version for the view tools would be cool...
>
> CloD
...
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
> I meant a standalone tiles tool, exhibiting quite the same
> functionnalities but not relying on the struts tiles taglib.
aaahhh ... ok :)
yeah ... of course it would be cool to have a decent layout mechanism for
VelocityView - IMHO VelocityLayoutServlet doesn't quite compare with Tiles
:) However, since Tiles and Struts code are clearly separated - in fact
Tiles can run without Struts (or so they say), I'm not all that keen on
rewriting the Tiles lib in lightweight form for VelocityView.
> As I look to the Tiles taglib reference, I find it quite
> complex for what it does... there are many synonyms, and many
> things that could be dropped in the view.
I don't think it's all that complex in it's essence ... but I'll agree that
it's become a little bloated.
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by Claude Brisson <cl...@savoirweb.com>.
> what do you mean by "a tiles version for the view tools" ?
saying "a vew version of the tiles tool" should have been more correct :-)
I meant a standalone tiles tool, exhibiting quite the same functionnalities but not relying on the struts tiles taglib.
Please note that I'm not asking for it, I'm just wondering about the feasibility.
As I look to the Tiles taglib reference, I find it quite complex for what it does... there are many synonyms, and many things that
could be dropped in the view.
CloD
----- Original Message -----
From: "Marinó A. Jónsson" <ma...@centrum.is>
To: "'Velocity Developers List'" <ve...@jakarta.apache.org>; "'Claude Brisson'" <cl...@savoirweb.com>
Sent: samedi 18 octobre 2003 06:54
Subject: RE: TilesTool - support for alternative view technologies (was Tiles tools)
heh I don't know ... I was working on it in conjunction with the tiles tool
so I inadvertently put it in the struts package - it probably belongs in the
view.tools package :)
what do you mean by "a tiles version for the view tools"?
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
heh I don't know ... I was working on it in conjunction with the tiles tool
so I inadvertently put it in the struts package - it probably belongs in the
view.tools package :)
what do you mean by "a tiles version for the view tools"?
Marinó
> -----Original Message-----
> From: Claude Brisson [mailto:claude@savoirweb.com]
> Sent: 18. október 2003 04:34
> To: Velocity Developers List
> Subject: Re: TilesTool - support for alternative view
> technologies (was Tiles tools)
>
>
> Why does the import tool appear as a struts tool ? It doesn't
> rely on struts at all, apparently.
>
> That may me think a tiles version for the view tools would be cool...
>
> CloD
>
> ----- Original Message -----
> From: "Marinó A. Jónsson" <ma...@centrum.is>
> To: "'Velocity Developers List'" <ve...@jakarta.apache.org>
> Sent: samedi 18 octobre 2003 05:47
> Subject: RE: TilesTool - support for alternative view
> technologies (was Tiles tools)
>
>
> ps. on the subject of 'overlap' ... the ImportTool can of
> course both include and parse the same resources as #include
> and #parse:
>
> #include("foo.txt") --> $import.read("foo.txt")
> #parse("bar.vm") --> $import.read("bar.vm")
>
> so those using the ImportTool could also technically
> substitute both of these directives with a call to the read()
> method - although I would suspect some performance penalty :P
> However, by using the ImportTool you have the option of
> adding URL params.
>
> cheers,
> Marinó
>
> > -----Original Message-----
> > From: Marinó A. Jónsson [mailto:marinoj@centrum.is]
> > Sent: 18. október 2003 01:43
> > To: 'Velocity Developers List'
> > Subject: RE: TilesTool - support for alternative view technologies
> > (was Tiles tools)
> >
> >
> > Nathan said:
> > > i'd say they barely overlap, if it all.
> >
> > I agree.
> >
> > > one doesn't accept arbitrary, absolute
> > > URLs, and the other will primarily (if not only!) take arbitrary,
> > > absolute URLs.
> >
> > no ... not only :)
> >
> > > the only overlap might be between doing #include( '/mydoc.bar' )
> > > with the URLResourceLoader and doing $import.read(
> > > 'http://foo.com/mydoc.bar' ) with the ImportTool.
> >
> > actually the corresponding call would be
> $import.read('/mydoc.bar'),
> > but the other call should work too ... btw. nice touch on
> the method
> > renaming.
> >
> > > bottom line, i see Tools and ResourceLoaders as being in
> different
> > > problem
> > spaces. an
> > > ImportTool and URLResourceLoader may have a little superficial
> > > similarity,
> > but they fit
> > > different problem spaces and are drastically different
> > under the hood.
> > > i
> > think we need both
> > > and both to be separate.
> >
> > yup ... let's not forget that the primary impetus for the
> ImportTool
> > was to be able to include local JSP resources (as well as other
> > resources that can be accessed via the
> > RequestDispatcher) in Velocity templates. And that it does
> > :) ... it is now possible to make the following call within
> a Velocity
> > template and have it correctly rendered into the template:
> >
> > $import.read('/foo.jsp')
> >
> > as well as arbitrary, absolute URLs :)
> >
> > IMO this tool could very well ease the transition for e.g. JSP
> > programmers who flirt with Velocity.
> >
> > cheers,
> > Marinó
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> velocity-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by Claude Brisson <cl...@savoirweb.com>.
Why does the import tool appear as a struts tool ? It doesn't rely on struts at all, apparently.
That may me think a tiles version for the view tools would be cool...
CloD
----- Original Message -----
From: "Marinó A. Jónsson" <ma...@centrum.is>
To: "'Velocity Developers List'" <ve...@jakarta.apache.org>
Sent: samedi 18 octobre 2003 05:47
Subject: RE: TilesTool - support for alternative view technologies (was Tiles tools)
ps. on the subject of 'overlap' ... the ImportTool can of course both
include and parse the same resources as #include and #parse:
#include("foo.txt") --> $import.read("foo.txt")
#parse("bar.vm") --> $import.read("bar.vm")
so those using the ImportTool could also technically substitute both of
these directives with a call to the read() method - although I would suspect
some performance penalty :P However, by using the ImportTool you have the
option of adding URL params.
cheers,
Marinó
> -----Original Message-----
> From: Marinó A. Jónsson [mailto:marinoj@centrum.is]
> Sent: 18. október 2003 01:43
> To: 'Velocity Developers List'
> Subject: RE: TilesTool - support for alternative view
> technologies (was Tiles tools)
>
>
> Nathan said:
> > i'd say they barely overlap, if it all.
>
> I agree.
>
> > one doesn't accept arbitrary, absolute
> > URLs, and the other will primarily (if not only!) take
> > arbitrary, absolute URLs.
>
> no ... not only :)
>
> > the only overlap might be between doing #include(
> > '/mydoc.bar' ) with the URLResourceLoader and doing
> > $import.read( 'http://foo.com/mydoc.bar' ) with the ImportTool.
>
> actually the corresponding call would be
> $import.read('/mydoc.bar'), but the other call should work
> too ... btw. nice touch on the method renaming.
>
> > bottom line, i see Tools and ResourceLoaders as being in different
> > problem
> spaces. an
> > ImportTool and URLResourceLoader may have a little superficial
> > similarity,
> but they fit
> > different problem spaces and are drastically different
> under the hood.
> > i
> think we need both
> > and both to be separate.
>
> yup ... let's not forget that the primary impetus for the
> ImportTool was to be able to include local JSP resources (as
> well as other resources that can be accessed via the
> RequestDispatcher) in Velocity templates. And that it does
> :) ... it is now possible to make the following call within a
> Velocity template and have it correctly rendered into the template:
>
> $import.read('/foo.jsp')
>
> as well as arbitrary, absolute URLs :)
>
> IMO this tool could very well ease the transition for e.g.
> JSP programmers who flirt with Velocity.
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> ps. on the subject of 'overlap' ... the ImportTool can of course both
> include and parse the same resources as #include and #parse:
>
> #include("foo.txt") --> $import.read("foo.txt")
> #parse("bar.vm") --> $import.read("bar.vm")
...
actually the #parse and $import.read would not be quite equivalent. #parse()
would use the same context, while the $import.read() would get a new one.
still, you're right, they'd be close.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
ps. on the subject of 'overlap' ... the ImportTool can of course both
include and parse the same resources as #include and #parse:
#include("foo.txt") --> $import.read("foo.txt")
#parse("bar.vm") --> $import.read("bar.vm")
so those using the ImportTool could also technically substitute both of
these directives with a call to the read() method - although I would suspect
some performance penalty :P However, by using the ImportTool you have the
option of adding URL params.
cheers,
Marinó
> -----Original Message-----
> From: Marinó A. Jónsson [mailto:marinoj@centrum.is]
> Sent: 18. október 2003 01:43
> To: 'Velocity Developers List'
> Subject: RE: TilesTool - support for alternative view
> technologies (was Tiles tools)
>
>
> Nathan said:
> > i'd say they barely overlap, if it all.
>
> I agree.
>
> > one doesn't accept arbitrary, absolute
> > URLs, and the other will primarily (if not only!) take
> > arbitrary, absolute URLs.
>
> no ... not only :)
>
> > the only overlap might be between doing #include(
> > '/mydoc.bar' ) with the URLResourceLoader and doing
> > $import.read( 'http://foo.com/mydoc.bar' ) with the ImportTool.
>
> actually the corresponding call would be
> $import.read('/mydoc.bar'), but the other call should work
> too ... btw. nice touch on the method renaming.
>
> > bottom line, i see Tools and ResourceLoaders as being in different
> > problem
> spaces. an
> > ImportTool and URLResourceLoader may have a little superficial
> > similarity,
> but they fit
> > different problem spaces and are drastically different
> under the hood.
> > i
> think we need both
> > and both to be separate.
>
> yup ... let's not forget that the primary impetus for the
> ImportTool was to be able to include local JSP resources (as
> well as other resources that can be accessed via the
> RequestDispatcher) in Velocity templates. And that it does
> :) ... it is now possible to make the following call within a
> Velocity template and have it correctly rendered into the template:
>
> $import.read('/foo.jsp')
>
> as well as arbitrary, absolute URLs :)
>
> IMO this tool could very well ease the transition for e.g.
> JSP programmers who flirt with Velocity.
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Nathan said:
> i'd say they barely overlap, if it all.
I agree.
> one doesn't accept arbitrary, absolute
> URLs, and the other will primarily (if not only!) take
> arbitrary, absolute URLs.
no ... not only :)
> the only overlap might be between doing #include(
> '/mydoc.bar' ) with the URLResourceLoader and doing
> $import.read( 'http://foo.com/mydoc.bar' ) with the ImportTool.
actually the corresponding call would be $import.read('/mydoc.bar'), but the
other call should work too ... btw. nice touch on the method renaming.
> bottom line, i see Tools and ResourceLoaders as being in different problem
spaces. an
> ImportTool and URLResourceLoader may have a little superficial similarity,
but they fit
> different problem spaces and are drastically different under the hood. i
think we need both
> and both to be separate.
yup ... let's not forget that the primary impetus for the ImportTool was to
be able to include local JSP resources (as well as other resources that can
be accessed via the RequestDispatcher) in Velocity templates. And that it
does :) ... it is now possible to make the following call within a Velocity
template and have it correctly rendered into the template:
$import.read('/foo.jsp')
as well as arbitrary, absolute URLs :)
IMO this tool could very well ease the transition for e.g. JSP programmers
who flirt with Velocity.
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Christoph.Reck@dlr.de said:
...
> seems like a ImportTool overlaps with functionality a
> UrlResourceLoader could provide?
>
http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/whiteboard/geir/URLResourceLoader.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
i'd say they barely overlap, if it all.
one is a ResourceLoader and the other would be a ViewTool (two very different
things for significantly different purposes). one is in the whiteboard and
the other would be in VelocityView. one doesn't accept arbitrary, absolute
URLs, and the other will primarily (if not only!) take arbitrary, absolute
URLs. one is primarily meant to load templates directly into a parent
template, and the other is meant to import an arbitrary character stream from
the web into a String.
the only overlap might be between doing #include( '/mydoc.bar' ) with the
URLResourceLoader and doing $import.read( 'http://foo.com/mydoc.bar' ) with
the ImportTool.
> Currenlty the UrlResourceLoader is configured like all other
> resource loaders, using preconfigured base URLs, and does not take
> arbitrary URLs (neither absolute nor external ones).
>
> The biggest drawback I see is that how can one send and
> #import or #parse with an arbitary URL?
<gentle reminder>it's #include and #parse. :)</gentle reminder>
> Maybe one could enhance
> the UrlResourceLoader to understand a syntax like:
> http://localhost:8080/webappName/servletName/relative/resource
> as well as:
> http:/relative/resource
> or
> local:/relative/resource
> or any other standard url...
personally, i don't think ResourceLoaders should be pulling down documents
from arbitrary urls. security, sanity, simplicity, blah, blah, blah.
> IMO, it seems that allowing
#import("http://localhost:8080/myapp/vel/foo.vtl")
> and #parse("http://localhost:8080/myapp/bar.jsp")
> just hides the necesity of explicitely requiring a tool.
adding such a tool will probably be easier to set up than a(nother)
ResourceLoader would be. also, #parse( 'http://foo.com/bar.jsp' ) is an
anathema. the very possibility of someone doing that appalls me. :)
bottom line, i see Tools and ResourceLoaders as being in different problem
spaces. an ImportTool and URLResourceLoader may have a little superficial
similarity, but they fit different problem spaces and are drastically
different under the hood. i think we need both and both to be separate.
but i do appreciate the lateral thinking! :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Ch...@dlr.de.
Hi Marino and Nathan,
seems like a ImportTool overlaps with functionality a
UrlResourceLoader could provide?
http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/whiteboard/geir/URLResourceLoader.java?rev=HEAD&content-type=text/vnd.viewcvs-markup
Currenlty the UrlResourceLoader is configured like all other
resource loaders, using preconfigured base URLs, and does not take
arbitrary URLs (neither absolute nor external ones).
The biggest drawback I see is that how can one send and
#import or #parse with an arbitary URL? Maybe one could enhance
the UrlResourceLoader to understand a syntax like:
http://localhost:8080/webappName/servletName/relative/resource
as well as:
http:/relative/resource
or
local:/relative/resource
or any other standard url...
IMO, it seems that allowing #import("http://localhost:8080/myapp/vel/foo.vtl")
and #parse("http://localhost:8080/myapp/bar.jsp")
just hides the necesity of explicitely requiring a tool.
Any thoughts?
Cheers,
Christoph
Marinó A. Jónsson wrote:
> Nathan said:
>
>>and i wonder... is there any reason you couldn't
>>combine all of them in any arrangement you desire? crazy cool stuff.
>
>
> no reason that I can see :)
>
>
>><sidenote>please be sure you properly credit the JSTL authors
>>whose work this is derived from when you commit this code!</sidenote>
>
>
> of course ... I also updated the Wiki with this info.
>
>
>>on that note, how much functionality would overlap between
>>what the TilesTool is going to do and what the ImportTool
>>would do? i wouldn't want to see an inner
>>ImportResponseWrapper class showing up in both tools if that
>>could be avoided. is there any way for them to leverage the
>>same code? <wild idea>could TilesTool extend a well-written
>>ImportTool?</wild idea>
>
>
> As it is TilesTool only deals with local resources - the ImportTool would be
> a general-purpose text-importing mechanism, like it's JSTL counterpart.
> TilesTool currently uses a stripped down version of ImportResponseWrapper
> (compared with the ImportTool version) but it could just as easily use the
> full version I guess. Apart from that it's just a question of one small
> method in TilesTool, acquireString(), that actually prepares the target url
> and uses the ImportResponseWrapper to get the response as string. I think
> that putting ImportResponseWrapper along with some utility methods into a
> seperate class that both TilesTool and ImportTool interact with might be the
> way to go.
>
> However, I haven't checked to see if the Tiles JSP tag supports absolute
> URLs and/or request parameters ... but at least the TilesTool doesn't at
> present. If it turns out that the Tiles JSP tag supports it, I would
> upgrade the TilesTool accordingly. In that event there should be a
> significant overlap between the TilesTool and the ImportTool. In that case
> dropping the utility class and simply extending the ImportTool might very
> well be an option.
>
> But we'll see how the ImportTool turns out - I'm so excited about this that
> I expect that we'll be having the ImportTool ready for the 1.1 release :)
>
> Here is a working example of a Velocity ImportTool I just rigged up from the
> JSTL ImportSupport tag :)
>
> (I work behind a http proxy so I couldn't try it with external URLs - but it
> works with local absolute URLs at least :) )
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?ImportTool
>
> Go on ... give it a try ... it's pretty damn neat ;)
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> Nathan said:
...
> > in other words, are there reasons to
> > avoid using absolute/remote URLs with Tiles? i can't think
> > of any, but then again, i've never used Struts Tiles and know
> > little about it.
>
> probably saw no reason to ... Struts Tiles uses the RequestDispatcher for
> it's includes, but JSTL's ImportSupport detects if the URL is absolute or
> relative, and uses URLConnection and RequestDispatcher respectively as
> appropriate.
...
> at least, afaiks, it can't hurt - unless someone developes using TilesTool
> and then needs to port to Struts Tiles :P
heh... we don't support ports away from our code...all your base are belong
to... aw, nevermind. ;)
...
> > personally, i don't have a strong opinion about extending
> > ImportTool or having an view.ImportUtils class. i guess it's
> > a matter of whether TilesTool really is an extension of the
> > ImportTool concept. if it is, then extending makes sense.
> > but if it more of a parallel or alternate use of "importing",
> > then the ImportUtils is probably the way to go, and extending
> > would be more of a hack. what do you guys think? does
> > $tiles.read( $url ) make sense? i can't decide.
>
> Hmm ... no it doesn't really make sense - it doesn't extend it's concept but
> it does use it's function. The TilesTool is all about mapping logical names
> to resources - while the ImportTool is all about importing resources as
> strings. So $tiles.read($url) wouldn't make sense.
ok.
> We could create an
> abstract class, i.e. ImportSupport, that includes all the importing logic,
> and let both TilesTool and ImportTool extend it - so changes to the
> TilesTool would be minimal and the ImportTool would consist of only a single
> method - read().
+1 makes sense. they both use the "importing" concept/code to different ends.
> Or, we could go with the ImportUtils which would work much
> the same way, I think.
-0 probably wouldn't be quite as clean in implementation, and not as strongly
tied to the "tool" concept.
> what do you think?
all sorts of crazy things. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Nathan said:
> hmm. depends. is Struts Tiles explicitly designed to
> prevent use of absolute URLs? or is it merely something they
> saw no reason to do? in other words, are there reasons to
> avoid using absolute/remote URLs with Tiles? i can't think
> of any, but then again, i've never used Struts Tiles and know
> little about it.
probably saw no reason to ... Struts Tiles uses the RequestDispatcher for
it's includes, but JSTL's ImportSupport detects if the URL is absolute or
relative, and uses URLConnection and RequestDispatcher respectively as
appropriate.
> in general, i have always insisted on working to be a better
> solution over against being merely a
> parallel/compatible/similar solution. if supporting absolute
> URLs is a clear improvement, then i'm +1. if there are
> reasons not to besides "that's not how so-and-so does it",
> then i'm -0.
at least, afaiks, it can't hurt - unless someone developes using TilesTool
and then needs to port to Struts Tiles :P
I'm +1 here.
> hmm. i presume that in either case, if we didn't want to
> allow absolute URLs in TilesTool, then we'd have to actively
> block/inhibit that behavior in TilesTool, right? if so, then
> KISS might be another motive for allowing absolute URLs with Tiles.
yup.
> personally, i don't have a strong opinion about extending
> ImportTool or having an view.ImportUtils class. i guess it's
> a matter of whether TilesTool really is an extension of the
> ImportTool concept. if it is, then extending makes sense.
> but if it more of a parallel or alternate use of "importing",
> then the ImportUtils is probably the way to go, and extending
> would be more of a hack. what do you guys think? does
> $tiles.read( $url ) make sense? i can't decide.
Hmm ... no it doesn't really make sense - it doesn't extend it's concept but
it does use it's function. The TilesTool is all about mapping logical names
to resources - while the ImportTool is all about importing resources as
strings. So $tiles.read($url) wouldn't make sense. We could create an
abstract class, i.e. ImportSupport, that includes all the importing logic,
and let both TilesTool and ImportTool extend it - so changes to the
TilesTool would be minimal and the ImportTool would consist of only a single
method - read(). Or, we could go with the ImportUtils which would work much
the same way, I think.
what do you think?
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
...
> However, as it turns out, Struts Tiles does not support using arbitrary
> absolute URLs as attributes ... so the question is - do we limit the
> TilesTool to be in concordance with it's Struts counterpart or do we let it
> support this feature?
hmm. depends. is Struts Tiles explicitly designed to prevent use of absolute
URLs? or is it merely something they saw no reason to do? in other words,
are there reasons to avoid using absolute/remote URLs with Tiles? i can't
think of any, but then again, i've never used Struts Tiles and know little
about it.
in general, i have always insisted on working to be a better solution over
against being merely a parallel/compatible/similar solution. if supporting
absolute URLs is a clear improvement, then i'm +1. if there are reasons not
to besides "that's not how so-and-so does it", then i'm -0.
> Then there's the question of letting TilesTool extend ImportTool, or
> creating some sort of Import utility class that both TilesTool and
> ImportTool would use.
hmm. i presume that in either case, if we didn't want to allow absolute URLs
in TilesTool, then we'd have to actively block/inhibit that behavior in
TilesTool, right? if so, then KISS might be another motive for allowing
absolute URLs with Tiles.
personally, i don't have a strong opinion about extending ImportTool or having
an view.ImportUtils class. i guess it's a matter of whether TilesTool really
is an extension of the ImportTool concept. if it is, then extending makes
sense. but if it more of a parallel or alternate use of "importing", then the
ImportUtils is probably the way to go, and extending would be more of a hack.
what do you guys think? does $tiles.read( $url ) make sense? i can't decide.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
I said:
> As it is TilesTool only deals with local resources - the
> ImportTool would be a general-purpose text-importing
> mechanism, like it's JSTL counterpart. TilesTool currently
> uses a stripped down version of ImportResponseWrapper
> (compared with the ImportTool version) but it could just as
> easily use the full version I guess. Apart from that it's
> just a question of one small method in TilesTool,
> acquireString(), that actually prepares the target url and
> uses the ImportResponseWrapper to get the response as string.
> I think that putting ImportResponseWrapper along with some
> utility methods into a seperate class that both TilesTool and
> ImportTool interact with might be the way to go.
>
> However, I haven't checked to see if the Tiles JSP tag
> supports absolute URLs and/or request parameters ... but at
> least the TilesTool doesn't at present. If it turns out that
> the Tiles JSP tag supports it, I would upgrade the TilesTool
> accordingly. In that event there should be a significant
> overlap between the TilesTool and the ImportTool. In that
> case dropping the utility class and simply extending the
> ImportTool might very well be an option.
The new TilesTool enables us to mix'n match Velocity Templates and JSPs at
will - eg. the following tiles-defs are perfectly ok:
<definition name="store.jsp.frontpage" path="/layout/jspLayout.jsp">
<put name="body" value="store.frontpage.body"/>
<put name="menu" value="/menu_frontpage.vm"/>
<put name="footer" value="/footer.jsp"/>
</definition>
<definition name="store.frontpage.body" path="/layout/bodyLayout.vm">
<put name="header" value="/header_frontpage.vm"/>
<put name="body" value="/featured_frontpage.jsp"/>
</definition>
However, as it turns out, Struts Tiles does not support using arbitrary
absolute URLs as attributes ... so the question is - do we limit the
TilesTool to be in concordance with it's Struts counterpart or do we let it
support this feature?
Then there's the question of letting TilesTool extend ImportTool, or
creating some sort of Import utility class that both TilesTool and
ImportTool would use.
thoughts?
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: TilesTool - support for alternative view technologies (was Tiles tools)
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Nathan said:
> and i wonder... is there any reason you couldn't
> combine all of them in any arrangement you desire? crazy cool stuff.
no reason that I can see :)
> <sidenote>please be sure you properly credit the JSTL authors
> whose work this is derived from when you commit this code!</sidenote>
of course ... I also updated the Wiki with this info.
> on that note, how much functionality would overlap between
> what the TilesTool is going to do and what the ImportTool
> would do? i wouldn't want to see an inner
> ImportResponseWrapper class showing up in both tools if that
> could be avoided. is there any way for them to leverage the
> same code? <wild idea>could TilesTool extend a well-written
> ImportTool?</wild idea>
As it is TilesTool only deals with local resources - the ImportTool would be
a general-purpose text-importing mechanism, like it's JSTL counterpart.
TilesTool currently uses a stripped down version of ImportResponseWrapper
(compared with the ImportTool version) but it could just as easily use the
full version I guess. Apart from that it's just a question of one small
method in TilesTool, acquireString(), that actually prepares the target url
and uses the ImportResponseWrapper to get the response as string. I think
that putting ImportResponseWrapper along with some utility methods into a
seperate class that both TilesTool and ImportTool interact with might be the
way to go.
However, I haven't checked to see if the Tiles JSP tag supports absolute
URLs and/or request parameters ... but at least the TilesTool doesn't at
present. If it turns out that the Tiles JSP tag supports it, I would
upgrade the TilesTool accordingly. In that event there should be a
significant overlap between the TilesTool and the ImportTool. In that case
dropping the utility class and simply extending the ImportTool might very
well be an option.
But we'll see how the ImportTool turns out - I'm so excited about this that
I expect that we'll be having the ImportTool ready for the 1.1 release :)
Here is a working example of a Velocity ImportTool I just rigged up from the
JSTL ImportSupport tag :)
(I work behind a http proxy so I couldn't try it with external URLs - but it
works with local absolute URLs at least :) )
http://nagoya.apache.org/wiki/apachewiki.cgi?ImportTool
Go on ... give it a try ... it's pretty damn neat ;)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: TilesTool - support for alternative view technologies (was Tiles
tools)
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
...
> The new version of the TilesTool utilizes the RequestDispatcher to
> correctly render alternative view technologies, such as JSPs. Thus it
> is now possible to let tiles definitions that are based on a velocity
> layout to include responses from these technologies.
neato! this could be powerful stuff. the layout/content options abound!
#include/parse, VelocityLayoutServlet, and a TilesTool that for all
appearances is better than the JSP version! and i wonder... is there any
reason you couldn't combine all of them in any arrangement you desire? crazy
cool stuff.
> Check it out on the Wiki:
> http://nagoya.apache.org/wiki/apachewiki.cgi?NewTilesTool
<sidenote>please be sure you properly credit the JSTL authors whose work this
is derived from when you commit this code!</sidenote>
> IMO this opens the door for a proper ImportTool, based on the
> Import tag from JSTL, that can take in Absolute URLs using streams,
> URLs with prameters and so on and so forth :)
>
> whatdayathink?
i think it would be great to have an ImportTool as well. there have been
inquiries about how to do that for a while. on that note, how much
functionality would overlap between what the TilesTool is going to do and what
the ImportTool would do? i wouldn't want to see an inner
ImportResponseWrapper class showing up in both tools if that could be avoided.
is there any way for them to leverage the same code? <wild idea>could
TilesTool extend a well-written ImportTool?</wild idea>
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org