portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject Re: Security stuff...
Date Tue, 12 Jun 2001 17:33:07 GMT
> 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)

The populating of the roles is done when we they are pulled out of the
context, as in

#foreach ($role in $security.Roles)

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...

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

> All in all, this will wait for 1.3a3 if ever (unless someone else picks
> this up)
>
I don't know, maybe we can work something out for 1.3a3 :-)




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


Mime
View raw message