I've sent very few emails to this list.  I've gone through the code on my 
own and wrote many test cases.  This list is not very kind to people asking 
newbie questions and most of mine have been very newbie.

Please keep in mind that my target audience is probably different from 
yours.  I'm in an IT shop that has contractors sliding in and out on various 
projects.  Simple, widely used frameworks are the most I can enforce.  
WebSphere 4.0's admin web app is even written in Struts.  I can't tell you 
how much it annoys me not to pick Turbine.  I REALLY like the templating 
system.  I despise the edit-compile-was there an error?-what layer was the 
error in?-edit-compile JSP system.

I know Turbine 2.1 is stable but its not what I need it to be.  That's not a 
fault of Turbine's, it's just my particular needs.  I need to provide my own 
security infrastructure (through WebSphere/Tivoli/LDAP), I need to use 
WebSphere's pooling (the WebSphere admin's are responsible for database 
connectivity and won't mess with app property files), etc.  Turbine 2.2 is 
much closer, especially following all your conversations about pulling out 
the services into a standalone framework, etc.

As to skill level, I don't code to my skill level, I code to others.  I 
don't maintain my code, contract programmers do.  I try to write EXTREMELY 
straight-forward code and use simple models.  They often aren't the best 
solutions but I can explain them in 2-3 Powerpoint slides.  I've written 
elegant solutions to problems in the past and found out 3 months after I 
left that it was thrown out because the requirements changed and nobody 
could understand how it worked well enough to modify it.  The elegant 
solution cost them twice as much as the inelegant one.  I can't tell you how 
many times I've seen eyes glaze over when the object model went beyond a 
handful of objects.  I try to highly segment code into very simple and 
manageable chunks.  I would argue it takes more skill, not less, to do that.

As to the open issue, any code I write that is derivative of Struts or 
Turbine is GPL'd - as far as I'm aware that's the only legal way to do it.  
Will it ever see the light of day outside company walls?  Probably not but 
somebody could walk off with it if they wanted to.  I'm balancing my needs 
against the open source communities needs.  I want to use somebody else's 
code whenever possible.  I want to contribute back whenever possible.

Please feel free to flame me for my opinion but I have nothing but respect 
for the work you do.  I'm extremely impressed by the time and effort you've 
put into Turbine.  If I have something I can add, I will try and do so.  
Unfortunately, most of what I need to do is subtract.

Ted Wise

>From: Jon Stevens <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Turbine-user <[EMAIL PROTECTED]>
>Subject: Re: turbine vs. struts
>Date: Thu, 05 Jul 2001 15:09:08 -0700
>
>on 7/5/01 2:35 PM, "Charles Wise" <[EMAIL PROTECTED]> wrote:
>
> > This'll probably start a flamewar but I'm in exactly the same position.  
>I'm
> > also torn between the two.  I want very much to use Turbine.  I've been
> > lurking on this list for months and playing with Turbine but I've come 
>to
> > the conclusion that I'm going to use Struts.  Here's the reasons:
> >
> > - We're a WebSphere shop.  We're building an enterprise infrastructure
> > including scalability and security.  It ties into WebSphere, Tivoli, 
>etc.
>
>Turbine was originally written on top of WS back when I was doing a gig for
>Novell.
>
> > Turbine is not setup to use anything other then its own internal 
>security
> > and database pool.
>
>If you look, Turbine's connection pool has a wrapper which talks to WL's
>connection pool. You have double pooling of the objects, but there isn't
>much overhead with that.
>
>Also, it depends on how you decide to use Turbine. If you are just
>interested in the Services/Peer frameworks, then there is no similar system
>in Struts.
>
> > - We're a straight IT shop, not a web or product shop.  We get body shop
> > people for many tasks and its hard enough to get quality people let 
>alone
> > train them on Velocity / Turbine.  Using a "standard" like JSP helps to
> > minimize the training and learning curve problem.  You can use JSP with
> > Turbine but as every person who asks a JSP question on the list can tell
> > you, its not well supported.
>
>Yup. We can't beat out the "standard" of JSP...yet. I will talk more about
>that in another month or so if my plan succeeds.
>
> > - Struts is extremely simple to explain and use and performs very well.
> > Turbine is very complex.  I can easily tweak a Struts app logical flow
> > without recompiling and I don't have to track the latest libraries.
>
>Turbine isn't that complex. The complex thing about Turbine is that there
>isn't enough perfect documentation in the world to explain every single way
>to use Turbine.
>
> > - Struts is very stable.  My biggest problem with Turbine is that its a
> > constantly moving target.  The older versions don't meet my requirements 
>and
> > the development version is moving too fast to use (not that that one 
>meets
> > all my requirements either).
>
>We have a released version of Turbine 2.1. What is not stable about that?
>
>I don't have any emails from you suggesting what your "requirements" are.
>
> > - And as a very small nit, you can use normal URLs with Struts.  I'm 
>sorry
> > but telling people to use mod_rewrite is not a solution.  I need to be 
>able
> > to field an installation package to multiple servers w/o having people
> > fiddle around with Apache.  It's hard enough getting things through QA 
>onto
> > the production boxes as it is.
>
>Huh? What is not normal about Turbine urls?
>
>Here is an example url:
>
>http://www.server.com/context/servlet/whatever?foo=bar
>
>This is what any other Servlet would require.
>
> > What Struts is (primarily) missing is:
> > - Layouts
> > - Services
> > - Database layer
> > - Security
> >
> > Security is a wash, I have to authenticate using WebSphere's security to 
>get
> > single sign-on regardless of the approach I take.
> >
> > It's (relatively) easy to write a JNDI datasource object for Turbine but 
>I
> > can't easily rip out the security framework.  I'm also not sure about 
>the
> > Criteria approach.  Instead I'll adapt an extremely simple generator I 
>wrote
> > that produces code very similar to the Peers system.  I've also looked 
>very
> > hard at Castor but I've got problems with its cacheing approach and 
>startup
> > times.
>
>So, you solved the problems yourself instead of contributing them to the
>community. I consider that a proprietary solution that is worth about zero
>for anyone else out there.
>
>Years ago, I did a similar thing and quickly realized that I could try to
>build something that a lot of people would appreciate. That is what Turbine
>is today. If it doesn't do everything you need, then you can help make it 
>do
>so or you can do something on your own and it will most assuredly be custom
>for you and not help out the greater community.
>
> > The services I mostly like but I'll end up writing a simple system to
> > replace that as well.  I don't need most of the complexity in the 
>services
> > framework and I want to simplify the logic.  If you add service
> > dependendency you really don't need the whole early initialization 
>thing.
>
>If you think Services are complex, then I would question your skills. They
>are one of the most basic parts of Turbine.
>
> > Layouts and Velocity I'll simply miss.  I really, really like Velocity 
>and
> > the Turbine layout system.  It's simple, easy and powerful.  None of my 
>JSP
> > alternatives appeal to me.  Instead I'll be relying on JSP includes.
>
>Amazing, you said one nice thing.
>
>-jon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to