[OT/Long] Re: [PATCH] ResourceManager.java and VelocityServlet.java

[Christoph Reck <Ch...@dlr.de>]

Hi everyone, hi Jon,

Jon Stevens wrote:
> on 1/31/01 1:20 PM, "Daniel Rall" <dl...@collab.net> wrote:
> > Ditto.  We'd appreciate help making Turbine a better "out of the box"
> > experience, however.  At CollabNet, we use only selected pieces of
> > Tubine, and have no problem configuring it as such (meaning you don't
> > have to use *all* its functionality).
> 
> In fact, that is a goal of Turbine. I don't mind seeing someone using
> Turbine within *their* own framework and in fact, I encourage it.
> 
> However, putting a framework into the Velocity project is well beyond the
> goals of the Velocity project and therefore, I would be -1 on that.
> 
> -jon

I have not designed a framework, it is a simple Velocity 
application! The patch on the VelocityServlet.java simplifies 
making applications by inheritance and avoids duplication 
(copy-and-pase of) this core functionality.

I did not mean to attack turbine, nor offend anyone of its
contributors. I just stated that I do not see a release within
many weeks, and that the interfaces and configuration are still 
changing (too much) to base a application on it that needs to be 
released soon. I've been on the turbine list since early last 
year and tried to contribute some. But my application is simple
and I greatly welcomed the Velocity initiative (to be simpler,
cleaner, stabler and easyer to contribute to). I need to release
within 4 weeks!

Since august I have been using Turbine as the base, used one
single Default.java screen to populate the basic pull-model.
In november I tried to go to Vel, but it was not ready yet,
I reported some bugs (since Geir was working in this area it
would have been double work do provide fixes) and finally in
Dec/Jan I completely ans sucessfully went to Velocity. Now I'm
providing patches to fix the bugs I'm encountering.

Turbine is a great framework for complex applications. But 
most current contributions are in areas I don't have a need. 
Many developers just need a simple tool as velocity to create 
their dynamic content. No need of DB, Scheduling, pluggable 
screen engine, etc.. They could use PHP, JSP/Servlets, 
ECS+Servlets, Cocoon, WM, etc., but the simplicity and power
of Velocity beats them. They do normally need session, ACL, 
action handling as well as utilities as the DynamicURI, 
ParameterParser, etc., the first things are part of the Servlet
API and the latter is deeply rooted into turbine (I cloned
and cleaned the PP&Link to be able to use them in my standalone 
velocity application).

I see the non-XML syntax of Velocity an advantage against JSP,
Tea, Bishop, and WebWork. All these projects are adressing
less complex areas than Turbine. As some postings state, many
users admire the features of some services, and would like them
to be usable outside of Turbine (Torque/Peer, Intake, Scheduler,
Log, DynamicURI, ParameterParser, CookieTool, etc). So the goal 
for Turbine is to get a relase asap (the path till there has 
found a consensus in the turbine list) and then work on getting 
the services more indpendent following the pattern of Avalon. 
Make the framework components independent of turbine, and make
Turbine the Servlet-framework for Avalon!

If my next project allows me to, I will contribute in the
re-engineering required to make turbine services into Avalon
blocks, if this path is agreed upon by the committers. Maybe
Turbine could influence Avalon with some better/newer ideas?

Jon, please no ofense, but you need to be somewhat more
diplomatic dealing/writing with other people. I believe many
users got scared at some of your replies and postings. It 
reflects either preasure, fanatism, low-level, or frustration;
this will keep people scared from you and others not to take
you fully seriosly. You have good views and are coaching the
team well, but have not accepted that others may have diferent 
(worng?) views. You are not willing to modify/drop turbine in 
favour of any other framework, so do others with theirs - 
everyone has project presures and it this would cause more 
delays. After a project there are allways lessons-learned and 
a new iteration for the next. If turbine provides good 
independent services, these can be used by others, brings in 
more contributors, and avoids re-inventing same things.

I myself have made a simple MVC application based on Velocity
using VTL to configure and run the controller and VTL to render 
the view. Some context tools are there to instantiate the pull
model within the controller, which also decodes and performs
the actions. Since speed is not a primary requirement, this
approach is simple, flexible, powerfull and easy to use/learn.

I already agreed with Geir that this should not be part of 
the Velocity core. Somewhere we will create a location for 
(unsupported) contributions for things like this.

:) Chirstoph