to some
> other presentation technologies, but clearly not all.
Tiles works great for us, and we are able to use it in such a way that we can
mix and match JSP and Velocity tiles. i definitely think Tiles can and should
avoid dependence
to each of us individually, of course.
...
couldn't agree more!
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
you're linking *to*, not which
one you are *in*.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
t; extensions? This is how JSPs work as it is; if your deployment
> descriptor gave *.xsl to the STXX servlet, then
> requestDispatcher.forward() would give control to STXX just to do the
> view rendering.
>
> I thought this was how the Velocity/Struts integration stuff worked already.
that
aglibs are
separated, we will include the taglib jar in the WAR for that app, but not
have it in the rest of the distribution. if you included a VelocityStruts app
in the Struts examples, would you argue that VelocityTools should be
distributed with Struts besides being in the example app's WAR?
> And if we're going to bundle support for a
> view technology, shouldn't it be the most widely used, widely understood and
> standard (as in JCP, not as in the standard for Struts) one?
as long as the core and the taglibs have separate release cycles and are in
separate jars, i won't be too picky. :) if you want to ship them together,
go for it. though personally, i think the 16MB size of the Struts 1.1
distribution could use a little paring down somewhere. there's already a ton
of jars (mostly duplicates) between the lib, struts-el/lib, and the example
WARs. but i digress, that is another matter. :)
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
little success with that, but you're not
really helping here. while it's true that other view technologies can use
Struts, as long as the Struts developers treat JSP as the "standard" view and
distribute the two together, i believe you are significantly limiting the
potential of Struts as a framework/controller for applications (web and
otherwise).
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
l
documented/exampled.
> Also, what happens if we need to resolve by other means? Add more weight to
> the super class or add another specialized sub class?
...
i don't think there's really that many reasonable ways to specify a dispatch,
and you're just talking here abou
x27;d be very much in favor of integrating something like Tiles as part
> of the request processor, so long as it is accessible to non-JSP
> technologies. But I'm not sure if we have that now.
agreed.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mirror.
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bean, it already has a get(String) method.
cool. i was happy and didn't even know it! thx! :)
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > > Thanks.
> >
> > The reason to think about doing it is usability, which sometimes needs
> > to
> > win out over O-O purity :-).
>
> I often argue from the OO purist perspective (if you hadn't guessed by now
> :-). However, sometimes th
David Graham said:
...
> Struts is view agnostic. You can use any view technology you like.
agreed! but it could be made friendlier to non-JSP view technologies.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16814
:-)
(btw, congrats again on getting 1.1 out. ya'll are great!)
elp in
dispelling the seemingly frequent perception that Struts is just for those
using JSPs.
> Nathan said:
...
> >It would also *greatly* please those of us who prefer to use Struts
without
> >using JSPs.
Nathan Bubna
[EMAIL PROTECTED]
David Graham said:
...
> It would benefit Struts to move the tags to a separate distro (there
should
> probably still be an all-in-one distro too).
...
It would also *greatly* please those of us who prefer to use Struts without
using JSPs.
Nathan Bubna
[EMAIL PRO
you do if you need the ServletContext but no session exists for
the request? Do you want the RequestUtils to be responsible for creating a
session? I'm not sure I like that. I think it's fine to pass the
ServletContext as well as the request
nd you the patches to review, Anthony?
The velocity-dev list would be a great place to share those. :-)
Nathan Bubna
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ed on the model
> objects that have been placed into the context.
[snip]
yeah, i had a feeling it was something like that. i can see that that is
useful for initial development, but unless you have some real need to keep
that HTML output always in sync with the NavBar tag, i think it would be
best to move away from that as you continue to develop the product.
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
tually, Ted's Struts book (Struts In Action) devotes an entire chapter
> to using Velocity and Struts together, including how VelocityViewServlet
> helps you out. It would make a pretty good starting point for people
> interested in learning how to combine them.
yeah, i haven't
y/user-guide.html#Velocimacros
this provides some nice encapsulation to avoid both hard-coding html or xml
or whatever and yet not have to copy-paste or retype the same stuff every
time.
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
be in the template to begin with, or
at least defined the global Velocimacro library. that way the code could
just be:
#showNavBar( true)
anyway, i hope i'm not coming off too argumentative, it's just that these
are poor examples of using velocity. i wouldn't want people to get the
wrong idea. :)
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
agement and such is mostly in the javadocs right
now. here's some links that may be of interest to you:
Gabe Sidler's docs on Velocity+Struts:
http://www.teamup.com/jakarta-velocity-tools/struts/docs/index.html
Velocity Tools home:
http://jakarta.apache.org/velocity/toolsubproject.html
Veltag
21 matches
Mail list logo
