Active Zones Implementation Ideas
Information
These are some possible ideas for implementing Portal Active Zones.
Using a bean collector method
- Using a bean collector would allow the portal to simply define an interface (or two) which the developer would implement
- The bean collector will pick up the implemented interfaces if the set themselves to AutoRegister
- It will also allow for optional ordering based on a priority number
- Possible interfaces
- Interface for the zone provider (defines the content and location to put it in the portal)
public interface PortalZoneProvider { /** * Defines the zones which this provider will affect, * all zone ids listed will have their content added/controlled by this provider * @return an array of portal zone ids */ public String[] getZoneIds(); /** * Gets the html fragment to place into the zone(s) handled by this provider * @return a string representing an html fragment or null if we have none to add at this time */ public String getHtmlFragment(); }
- Interface for the overrider (allows this provider to be the sole provider for this zone based on priority)
public interface PortalZoneOverrider extends PortalZoneProvider { /** * Allows this provider to override all other content and replace it with its own content * @return true to override content and stop going through the providers for this zone or false to * handle like normal (add content from this provider to what is there in order by priority) */ boolean getOverrideContent(); }
- Interface for the suppressor (causes the zone to be completely suppressed and not even be rendered on screen at all, this is the same effect as having no content in the zone but this will allow the zone to be supressed even if there is content)
public interface PortalZoneSuppressor extends PortalZoneProvider { /** * Causes the zone to be completely suppressed and not even be rendered on screen at all * if the return is true, this will also stop processing for this zone and will skip the * remaining providers for this zone * @return true to suppress this zone, false to continue normal processing */ public boolean getSuppressZone(); }
- Interface for the zone provider (defines the content and location to put it in the portal)
- The bean collector would need to also have something along with it (like what Ian suggests below) which will allow for manual registration, this would probably some kind of service which handles the registration and keeps track of the providers
- The service would be consulted as the portal is rendered to see
Ideas from Ian B on sakai-dev
The major difference is that this does not have an autoregister via spring and passes the context instead of the fragment itself, overall this is a great idea and if we join the best parts of these suggestions we should have a usable and fairly simple to implement solution
It would be a simple addition to the current portal to allow anything to register an interface implementation with the portal that would be given some information (eg request object or something smaller) and deliver "" or a block of markup to be added into the area. The tools might also want to deliver content. The interface might have one method. interface FragmentProducer { String getFragment(FragmentContext context); } where FragmentContext is the thing that holds enough of the request environment to be useful. The register might be void registerFragentProducer(FragmentProducer producer, String zone, int priority); where zone is the named portal zone and priority gives some order. If the tool implements interface ZoneFragmentProducer { String getFragment(FragmentContext context, String zone); } it would be invoked for each zone in the portal. The fragments once collected, would be injected into the RequestContext and available to the RenderEngine to layout at will. The template in use would register available zones (as it does currently for capabilities in the current templates).