* Gunther Birznieks ([EMAIL PROTECTED]) [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 ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
