On 3/13/06, Serge Knystautas <[EMAIL PROTECTED]> wrote:
> On 3/3/06, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> > yeah, i'm interested in this stuff. in what little free time i have
> > these days, i've been half-heartedly fussing around with sprucing up
> > Veltag and adding tools support. since we've been using jsp at work a
> > lot more lately (much to my irritation), i've got increasing interest
> > in integrating Velocity and JSP in both directions. one of the
> > reasons we're using jsp more is because of a few tags we need.
>
> Nathan,
>
> So, I've got a page faker page context and have velocity able to
> invoke a tag. The basics are there, but I have questions I wanted to
> bounce off of you:
>
> 1. I don't see how I can use tags with body content. Freemarker
> syntactally supports tag invocations similar to a foreach loop, but
> without changing velocity's syntax, I can't see any way to provide
> similar capabilities. Do you have any ideas on this?
i think i'd have to see some of the code before i can suggest many
ideas. Velocity does support custom directives that take body
content. i think WebWork took this route when creating their tag
support for Velocity.
> 2. Do you have any ideas on syntax for how to access a tag invoker?
very tough call. it feels like there are only three options:
1) something along the lines of what webwork did, which i think was
kinda like this:
#invokeTag( 'myTag' "bar=$foo&foo=$bar" ) here's the body $stuff #end
i'm sure i don't have that exactly, but you can see that the ugly part
is specifying tag attributes as one string that later has to be
parsed.
2) do some fancy veltools-ish syntax like:
$tag.myTag.attribute('bar', $foo).attribute('foo',
$bar).body("here's the body $stuff")
this should be more robust and flexible. you might also be able to do
stuff like:
#set( $myTag = $tag.myTag )
#set( $myTag.bar = $foo )
#set( $myTag.foo = $bar )
#set( $myTag.body = "here's the body $stuff" )
$myTag
in fact, i'm pretty sure i could pretty easily create a single tool
that could handle both of the above syntaxes. the catch in both,
however, is setting a multi-line body. in Velocity 1.4, this would
not be possible. in Velocity 1.5, multi-line string literals and #set
statements should work (haven't actually tried that recently), so that
would get better:
#set( $myTag.body =
"here's the first body $stuff
and here is the $rest" )
3) change Velocity syntax to accomodate things:
#myTag( bar=$foo, foo=$bar ) here's the body $stuff #end
this might be possible if we can preload tag libraries as either
custom directives or maybe velocimacros and implement support for
named parameters into either or both of those. the named parameter
support is often requested, but no one has stepped up with a patch
there.
all in all, i think the tool syntax (#2) is probably going to be the
easiest to implement and the most flexible for the time being.
eventually #3 would be better though. i'm willing to help as i can on
the tricks needed for syntax #2, but my time is running short again,
so i can't promise too much.
> My initial needs do not need to expose ad-hoc tag calling from my
> velocity templates. I need context objects able to invoke specific
> tags....to explain a bit more, I'm using http://ajaxtags.sf.net, and I
> have some business logic beans that expose the ajax portlet and
> toggle/rating tags. What I expose to the velocity template is just
> something that says stick the rating element here, and I hardcode the
> tag attributes. This works for my app but isn't very helpful for
> everyone else. Any ideas appreciated.
not sure i followed that...
> 3. Do you have any ideas on suitable test cases? Maybe run all JSTL
> tags without body content?
hmm. i'm thinking most Velocity users won't be interested in most
JSTL tags as we already have support for most of that stuff in
Velocity or VelocityTools. DisplayTag is pretty popular, but i don't
know much about it. there is also the joda-time jsp tags. i'm
interested in those. :)
> --
> Serge Knystautas
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
