Leon Messerschmidt wrote:
>
> Hi,
>
> I propose we change the ScreenLoader class to enable multiple screen source
> (Python, Rhino, Java, Whatever).
>
> What I have in mind is to keep the interface to the ScreenLoader class
> as-is, but we change the implementation to load screens from 1 or more
> screen factories. ScreenLoader will still take care of screen caching. It
> should probably also cache screen factories.
>
> A screen factory will need to implement a ScreenFactory interface:
>
> public interface ScreenFactory
> {
> Screen getScreen (String name);
> // Anybody have suggestions for useful methods?
> }
>
> To enable a screen factory we define it in the TR.properties like so:
>
> #property name?
> screen.loader.factory=org.apache.turbine.modules.factories.JavaScreenFactory
> screen.loader.factory=org.apache.turbine.modules.factories.PythonScreenFacto
> ry
> screen.loader.factory=org.apache.turbine.modules.factories.RhinoScreenFactor
> y
>
> Will the order in which screens are loaded be of any relevance? If you have
> the same screen in both Java and Rhino code which one will be loaded, or do
> we assume that a screen will be unique over screen loaders?
>
> Should we maybe implement ScreenLoader as a Service? I thought of this, but
> I don't think that ScreenLoader fits the description of a service, and that
> we should only make the changes suggested above.
>
> Any other thoughts/comments on this?
This is looking much better. I don't see why the ScreenLoader wouldn't
be implemented as a Service. I'm betting Rafal has an opinion on this.
:)
--
Daniel Rall <[EMAIL PROTECTED]>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
