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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
