You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Raphaël Luta <ra...@apache.org> on 2005/12/01 10:48:10 UTC
Re: Extract from a discusion on open source LMS
Aaron Evans wrote:
> Greg Reddin <greddin <at> apache.org> writes:
>
>>Interestingly, I've found that Jetspeed does not necessarily use the
>>same standards as I do So I'm battling with whether to learn
>>Velocity or try to introduce more JSP examples into J2. For now,
>>I'll probably learn velocity just for the reasons mentioned in that
>>post. I don't want to roll my own version of everything. Would
>>probably be better to just stick with what's already being done.
>>
>
>
> I for one would love to see jsp versions of the velocity components.
> I don't really want to learn velocity, I'm already having to learn enough
> new technologies! :)
>
>
I can definitely feel your pain. Jetspeed uses a lot of technologies that may
or may not be familiar to many people (Velocity, Maven, Turbine in JS1 Spring in
JS2, etc...).
For the specific case of Velocity, in addition to the fact that some us loathe
JSP (count me in !), there is at least one compelling reason to use Velocity in
Jetspeed for core components : velocity fragments are plain text resources
whereas JSPs are actually servlets.
It may seem trivial but the actual consequences in a portal environment are very
important:
with Velocity, *you* decide how to retrieve and parse your Velocity view without
any reliance on the deployment app server implementation :
- you don't need to worry about classloading issues
- you don't need to worry about "reserved" file placements in your WAR
- you don't have to ensure that you pass along the app server request/response
implementation so that you can servlet.include() those JSPs
- you always control caching/buffering of processed contents
- etc...
In short, you're guaranteed a consistent behavior of your application across all
app servers without stupid workarounds to deal with specific implementations.
I can list *a lot* of complications created by using JSPs vs Velocity
(unfortunately most of these constraints are now part of JSR 168 :( )
Now for the functional side, consider that using velocity in the layout, we can
easily have the layout portlets dynamically query a DB a runtime, load a stored
velocity script fragment to customize the behavior at runtime (think
implementation of dynamic marketing/personalisation rules for example).
Try doing that with JSP !
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Extract from a discusion on open source LMS
Posted by Raphaël Luta <ra...@apache.org>.
Aaron Evans wrote:
>
> My goodness, I certainly seem to have hit a nerve with regards to Velocity
> (there were a few posts by people who apparently loathe JSPs). ;-)
>
> Granted I am new to both Velocity and portlet development and I certainly did
> not want to start a religious war here. I think we can save that for the M$
> and PHP developers.
>
Don't worry, we're not religious here (the proof being that both Velocity and
JSP *are* supported by the engine :). This is mostly personal prefrences of
different developers that have evolved based on experience.
But I think it's interesting to discuss the pro and cons of the different
technologies that are used in Jetspeed.
> But I can tell you that having worked with java web apps over the past 10
> years I haven't really run into any frustrations from app server to app server
> using JSPs (since the emergence of J2EE) and the frustrations you list
> above (eg. classloading, structure of WAR files, etc) I have not found to be
> a problem. I have found that if I keep my applications to spec, they will run
> in any J2EE environment without a problem.
>
All the things I've listed have bitten us in Jetspeed 1 over the last 5 years
ever since we've decided to support JSP for views (in the very first releases
only Velocity was available).
Also, note that portals and especially JSR168 portals are tricky applications
when it comes to classloading and in general we're stretching the servlet
API to its limit (for example: parallel rendering of portlets with JSP views is
not possible according to servlet spec 2.3 (haven't checked 2.4 yet) because
you'd have to invoke your JSP servlet on a different thread that the main
request thread).
> With regards to dynamic profiling and personalization of content, I have been
> doing this for many years using JSP for the presentation layer in combination
> with other technologies and again, I haven't run into any problems there
> either.
>
I agree there are many ways to handle this requirement with JSPs but you can't
use JSPs as a script snippet as you can with Velocity.
> You say the compelling reason to use velocity over JSP for core components is
> because they are text resources instead of compiled servlets. I would think
> it would be the opposite. I would think that you would want the components
> that are called most frequently to be compiled resources already loaded in
> memory thereby avoiding disk contention and reducing processing time. But
> then again, I am new to velocity and so perhaps I am ignorant to it's caching
> capabilities.
>
You have some caching capabilities but you are right that there's a
performance cost to using velocity compared to JSP.
Whatever our personal preferences are, we're going to support both technologies:
Velocity because we like it and think it's the right technology for the
problem we're trying to solve and JSP because there's a user demand for it.
Since it's incredibly cumbersome to implement everything twice, we
would need someone comfortable with JSPs to reimplement the Velocity view
components and tools as JSP pages/tag libraries and willing to maintain them
other time.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Extract from a discusion on open source LMS
Posted by Raphaël Luta <ra...@apache.org>.
Frank Villarreal wrote:
> I tend to agree that using plain JSP+standard tags would certainly lower the learning curve for J2 newbies.
> Speaking from my personal experiences with this project, Velocity made my life
much more difficult.
> I'm still trying to customize layouts, menus, etc. And doing so with complex
Velocity scripts sure
> isn't very easy to do and/or debug ... especially when there is limited debug
info (compile errors!).
> Doesn't help that Velocity's site isn't documented very thoroughly. I find
myself needing to do more
> and more advanced stuff in Velocity that would be a snap in plain JSP ... but
constrained by
> Velocity's environment. This is just my 2 cents and me sharing my experience
... not a gripe.
>
You definitely have a point on tracking Velocity error messages, that may really
be a pain.
Can you give some example of things you're finding difficult to implement with
velocity ? Maybe we help you figure out the best way to implement your
requirement in Velocity.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Extract from a discusion on open source LMS
Posted by "Dr. Michael Lipp" <Mi...@danet.de>.
I'd like to add a quite different point concernbing Velocity. It may
have changed, but when I had my first "contact" with Jetspeed2, it was
definitely the case that every servlet needs its own instance of the
Velocity engine (and due to classloading rules its own copy of the
classes). This makes startup time quite long (admitted, this is a
developer time issue) and requires quite some memory (my impression,
never really tracked that down).
- Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Extract from a discusion on open source LMS
Posted by Scott T Weaver <sc...@binary-designs.net>.
I agree that Velocity's error reporting is lacking. That is why I would
like to see Jetspeed 2 use something like Wicket that gives you wonderful
line-precise error reports. Another bonus of the component oriented
frameworks like Echo, Tapestry and Wicket is that there is NO code in your
HTML whatsoever. This makes debugging so much simpler and template
development for non-java gurus actually possible.
Okay, you can tell me to shut up about now component frameworks now ;)
As for my loathing of JSPs; honestly, I've tried to like them, I swear. I
have used Struts, JSTL, etc. Every time I end up with a horribly unwelcome
taste in my mouth which requires me to rinse it out with Velocity.
Ahhhhh!!! Minty fresh!!!
Regards,
-Scott
> -----Original Message-----
> From: Frank Villarreal [mailto:f_villarreal@tetco.com]
> Sent: Thursday, December 01, 2005 9:00 AM
> To: Jetspeed Users List
> Subject: RE: Extract from a discusion on open source LMS
>
> I tend to agree that using plain JSP+standard tags would certainly lower
> the learning curve for J2 newbies. Speaking from my personal experiences
> with this project, Velocity made my life much more difficult. I'm still
> trying to customize layouts, menus, etc. And doing so with complex
> Velocity scripts sure isn't very easy to do and/or debug ... especially
> when there is limited debug info (compile errors!). Doesn't help that
> Velocity's site isn't documented very thoroughly. I find myself needing
> to do more and more advanced stuff in Velocity that would be a snap in
> plain JSP ... but constrained by Velocity's environment. This is just my
> 2 cents and me sharing my experience ... not a gripe.
>
> - Frank
>
> >
> > My goodness, I certainly seem to have hit a nerve with regards to
> > Velocity
> > (there were a few posts by people who apparently loathe JSPs). ;-)
> >
> > Granted I am new to both Velocity and portlet development and I
> > certainly did
> > not want to start a religious war here. I think we can save that
> > for the M$
> > and PHP developers.
> >
> > But I can tell you that having worked with java web apps over the past
> 10
> > years I haven't really run into any frustrations from app server
> > to app server
> > using JSPs (since the emergence of J2EE) and the frustrations you list
> > above (eg. classloading, structure of WAR files, etc) I have not
> > found to be
> > a problem. I have found that if I keep my applications to spec,
> > they will run
> > in any J2EE environment without a problem.
> >
> > With regards to dynamic profiling and personalization of content,
> > I have been
> > doing this for many years using JSP for the presentation layer in
> > combination
> > with other technologies and again, I haven't run into any problems there
> > either.
> >
> > You say the compelling reason to use velocity over JSP for core
> > components is
> > because they are text resources instead of compiled servlets. I
> > would think
> > it would be the opposite. I would think that you would want the
> > components
> > that are called most frequently to be compiled resources already
> > loaded in
> > memory thereby avoiding disk contention and reducing processing time.
> But
> > then again, I am new to velocity and so perhaps I am ignorant to
> > it's caching
> > capabilities.
> >
> > I think for those that are used to using velocity, it is great that it
> is
> > supported as that will help get J1 developers onboard for J2. But I
> think
> > if we look to get adoption from outside the jetspeed community
> > (and I believe
> > there is and will be a lot of interest in J2), you will find that
> > most people
> > are not familiar with velocity.
> >
> > Personally, I don't have a problem with it except that it looks a lot
> like
> > script or PHP and that it is new to me and, like you said, there
> > are already
> > a lot of technologies to learn with J2. I think that this is by
> > no means the
> > fault of the J2 developers though. When you are talking portal, it
> really
> > covers a lot and will require many technologies to do it right.
> > Thankfully,
> > the J2 developers have used OS technologies that have solid
> > communities behind
> > them.
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
RE: Extract from a discusion on open source LMS
Posted by Frank Villarreal <f_...@tetco.com>.
I tend to agree that using plain JSP+standard tags would certainly lower the learning curve for J2 newbies. Speaking from my personal experiences with this project, Velocity made my life much more difficult. I'm still trying to customize layouts, menus, etc. And doing so with complex Velocity scripts sure isn't very easy to do and/or debug ... especially when there is limited debug info (compile errors!). Doesn't help that Velocity's site isn't documented very thoroughly. I find myself needing to do more and more advanced stuff in Velocity that would be a snap in plain JSP ... but constrained by Velocity's environment. This is just my 2 cents and me sharing my experience ... not a gripe.
- Frank
>
> My goodness, I certainly seem to have hit a nerve with regards to
> Velocity
> (there were a few posts by people who apparently loathe JSPs). ;-)
>
> Granted I am new to both Velocity and portlet development and I
> certainly did
> not want to start a religious war here. I think we can save that
> for the M$
> and PHP developers.
>
> But I can tell you that having worked with java web apps over the past 10
> years I haven't really run into any frustrations from app server
> to app server
> using JSPs (since the emergence of J2EE) and the frustrations you list
> above (eg. classloading, structure of WAR files, etc) I have not
> found to be
> a problem. I have found that if I keep my applications to spec,
> they will run
> in any J2EE environment without a problem.
>
> With regards to dynamic profiling and personalization of content,
> I have been
> doing this for many years using JSP for the presentation layer in
> combination
> with other technologies and again, I haven't run into any problems there
> either.
>
> You say the compelling reason to use velocity over JSP for core
> components is
> because they are text resources instead of compiled servlets. I
> would think
> it would be the opposite. I would think that you would want the
> components
> that are called most frequently to be compiled resources already
> loaded in
> memory thereby avoiding disk contention and reducing processing time. But
> then again, I am new to velocity and so perhaps I am ignorant to
> it's caching
> capabilities.
>
> I think for those that are used to using velocity, it is great that it is
> supported as that will help get J1 developers onboard for J2. But I think
> if we look to get adoption from outside the jetspeed community
> (and I believe
> there is and will be a lot of interest in J2), you will find that
> most people
> are not familiar with velocity.
>
> Personally, I don't have a problem with it except that it looks a lot like
> script or PHP and that it is new to me and, like you said, there
> are already
> a lot of technologies to learn with J2. I think that this is by
> no means the
> fault of the J2 developers though. When you are talking portal, it really
> covers a lot and will require many technologies to do it right.
> Thankfully,
> the J2 developers have used OS technologies that have solid
> communities behind
> them.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: Extract from a discusion on open source LMS
Posted by Aaron Evans <aa...@yahoo.ca>.
Raphaël Luta <raphael <at> apache.org> writes:
> For the specific case of Velocity, in addition to the fact that some us
loathe
> JSP (count me in !), there is at least one compelling reason to use Velocity
in
> Jetspeed for core components : velocity fragments are plain text resources
> whereas JSPs are actually servlets.
>
> It may seem trivial but the actual consequences in a portal environment are
very
> important:
> with Velocity, *you* decide how to retrieve and parse your Velocity view
without
> any reliance on the deployment app server implementation :
> - you don't need to worry about classloading issues
> - you don't need to worry about "reserved" file placements in your WAR
> - you don't have to ensure that you pass along the app server
request/response
> implementation so that you can servlet.include() those JSPs
> - you always control caching/buffering of processed contents
> - etc...
>
> In short, you're guaranteed a consistent behavior of your application across
all
> app servers without stupid workarounds to deal with specific implementations.
>
> I can list *a lot* of complications created by using JSPs vs Velocity
> (unfortunately most of these constraints are now part of JSR 168 :( )
>
> Now for the functional side, consider that using velocity in the layout, we
can
> easily have the layout portlets dynamically query a DB a runtime, load a
stored
> velocity script fragment to customize the behavior at runtime (think
> implementation of dynamic marketing/personalisation rules for example).
> Try doing that with JSP !
>
My goodness, I certainly seem to have hit a nerve with regards to Velocity
(there were a few posts by people who apparently loathe JSPs). ;-)
Granted I am new to both Velocity and portlet development and I certainly did
not want to start a religious war here. I think we can save that for the M$
and PHP developers.
But I can tell you that having worked with java web apps over the past 10
years I haven't really run into any frustrations from app server to app server
using JSPs (since the emergence of J2EE) and the frustrations you list
above (eg. classloading, structure of WAR files, etc) I have not found to be
a problem. I have found that if I keep my applications to spec, they will run
in any J2EE environment without a problem.
With regards to dynamic profiling and personalization of content, I have been
doing this for many years using JSP for the presentation layer in combination
with other technologies and again, I haven't run into any problems there
either.
You say the compelling reason to use velocity over JSP for core components is
because they are text resources instead of compiled servlets. I would think
it would be the opposite. I would think that you would want the components
that are called most frequently to be compiled resources already loaded in
memory thereby avoiding disk contention and reducing processing time. But
then again, I am new to velocity and so perhaps I am ignorant to it's caching
capabilities.
I think for those that are used to using velocity, it is great that it is
supported as that will help get J1 developers onboard for J2. But I think
if we look to get adoption from outside the jetspeed community (and I believe
there is and will be a lot of interest in J2), you will find that most people
are not familiar with velocity.
Personally, I don't have a problem with it except that it looks a lot like
script or PHP and that it is new to me and, like you said, there are already
a lot of technologies to learn with J2. I think that this is by no means the
fault of the J2 developers though. When you are talking portal, it really
covers a lot and will require many technologies to do it right. Thankfully,
the J2 developers have used OS technologies that have solid communities behind
them.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org