Turbine

Essentials

Models

Get Involved

Documentation

Database

i18n

  • Messages that turbine outputs should live in a resource bundles, not in in TR.props
  • Template lookups depending on locale (Is Ilkka working on that?)

Sub-Applications

  • Separate template/module namespaces for diffent sub-applications.
  • Extension do DynamicURI and derivates to support new parameter (sub-application selector)
  • Sub Application configuration issues.
  • Loading sub-application from jar files.
  • Deployment/undeployment of sub-applications - runtime or not?

Service framework

  • Simplify initialization sequence - no more init(Object), just start(), init(), shutdown()
  • system property repository in the broker, for the services that *really* need to use ServletConfig or RunData
  • getRealPath/getResourceAsStream for the use in the services in the broker
  • initialization of the broker needs to be refactored - logic for that should moved from TurbineServices into BaseServiceBroker

Resource Service

  • clean up property names so that dot is used as namespace separator, not as a space character replacement examples:
    services.GlobalCacheService.cache.check.frequecy should be:
    services.GlobalCacheService.cachCheckFrequency
    services.PullService.tools.per.request.refresh should be:
    services.PullService.toolsPerRequestRefresh

    if we do the above, it would be easy to map the dot separated property names onto a DOM tree or a JNDI namespace. These two alternative ResourceService implementation would be a nice addition to Turbine.

Security Service

  • UserManager should become a service in it's own right
  • ACL mechanism should become pluggable. A new interface ACLBuilder must be defined, the interface would have single method of 'Object buildACL(User)' signature. UserManagerService would have a property that would contain *service name* that implements ACLBuilder. buildACL will be an instance not class method, so a concrete instance of the service must be consulted.
  • User object will have method of 'Object getACL()' signature that will delegate to UserManagerService, which in turn delegates to the configured ACLBuilder. It's OK to cache the returned object, since the ACLBuilder will keep references ACL objects internally, to reflect the changes of sercurity information at runtime.
  • TurbineSecurityService will be the default ACLBuilder shipped with the system.
  • TurbineSecurityService should have it's OM/Peer classes Torque generated
  • Group should be could be renamed to 'Realm' or 'Domain'. This should decrease the confusion about it's meaning
  • Attributes of Roles/Groups/Permissions will be dropped. I don't think the idea catched on.
  • User attributes should be moved into a seaprate table, or even two tables if we want to store meta information for user attributes. This will require a customized Peer class for User objects, but this will be easy with recent Torque's two-level class generation
  • On session unbind event, only acces counters/timestamps should be updated not the whole data. This should fix the overriding of admin's changes by the unbound session problems. The information which attributes should be updated could be placed in user attribute meta-information table.

Naming service

  • this service is rater outdated, it needs some cleanup, and adding suppport for DirContexts (low priority, might be useful in creating LDAP User Manager / Security Service implementations)

XSLT Service

  • support for processing of DOM trees present in memory could be useful (right now both data and stylesheet are read from disk files)

Scheduler Service

  • implementaions independent of DB/Peers should be added. An xml based implementation seems easy and useable.

Reusable Components

  • facilities for presenation of tabular data, with the ability to do paging, filtering and sorting
  • date selection component (skinnable calendar with year/month/week views in a popup window, includes some JS)

Browser window bound application context

  • SessionContext interface similar to that of ServletSession
  • getGlobalContext() and getLocalContext() methods in RunData
  • objects stored in local context must be Cloneable (they will be cloned per every hit. A configurable number of local contexts will be kept, so that user may continue a sub-session from an alternate window)
  • those will not interfere with normal usage of Servlet session

Peers

  • Criteria should not extend Hashtable. This is widely considered to be a bad practice. Even if criteria is to maintain hashtable-like semantics, it should do so by delegation not derivation.

Parameter parser and its ilk

  • clean up and orthogonalize APIs (add vs append vs set)
  • what the heck is uploadData? I think UploadService/FileItems do the trick just fine
  • BaseValueParser should not extend RecyclableSupport. If I understand the pattern correctly, it should include an instance of RecyclableSupport and delegate Recyclable interface method to it. The same goes for TurbineDefaultRunData. To prevent people from doing that RecyclableSupport should not implement Recyclable itself. AFAIK, this kind of apprach is used to emulate multiple inheritance in Java. I'd appreciate a comment on this issue from Ilkka.

Core Processing

  • Begone, ECS! We want ECS to dissappear completly from Turbine. Instead of Elements, modules should pass Strings around.
  • the inheritance hierarchy of modules - if you look at the class diagram, you'll notice that it looks rather ugly.

Renaming and reordering

  • 2.2 will be a good moment to rename, and move classes around.
  • WebMacroSite classes could be renamed to just WebMacro
  • some utility classes could be moved into service packages, to decerease the crazy number of packages we have, and help better hermetisation of code with package accesible fields/methods.


Copyright © 1999-2001, Apache Software Foundation