Leon Messerschmidt wrote:
>
> Hi,
>
> I propose we change the ScreenLoader class to enable multiple screen source
> (Python, Rhino, Java, Whatever).
What about Navigations and Actions? I think it makes perfect sense to be
able to write those in JPython too.
> 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
This looks good, We have ScreenLoader as before, but it delegates functionality
to multiple screen factories. I like that, but think about making it more
general, to include Actions and Navigations as well. One possiblility is to
make NavigationLoader and ActionLoader delegate to the factories as well,
and create an entity (a Service, presumably) that would manage the factories.
public interface AssemblerFactory
{
public Assembler getAssembler( String name );
}
public interface AssemblerFactoryManager
{
public static final String ACTION_TYPE = "action";
public static final String SCREEN_TYPE = "screen";
public static final String NAVIGATION_TYPE = "navigation";
public void registerFactory( String type, AssemblerFactory factory );
public Assembler getAssembler( String type, String name );
}
getAssembler method would query the factories registered for the
specified type, in the order that they were registered at system startup,
until one of them returns a non-null value, or there are no more registered
factories.
> 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?
I think it is. If you define multiple factories, you should be able to define
precedence also. For example, you can gradualy replace your JPython screens with
Java ones as your system matures, giving JavaScreenFactory preference over
JPythonScreenFactory. When there are no more JPython screens used, you remove
the factory and all JPython sources at once.
> 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.
I see the following similarities to a service:
1. Encapsulates a set of related functionality, and configuration options
2. Implementation should follow Singleton pattern to provide single point of access
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
