At 11:11 PM 12/12/2000 -0500, Chris Winters wrote:
>* Nathan Torkington ([EMAIL PROTECTED]) [001212 22:09]:
> >
> > Anyone run such an installation?  Anyone want to write about their
> > setup and experiences?
> >

There are projects where we use mod_perl handlers for stuff like 
prototyping auth but then use servlets/JSPs for the app. But I believe 
that's too shallow for what Nat wants.

We're a small shop of primarily fairly senior developers (at least several 
years experience in the languages we like to use)... and we've actually 
found that the Java web and the Perl web projects we've delivered on aren't 
necessarily THAT far off in project delivery time than some Perl people 
would have you believe.

Of course, we have a toolkit that we use to develop apps in both Perl and 
Java which helps, but it's still interesting that business logic for people 
experienced in the language of their choice isn't that bad in terms of 
delivery time. Of course, maintenance is another issue.

I'll probably get some flak for the above statement about Perl vs Java 
delivery time. :)


>Kind of off-topic but not really: I've recently moved from a job with
>100% Perl to one with 80% Java / 20% Perl. One of the things I miss
>most is the Template Toolkit. (There are lots of other things too, but
>this keeps coming up again and again.) TT is just so amazingly useful
>and simple enough that I can't believe more people aren't using it.
>
>As for Java, I find it really hard to believe that JSP has caught on
>like it has. The syntax is *amazingly* clunky and leads me to believe
>that most people who write JSP use WYSIWYG editors to generate the
>code for them. (Not that there's anything wrong with that, but it gets
>my hackles up that catering to one group of folks raises the barriers
>for another.)
>
>"Clunky syntax" might seem like a trivial concern, but IMO it's
>not. It goes right to the heart of usability -- JSP does not make easy
>things easy. Since you can embed Java into the page, hard things are
>possible, but the wisdom of doing a lot of processing in the page
>itself is beyond me.
Ah but have you looked at taglibs? We rarely ever put Java processing on 
the page itself.

In the history of open source java apps we've developed there was only one 
algorithm that we chose to kludge in as embedded Java code (and we will 
eventually remove it)... And it was an algorithm to generate event blocks 
in the day view of a calendar (ala Outlook) so that multiple appointments 
can be at the same time but also span different hours (so 3pm to 5pm and 
another from 3:30pm to 4:00pm) etc.. and the calendar knows how to render 
itself. Believe me that is a HARD algorithm in any language to get right so 
that the HTML displays nicely in all browsers.

As for logic in a JSP... Well, the above is an example of something where 
you need code for the display to work well.

The downside of taglibs is that they are complex, however taglibs aren't 
THAT bad. In our framework every JSP page has at least 3 sets of taglibs 
(more can be added if they are generic and serve a purpose)..

Framework level -- These are our utility taglibs.
App level -- These are taglibs that represent app information
Page level -- Each JSP page, like it or not, has information that it needs 
to display specific to itself.

The nice thing is that our web designer just needs a cheatsheet of taglib 
and what it does and doesn't have to worry about any other syntax.

The main bad thing about this is that when we spec out a project, each 
"view" on the application we spec out as 2 days instead of 1 day of work in 
the equivalent Perl because coding the taglibs gets to be a pain.

This may seem like overall project delivery time is increased, and it is... 
a bit. But the majority of a webapp is not necessarily the screens. It's 
the logic underneath, so our timelines don't really end up growing that 
much in the scheme of a project.

But we do get a better maintenance time because the JSPs are really 
divorced entirely from Java code allowing a web designer to change things 
at will without having to worry about an artificial . We almost never embed 
Java inside a JSP.

>(And generating web-interfaces from servlets is sufficiently painful
>that we don't need to discuss it -- haven't any of these smart Java
>people ever heard of heredocs?)

There are preprocessors that help with this. But of course, you have to 
always remember to compile step to include the preprocessor. And then you 
still have the issue of variable interpolation.. Another thing annoying not 
to have. :)

>In fact, entirely separate frameworks -- from the open source world
>there's WebMacro (www.webmacro.org) and the WebMacro spin-off Velocity
>project (jakarta.apache.org/velocity/), among others -- have sprung up
>to address JSP's deficiencies.
>
>But JSP has hooks in various editors (notably Dreamweaver) and has big
>money (Sun, Oracle, IBM...) behind it. Plus it has a published
>standard and (despite its syntax) is quite extensible.

I agree. It is quite extensible. We racked our heads long and hard last 
June when we started full-on development of open source Java apps as to 
which toolkit to use. In the end, WebMacro and the others have really not 
caught on in a huge way. JSPs are what a lot of developers we interview 
these days do know. So it was easier for us to go with the "standard".

However, keep in mind that JSPs are one part of a generic web application. 
There's still authentication, logging, datasource manipulation, session 
mgmt, resource locking, handling incoming data (form validation, untaint, 
transformation), having a framework to implement model,view,controller (eg 
struts project for Servlets/JSP), etc...

These are the things we spent a lot of up front time developing in Perl and 
then spent 2 man-months porting to Java. And in the end, having this 
toolkit has allowed us to focus on business logic and look-and-feel which 
is what makes one project different from every other project.

Having a solid architecture also helps. It took us 7 years of coding web 
apps in Perl, and then one and a half years of solid work on the latest 
Perl architecture we have. When I say it took us 2 man months to port the 
basic Perl stuff to Java, its not because Java was easier to code but 
because we had already discussed the design decisions to death and 
experimented and made the mistakes already.

A well-specified app is always easier to code regardless of Java or Perl. 
Over the years I've become more of a fan of seeing the benefits of good 
software engineering than really thinking a particular language is a silver 
bullet.

With that said though, I still love Perl.


Reply via email to