portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl Luta <raphael.l...@networks.groupvu.com>
Subject Re: Security stuff...
Date Wed, 13 Jun 2001 08:53:02 GMT
David Sean Taylor wrote:

>>Because a complete pull design would populate the context by reading the
> objects to instanciate from a configuration info, so you would not have to
>>explicitely put it the context.
>>An the other hand, Jetspeed does not currently offer a good pull system
>>for portlets: you can use the Turbine pull system within your system but
>>it's bad because the defintion are global for all the application and not
>>portlet specific (and you need to stop restart your app for adding new
>>tools definition which is not adequate for portlet deployment)
>>I started implementing a Pull system for the Velocity Portlet based on
>>registry parameter info, but it's much more complex that the Turbine one
>>because registry entries *are* mutable at runtime and semantics but be
>>extended to add a "shared" scope for sharing context objects between
>>different portlet instances.
> Yes, as in:
>     <parameter name="action" value="portlets.security.RoleBrowserAction"/>
> So now I see Jon's point. Its not really a 'tool' as described in the TR.p.
> Perhaps it would be better to have a session 'security' tool:
> tool.session.security    = org.apache.jetspeed.tools.Security
> When its instantiated at the start of the session, it could do something
> trivial, like check to see if the user has the proper authority to use the
> security tool. (I want to delay the populating of the roles in the template
> to ensure we get the most recent values)

Yes, security is a good candidate for implementation as a global Turbine tool
to be used in any portlet/screen/layout that requires this info.

> For the problem you described with portlet deployment,
> why not have a tool.xreg file that can be distributed with a PAR?
> I know it not a 'xml' format like the other xregs, but does turbine have a
> non-centralized, and dynamic approach to tool definition and maintenance? It
> seems like its all based out of the static TR.p, but don't quote me on
> that...

Because PAR are part of the new Portlet API and not integrated in HEAD right
now... ;)

> So Im  sure where this this fits in...
>     <parameter name="action" value="portlets.security.RoleBrowserAction"/>
> Taking the security example, we wouldn't need the action to pre-populate the
> context. The context would get populated when referenced in the template:
> $security.Roles

The action parameter is the best way I found right now for implementing MVC

for portlets (short of a complete Pull system):

- if you don't need to override specific Portlet API methods like (the

  PortletState methods) you don't need to subclass the VelocityPortlet but 

   simply associate at runtime through the registry a default template and a
   default action for the portlet.
   The portlet will always call the action for populating the portlet context
   before rendering with the template, thus all context population is handled
   in the Action class and dynamically coupled to a template at runtime.

   If you want to change your portlet behavior at runtime, you simply need to
   write a new action class implementing a new context, modify the registry
   entry, and your portlet will automatically use the new action context...

  Also note that the VelocityPortletAction extends VelocityAction (which 

   itself extends ActionEvent) so you can also dynamically call events on this
   action the usual Turbine way.

Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message