Using Turbine's controller with Velocity

[Justin Patterson <ju...@head-gear.com>]

Hey...

I'm evaluating Turbine for use in a commercial product.  We only need the controller portion of Turbine along with the Velocity integration.  We already have an in-house application framework for things like connection pooling and a lot of the utilities.  The problem is that my company has a policy of building all the third party code that we ship so that we can patch and rebuild on a moment's notice -- knowing exactly what has changed.

While I see a lot of references to not using all of Turbine if you don't want to on the web page, I haven't been able to find an easy way to build just the controller.  I found the source, but there were no build files.  I couldn't just build all of the classes because there are a lot of integrations with other packages that I don't need.  I don't want to check all those dependencies into our source control, since we won't be using the integrations anyway.  I don't need Torque.  I don't want to use Turbine's security model, etc.

Is there some clean separation between the core of Turbine's controller and the integration plug-ins?  Am I the only person who has ever wanted this?

I imagine that I can go through class by class and remove the ones that I'm not planning on using before compiling, but I wanted to do something cleaner so that it will be easier for me to pull in new versions of the codeas they're released.

Thanks for your help!
-Justin

Re: Using Turbine's controller with Velocity

[David Worms <da...@simpledesign.com>]

My guess is that you might be better using turbine 3. I am personally 
using this version, as some other in the list, and everyone agree to 
say it is stable. You will gain a clean separation between the 
framework and the services ( fulcrum ).

David

On Wednesday, October 23, 2002, at 09:31  AM, Justin Patterson wrote:

> Hey...
>
> I'm evaluating Turbine for use in a commercial product.  We only need 
> the controller portion of Turbine along with the Velocity integration. 
>  We already have an in-house application framework for things like 
> connection pooling and a lot of the utilities.  The problem is that my 
> company has a policy of building all the third party code that we ship 
> so that we can patch and rebuild on a moment's notice -- knowing 
> exactly what has changed.
>
> While I see a lot of references to not using all of Turbine if you 
> don't want to on the web page, I haven't been able to find an easy way 
> to build just the controller.  I found the source, but there were no 
> build files.  I couldn't just build all of the classes because there 
> are a lot of integrations with other packages that I don't need.  I 
> don't want to check all those dependencies into our source control, 
> since we won't be using the integrations anyway.  I don't need Torque. 
>  I don't want to use Turbine's security model, etc.
>
> Is there some clean separation between the core of Turbine's 
> controller and the integration plug-ins?  Am I the only person who has 
> ever wanted this?
>
> I imagine that I can go through class by class and remove the ones 
> that I'm not planning on using before compiling, but I wanted to do 
> something cleaner so that it will be easier for me to pull in new 
> versions of the codeas they're released.
>
> Thanks for your help!
> -Justin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Using Turbine's controller with Velocity

[Chris K Chew <ch...@fenetics.com>]

Turbine 2.x is awfully coupled to its components (called "Services") such as
Torque and the SecurityService.  You might be better off to familiarize
yourself with the code and extract the screen/action pieces you need
(altering them to remove the component requirements).

Turbine 3, and the recent Plexus are geared towards a true decoupling of the
model, view and controller.  You might want to peruse the list archives for
recent strands describing this effort and their current status.  Basically
Turbine 3 uses a framework called Fulcrum (a turbine sub-project), and
Plexus uses Avalon (A jarkarta project), and both are unofficially stable
but successfully used in production environments.  There does not seem to be
much argument against Avalon being superior, and Plexus looks pretty neat at
first glance.  You might also have to migrate your components to avalon in
order to use Plexus, but I am already speaking over my head.  From what I
understand of Avalon, this could possible be worth it anyways.

Don't get me wrong, I love turbine and it makes my life as a webapp
developer much easier, but if you already have a framework for many
components you will have fat in duplicated components that you can't get rid
of in turbine 2.x.

Chris

-----Original Message-----
From: Justin Patterson [mailto:justinp@head-gear.com]
Sent: Wednesday, October 23, 2002 10:32 AM
To: turbine-user@jakarta.apache.org
Subject: Using Turbine's controller with Velocity


Hey...

I'm evaluating Turbine for use in a commercial product.  We only need the
controller portion of Turbine along with the Velocity integration.  We
already have an in-house application framework for things like connection
pooling and a lot of the utilities.  The problem is that my company has a
policy of building all the third party code that we ship so that we can
patch and rebuild on a moment's notice -- knowing exactly what has changed.

While I see a lot of references to not using all of Turbine if you don't
want to on the web page, I haven't been able to find an easy way to build
just the controller.  I found the source, but there were no build files.  I
couldn't just build all of the classes because there are a lot of
integrations with other packages that I don't need.  I don't want to check
all those dependencies into our source control, since we won't be using the
integrations anyway.  I don't need Torque.  I don't want to use Turbine's
security model, etc.

Is there some clean separation between the core of Turbine's controller and
the integration plug-ins?  Am I the only person who has ever wanted this?

I imagine that I can go through class by class and remove the ones that I'm
not planning on using before compiling, but I wanted to do something cleaner
so that it will be easier for me to pull in new versions of the codeas
they're released.

Thanks for your help!
-Justin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>