Pull tools and access classes

[Scott Eade <se...@backstagetech.com.au>]

In the proposals directory of the trunk I have sitting there some 
enhancements to the UI pull tool.

Rather than just a pull tool I have implemented a service, since this 
makes it more practical to provide a class that implements static 
accessor methods to get at the skinning data from within action classes 
as well as in templates (via a pull tool).

If this was to be converted over to a fulcrum component, where would the 
turbine specific code (the pull tool and the static accessor class) go?  
I suggest that once we have the maven 2 build system in place these 
types of classes could actually remain with turbine and the fulcrum 
dependency could be listed as being optional.  Does this sound 
reasonable or does anyone else have a better suggestion?

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Pull tools and access classes

[Peter Courcoux <pe...@courcoux.biz>]

Hi Scott,

I have given this some thought over the last couple of years as I am 
using Turbine in one of my applications without using Velocity or Pull 
Tools (I am plugging in a page building service, based on an XML 
Document object, via the pipeline). My view is that it would be very 
nice to pull out all the Template Service code, template and action 
classes etc into separate fulcrum services and leave Turbine itself as 
clean as possible, with as few dependencies as possible.

I think that this can be done, but it would mean a change of package 
names for classes often used by applications built on top. For this 
reason I think that it would need a major release (say Turbine 4.0) to 
add this.

Ideally, I see Turbine itself as the main servlet, the pipeline and 
utilities, together with a service framework which can utilize services 
and components written for a variety of component frameworks, including 
YAAFI, Spring and osgi. Services can then be plugged in via the pipeline 
as required. Doing this should enable us to continue to support 
applications using the current version of Turbine while allowing 
interested developers to push forward with innovations.

Regards,

Peter




Scott Eade wrote:
> In the proposals directory of the trunk I have sitting there some 
> enhancements to the UI pull tool.
>
> Rather than just a pull tool I have implemented a service, since this 
> makes it more practical to provide a class that implements static 
> accessor methods to get at the skinning data from within action 
> classes as well as in templates (via a pull tool).
>
> If this was to be converted over to a fulcrum component, where would 
> the turbine specific code (the pull tool and the static accessor 
> class) go?  I suggest that once we have the maven 2 build system in 
> place these types of classes could actually remain with turbine and 
> the fulcrum dependency could be listed as being optional.  Does this 
> sound reasonable or does anyone else have a better suggestion?
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Pull tools and access classes

[Thomas Vandahl <tv...@apache.org>]

Scott Eade wrote:
> In the proposals directory of the trunk I have sitting there some
> enhancements to the UI pull tool.
> 
> Rather than just a pull tool I have implemented a service, since this
> makes it more practical to provide a class that implements static
> accessor methods to get at the skinning data from within action classes
> as well as in templates (via a pull tool).
> 
> If this was to be converted over to a fulcrum component, where would the
> turbine specific code (the pull tool and the static accessor class) go? 
> I suggest that once we have the maven 2 build system in place these
> types of classes could actually remain with turbine and the fulcrum
> dependency could be listed as being optional.  Does this sound
> reasonable or does anyone else have a better suggestion?

For components I write I usually place the static accessor class into
the same package as the service interface, because it not actually
Turbine specific code. The pull tool is then placed in a .turbine
package in my application code. So I'd propose to keep the pull tool
with Turbine and everything else in the Fulcrum repository.


Just my two cents.

Bye, Thomas.

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org