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 - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
