This roadmap is divided in two parts, Nukes 2.0 Developer Release (23 September of 2004) and Nukes 2.0 Alpha (December of 2004).
-
Nukes 2.0 Developer Release
PortalContainer :
Property management :
DONE - Define a set of interface that can have several implementations
DONE - Basic implementation, in memory
JSR-168 implementation
DONE - TCK compliance (for TC4, some test are not passing on TC5)
DONE 2 days - Look at the security stuff
DONE 3 days - Implement preferences on top component properties
DONE 3 days - Custom client properties per component. I don't know if that should be part
of the portal container or Nukes yet. This part is rather complicated because
several sources for properties needs to be aggregated (portal,component,user,group)
and need some kind of layered approach with some rules to compute the returned value.
At least the API to retrieve these properties needs to be defined by the PortalContainer.
DONE 2 days - Improve web application interception : works for TC4 and TC5
DONE Put basic portlet examples
Document the release : usage and architecture
DONE 2 days - Basic theme
DONE 2 days - Convert to JBoss-4.x : there are minor problem with
DONE 9 days - Decide which component are displayed ? do we need to introduce a page concept ?
For now in Nukes 1.x the algorithm is : in the center render the target module
then take all the blocks, remove the block the user cannot see and display everything.
This has is sufficient for Nukes 1.x but is too simplistic for advanced scenarios.
-
Nukes 2.0 AlphaBeta
2 days - Fetch config from tomcat connectors, the portal needs to know what are the ports (HTTP and HTTPS).
4 days - User/Group :
Reimplement persistence with hibernate
User defined properties
Group defined properties
2 day - Security :
Move the security from the module object to the request object.
8 days
Existing modules : Either convert the modules to the portlet format or modify the current and improve
the current Nukes 1.x custom API
Reimplement Nukes interface (Page object) based on the component framework or define a new set
of intefaces similar to portlet.
Improve the security management. I believe that the current Nukes authorization
mechanism is ok though it needs some fixes but the authentication needs to be
switched on JAAS. See how this would be possible with servlets and single sign on.
Define a theme API : The Portal Container will procude during an invocation a result
which is a set of page fragment. These page fragment will all inherit the same class
but will have various custom properties (for instance a Portlet window has a PortletMode).
We need to find the right architecture for theming here. A fragment should be rendered
on screen by a general mechanism and let room for customized renderers.
Assignee : Roy
Define a mechanism to allow component to specify a custom stylesheet during a request.
JSR-168 implementation
Finish JSR-168 implementations :
PLT.5.2.4.4 Exceptions During Request Handling : temporary unavailability
PLT.8.4 Custom Portlet Modes : map these to something
PLT.9.4 Custom Window States : map these to something
PLT.11.2.1 : Retrieving Uploaded Data : look at it
PLT.12.3.4 : Namespace encoding : all
PLT.14.3.1 : Localizing Preferences Attributes : look at it
PLT.17.1 : Defining User Attributes : look at it
DONE PLT.18 Caching
PLT.20.4 Specifying Security Constraints : all
-
Sometime later
Instance distribution
Extract the text rendering framework from Nukes 1.x, make it an independant module (maybe project).
Consider to release it as standalone.
Define an invocation pipeline at the application level. Ideally Nukes components
should use that pipeline.
The pipeline has interceptors applied locally and globally
and handle orthognal aspects of the application. In the pipeline we push application
commands (see the gof Command pattern). This is how it works today for the forum and the HTML
module. For instance for the forums the applied concerns are the mail notifications, the search
engine index modifications etc... The goal here would be to have global interceptors configured to
react on application events.
Allow command invocation by other mechanism than HTTP request. For instance the Nukes 1.x
integration with JBossMailServer will use the ReplyCommand to create a reply to a post.
Finish JBossMail/BB integration
Comments