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