You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Nathan Torkington <gn...@frii.com> on 2000/12/13 03:51:03 UTC
Article idea: mod_perl + JSP
I think the 100% Java idea has had its day. Microsoft's .NET is a
tacit admission that in the real world Microsoft will never own 100%
of the market, so let's make things work better together.
In that vein, I'd love to see an article on mod_perl and JSP
cooperating. That is, a website that uses both and admits that each
has its place. I know a lot of people don't like Java (I'm one of
them), but mentioning JSP is the foot in the door to getting mindshare
back from those folks who now think that Java is the only way.
Anyone run such an installation? Anyone want to write about their
setup and experiences?
Nat
JSP taglibs in Perl (was Re: Article idea: mod_perl + JSP)
Posted by Perrin Harkins <pe...@primenet.com>.
> 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.
Template Toolkit is a good way to do something similar in Perl. The obvious
way to use it is in the JSP "Model 2" style, with a mod_perl handler doing
some work and then passing data on to a template for display. However, you
can also use more of a "callback" style, like this:
[% USE prod = product( id => 27 ) %]
[% prod.name %] for only [% prod.price %]
[% FOREACH img = prod.images %]
<IMG SRC=[% img.src %] WIDTH=[% img.width %] HEIGHT=[% img.height %]>
[% END %]
This code will call a method on a perl class to instantiate a new product
object and make it available to the rest of the template. This is very
different from the taglib API, but it sounds like the resulting templates
are pretty similar to the way Extropia uses JSP.
I was part of the original discussion group for JSP, and when the first
public draft was finalized I was rather disappointed that we couldn't get
everyone to agree on a standard taglib for basic conditionals and iterators
with JavaBeans. These are fairly easy to code using the taglib API, but
they just seem so obvious that they should have been included in the spec
rather than having every vendor make their own slight variation.
- Perrin
Re: Article idea: mod_perl + JSP
Posted by brian moseley <bc...@maz.org>.
On Thu, 14 Dec 2000, Chris Winters wrote:
> I think a *really* good Perl person can be faster, but
> that's just a gut instinct. Most of us mortals don't
> qualify.
i used to think that, until i watched a set of really good
*engineers* move quickly inside and between c++, java and
perl. i no longer believe that language experts are the be
all and end all. altho it is nice to have experts in
particular skills - like wrapping things with xs.
Re: Article idea: mod_perl + JSP
Posted by Chris Winters <ch...@cwinters.com>.
* Gunther Birznieks (gunther@extropia.com) [001213 19:50]:
> Well, for me we do Java because I know that there are a couple drivers.
>
> 1) I do know of situations were Java is a better/easier tool.
> 2) For us its not about what is sexy, but what will sell. By the time we
> talk to a company, the debate of Perl vs Java is over and they've already
> spent the money on Java infrastructure or training their guys on Java.
> There is very little commercial benefit for us to tout the benefits of Perl.
<me-too>yep</me-too>
> One of the things I said earlier is that I think that the time it takes a
> good Java guy to develop something vs a good Perl guy seems to be about
> equal in terms of our real experiences (with Java being a bit longer).
I think a *really* good Perl person can be faster, but that's just a
gut instinct. Most of us mortals don't qualify.
> And then when it comes to maintenance (handover) the IT staff of the places
> we deal with are already trained in Java.
This is huge, and the toughest thing to do anything about. Look how
much money (marketing, conferences, magazines, arm-twisting, etc.) it
took for Sun to get on the radar at large corporations, away from (or
in addition to) various other languages. Not that money is the only
thing -- I think Java is a pretty nice language, which helps
acceptance -- but it's a HUGE effort.
> So I guess it's a matter of degree. I simply do love Perl, but I don't hate
> Java, I just merely really like it. I guess you could say I cheat on my
> Perl gf all the time. :) But unlike in life, I don't think a monogamous
> relationship with my language is actually very healthy.
LOL!
> I think Chris' views may be similar.
> ...
Yep, we basically said the same thing -- although mine was a little
more disjointed and less complete :-)
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
Posted by brian moseley <bc...@maz.org>.
On Thu, 14 Dec 2000, Gunther Birznieks wrote:
> So I guess it's a matter of degree. I simply do love
> Perl, but I don't hate Java, I just merely really like
> it. I guess you could say I cheat on my Perl gf all the
> time. :) But unlike in life, I don't think a monogamous
> relationship with my language is actually very healthy.
http://www.polyamory.com/
Re: Article idea: mod_perl + JSP
Posted by Gunther Birznieks <gu...@extropia.com>.
At 03:03 PM 12/13/00 +0000, Greg Cope wrote:
>Chris Winters wrote:
> >
> > * Gunther Birznieks (gunther@extropia.com) [001212 23:53]:
> >
> >
> > > With that said though, I still love Perl.
> >
> > Me too :-) It's frustrating to be doing something in Java that would
> > take a much shorter time in Perl. But then there are things in Java
> > that are simpler than Perl as well.
> >
>
>Appologies if I am butting in - but what you apppear to say here is that
>you are using JAVA because its sex / marketdriods know of it, yet perl
>would be the quicker (and hence cheaper solution ?). Surley for this
>reason you should use perl and persuade the PBH of the cost benefit here
>?
>
>This has hit on a point - in that may people choose Java over Perl
>because its sexier, which becomes self forfilling, unless we (the perl
>community) persaude people that (mod_)perl is sexy....
Well, for me we do Java because I know that there are a couple drivers.
1) I do know of situations were Java is a better/easier tool.
2) For us its not about what is sexy, but what will sell. By the time we
talk to a company, the debate of Perl vs Java is over and they've already
spent the money on Java infrastructure or training their guys on Java.
There is very little commercial benefit for us to tout the benefits of Perl.
One of the things I said earlier is that I think that the time it takes a
good Java guy to develop something vs a good Perl guy seems to be about
equal in terms of our real experiences (with Java being a bit longer).
And then when it comes to maintenance (handover) the IT staff of the places
we deal with are already trained in Java.
So I guess it's a matter of degree. I simply do love Perl, but I don't hate
Java, I just merely really like it. I guess you could say I cheat on my
Perl gf all the time. :) But unlike in life, I don't think a monogamous
relationship with my language is actually very healthy.
I think Chris' views may be similar. When you become a company selling a
commercial product, it's usually SMEs who don't care. Large corporates (If
you want to sell your product for over US$100k) will usually want to see
that it fits within some infrastructural puzzle they've already been
setting up pieces for or plan to set up the pieces for.
The problem is that all the time you save developing in Perl won't matter
if your sales team is going to have a hard time selling it because their
target market will be different.
BTW, I know large corporates and investment banks do use Perl and I've used
Perl in those environments. But while they enjoyed the benefits of rapid
development in-house, when they buy a commercial product with a large price
tag, it raises the profile of the product and many more decision makers
come in. When this happens, it slows down a sale tremendously because no
one wants to choose a "bad product" that "doesn't fit in the big picture"
in front of their peers although they would trust their own in-house
programmer to quickly write something in Perl.
Corporations are always political that way -- It's not a fault of
corporations, large societies just tend to form pockets where people of
like mind flock together and so what is actually normal disagreement among
people with individual ideas tends to get amplified into the phenomena of
politics because in a large society people can't know each other well
enough and it adds a lack of trust to the mix which equals politics.
I may be overloading the meaning of the word politics in this sense. But I
don't think politics means an organization is bad, it's just how societies
work when not everyone knows each other and you have people coming and going.
So it depends on whom you want to target. If you target SME's, I guarantee
you'll scramble to get them to sign off on a 10,000 purchase cuz they watch
every dime. So you work really really hard to make a sale to an SME to show
them value. Large corporates also require this, but they require doing it
to a small committee rather than 1 decision maker. But if it takes 1 month
to make an SME sale at 10k, and 3 months to make a corporate sale at 100k.
It's still more efficient to make the corporate sale and always looks good
on your marketing literature to have a big name than a small name.
Having a big name makes it easier to sell to SMEs too ... "Well, it was
good enough for God, so as an earthly mortal, you should be able to use
this product too and we'll even give you a discount." Wink, wink.
Wow, I just realized I am getting really off topic!
Sorry,
Gunther
Re: Article idea: mod_perl + JSP
Posted by Greg Cope <gr...@rubberplant.freeserve.co.uk>.
Chris Winters wrote:
>
> * Gunther Birznieks (gunther@extropia.com) [001212 23:53]:
>
> > ...
> >
> > 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.
>
> Yes -- it really comes down to what a company uses already and what
> it's being used for. My company is developing from scratch a web-based
> front end to a Visual Basic/SQL Server application. We could certainly
> do it faster in Perl (that's just because our Perl background is much
> stronger than our Java background), but having a Java-based solution
> is sexier and therefore more marketable than a Perl-based
> solution. (We are in business to make money, after all.) Is that a
> legitimate reason? I think so, but it's certainly a grey area.
>
> > With that said though, I still love Perl.
>
> Me too :-) It's frustrating to be doing something in Java that would
> take a much shorter time in Perl. But then there are things in Java
> that are simpler than Perl as well.
>
Appologies if I am butting in - but what you apppear to say here is that
you are using JAVA because its sex / marketdriods know of it, yet perl
would be the quicker (and hence cheaper solution ?). Surley for this
reason you should use perl and persuade the PBH of the cost benefit here
?
This has hit on a point - in that may people choose Java over Perl
because its sexier, which becomes self forfilling, unless we (the perl
community) persaude people that (mod_)perl is sexy....
Greg
>
> Chris
>
> --
> Chris Winters (chris@cwinters.com)
> Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
Posted by Chris Winters <ch...@cwinters.com>.
* Gunther Birznieks (gunther@extropia.com) [001212 23:53]:
>
> 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.
<me_too>yup.</me_too>
> Ah but have you looked at taglibs? We rarely ever put Java processing on
> the page itself.
I have, but they seemed more complex than was necessary --
particularly for explaining what's what to a graphical designer. I
will take your experience to heart, however, and give them a second
look :-)
>...
>
> As for logic in a JSP... Well, the above is an example of something where
> you need code for the display to work well.
I just find it annoying that simple things like loops and such are not
as easy as they should be -- Perl (and the Template Toolkit) have
trained me well :-) This is part of what initially drew me to WebMacro
-- that, plus the author's insistence on a forcible separation between
presentation and logic. Leaving the door open to executing Java (or
Perl for that matter) within a page means that someone will walk
through it and start writing mini-programs in the template because
it's "easy", leaving (IMO) an unmaintable mess.
> 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.
Sure -- I tend to break things down like this as well. (The
OpenInteract framework does this, although the second and the third
tend to blend together.)
> 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.
Again, I'll trust your experience.
> 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.
Makes sense.
> 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.
This is everyone's aim, I think. Finding the right balance and
applying it for the vast majority of users in the templating language
is very difficult -- although there are probably sufficiently many
templating languages to suit you depending on the balance you
personally would like to strike :-)
> 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. :)
Yep, I don't want to even go there.
> 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".
Also another important point, although good programmers can pick up
anything -- and a templating language is on the simpler side of things.
> 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...
Oh, yeah, absolutely.
> ...
>
> 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.
Yes -- it really comes down to what a company uses already and what
it's being used for. My company is developing from scratch a web-based
front end to a Visual Basic/SQL Server application. We could certainly
do it faster in Perl (that's just because our Perl background is much
stronger than our Java background), but having a Java-based solution
is sexier and therefore more marketable than a Perl-based
solution. (We are in business to make money, after all.) Is that a
legitimate reason? I think so, but it's certainly a grey area.
> With that said though, I still love Perl.
Me too :-) It's frustrating to be doing something in Java that would
take a much shorter time in Perl. But then there are things in Java
that are simpler than Perl as well.
Why is this (more or less) on-topic for mod_perl? Because you need to
know your competitors. The stuff I've learned from Servlets, J2EE and
(to a lesser extent) JSP will be making its way into the OpenInteract
application server in the next couple of months. There's quite a bit
of cross-pollenation that we can do and because Java is so well-known
and marketable, I think it's important to talk intelligently about
both.
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
RE: Article idea: mod_perl + JSP
Posted by Ed Park <ep...@athenahealth.com>.
I've been thinking about this quite a bit recently.
I agree with Gunther-- what is more important is not really the language
that you use, but the high-level application framework you have built for
yourself and how you use it. This is because most of the essential elements
of any framework can be duplicated in any reasonably powerful programming
language (mod_perl, java, tcl, even VBScript/VB to some extent).
That said, my own experience and benchmarking showed that mod_perl is the
best of these architectures for building extremely high-quality, reliable,
_complicated_ 3-tier Internet applications in which the prototyping and
release cycle are very highly compressed, because I can write the most
high-quality, high-speed code per unit time in Perl. By 3-tier apps, I mean
apps consisting of a browser, the app server (mod_perl), and an RDBMS.
Perl doesn't have much support in the way of n-tier apps, which is why I
find Nathan's question interesting, and why I have been thinking about it
recently. From some recent experiences with using SOAP to integrate with an
outside vendor, I believe that it is possible to create a best-of-breed
n-tier solution using Perl as the glue layer. For those of you who don't
know what SOAP is, it's essentially RPC over XML, and allows any app to talk
to any other app in a standard, XML-based format. Go to
http://www.soaplite.com for a very clean implementation of SOAP for Perl.
To continue-- there are a few reasons that you might want to use Java as a
component of a mod_perl app:
-There are sometimes pre-written components for Java that you'd like to use
because a vendor has written pre-specified hooks for Java. This could also
be the case in which you have to integrate with any legacy systems.
-Java has much better support for threading, and therefore in many cases
makes a much better server (the simple example for this is a chat server).
-Because of Java's threads, it can pool transactions resources (e.g.
databases) better, and may therefore be more efficient in places where
resources are tightly constrained, _especially_ if the database is queried
relatively infrequently.
For similar reasons, you might want to use a VB component in your
application, etc. SOAP makes that possible.
The point here is that I think that an awful lot of folks out there have
straitjacketed themselves into thinking that if there's a complicated
problem that needs to be solved, and there's a piece of that problem is best
done in Java, then we ought to write the whole thing in Java. What I'm
saying is that that's not necessarily true-- that it's actually possible to
write best-of-breed solutions by introducing a communications-layer
abstraction that enables you to build a clean n-tier architecture. CORBA
promised this, but was sufficently difficult to implement because it has not
(to my knowledge) gained very wide acceptance in the Perl community. Also,
the major ORBs (IONA, Visigenic) have largely overlooked creating Perl
bindings for theri apps. SOAP, however, makes distributed computing
extremely easy and _very_ clean, and I think that it could change the way
that people think about building complicated, high-quality applications in
an extremely compressed timecycle.
Using SOAP actually opens a number of other possibilities that don't require
thinking outside of mod_perl, too. For example, one of the big selling
points of Java is that it allows horizontal partitioning of classes on
different machines. Using SOAP, you can actually partition your _perl_ logic
so that different pieces run on different machines; or, you can write a
component in Perl that is subsequently called by a Java component.
OK, enough of my rambling...
cheers,
Ed
-----Original Message-----
From: Gunther Birznieks [mailto:gunther@extropia.com]
Sent: Tuesday, December 12, 2000 11:42 PM
To: Chris Winters; Nathan Torkington
Cc: modperl@apache.org
Subject: Re: Article idea: mod_perl + JSP
At 11:11 PM 12/12/2000 -0500, Chris Winters wrote:
>* Nathan Torkington (gnat@frii.com) [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.
Re: Article idea: mod_perl + JSP
Posted by Gunther Birznieks <gu...@extropia.com>.
At 11:11 PM 12/12/2000 -0500, Chris Winters wrote:
>* Nathan Torkington (gnat@frii.com) [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.
Re: Article idea: mod_perl + JSP
Posted by Chris Winters <ch...@cwinters.com>.
* Nathan Torkington (gnat@frii.com) [001212 22:09]:
> I think the 100% Java idea has had its day. Microsoft's .NET is a
> tacit admission that in the real world Microsoft will never own 100%
> of the market, so let's make things work better together.
>
> In that vein, I'd love to see an article on mod_perl and JSP
> cooperating. That is, a website that uses both and admits that each
> has its place. I know a lot of people don't like Java (I'm one of
> them), but mentioning JSP is the foot in the door to getting mindshare
> back from those folks who now think that Java is the only way.
>
> Anyone run such an installation? Anyone want to write about their
> setup and experiences?
>
> Nat
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.
(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?)
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.
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
Re: Article idea: mod_perl + JSP
Posted by Nathan Torkington <gn...@frii.com>.
Perrin Harkins writes:
> Anyway, I think a better approach for getting attention from Java-minded
> people is to demonstrate that there are well-designed, carefully
> engineered sites being built in mod_perl. Most of the articles I see
> about Perl tend to play up the "quick hack" aspect, and ignore things like
> OO design, maintainability, and scalability. Those things are the stock
> in trade of Java articles, as a quick look through Java World will show.
That's an offer of an article? :-)
Nat
Re: Article idea: mod_perl + JSP
Posted by Perrin Harkins <pe...@primenet.com>.
On Tue, 12 Dec 2000, Nathan Torkington wrote:
> In that vein, I'd love to see an article on mod_perl and JSP
> cooperating. That is, a website that uses both and admits that each
> has its place. I know a lot of people don't like Java (I'm one of
> them), but mentioning JSP is the foot in the door to getting mindshare
> back from those folks who now think that Java is the only way.
I'd be surprised if many people do this. Companies that have both
probably consider one or the other a legacy system or a totally separate
project.
The only web project I've heard of where Perl and Java were really being
used together on the server side was one that Gunther described, with a
mod_perl front-end talking SOAP to a server running application logic in
Java.
Anyway, I think a better approach for getting attention from Java-minded
people is to demonstrate that there are well-designed, carefully
engineered sites being built in mod_perl. Most of the articles I see
about Perl tend to play up the "quick hack" aspect, and ignore things like
OO design, maintainability, and scalability. Those things are the stock
in trade of Java articles, as a quick look through Java World will show.
- Perrin