[PATCH] Re: Registry service enhancment

[Jeremy Ford <ca...@hotmail.com>]

Here is my take on the ability to add a registry entry to a fragment.

In the path, I have included a sample action that will create a entry with
the new method.

Please note:  The second parameter takes the name of the fragment, not the
absolute path.  This is determined by the implementation.

Jeremy Ford

----- Original Message -----
From: "Luta, Raphael (VUN)" <Ra...@groupvu.Com>
To: "'Jetspeed Developers List'" <je...@jakarta.apache.org>
Sent: Friday, October 25, 2002 6:20 AM
Subject: RE: Registry service enhancment


De : Jeremy Ford [mailto:caius1440@hotmail.com]
>
> While developing with Jetspeed, I have experimented with
> creating Registry
> entries via the API.  Currently, when you add a new entry,
> that entry will
> be placed into the local-portlets.xreg.  I have often wished
> that I could
> control the name of the file that the entry was placed in.  Here is a
> suggested addition to the Registry interface.
>
> public void addEntryToFragment(String regName, String fragmentName,
> RegistryEntry entry)
>      throws RegistryException;
>
> When implemented in the CastorRegistryService, this method
> would add an
> entry to the suggested file name if that entry does not
> already exist.  If
> an entry already exists in another fragment, then the
> existing fragment name
> will be used instead.  If fragmentName is null or empty, then
> local-portlets.xreg would be used as the default.
>

I would be -1 to add this signature to the standard Registry method
as I just hate methods in API interface that have no meaning in most
implementations.

However, this could be easily added to a sub interface of Registry
(or perhaps FileRegistry which is already dealing with fragment
manipulation) and have the CastorRegistry implementation implement this
interface.

You'd have to tie your code to a specific known sub-interface but I think
that's the better option unless there's a need to structure most
of the registry implementations in additionnal fragments than currently
(the default division common to all impl is by element function: portlet,
controller, skin, control, etc...)

I just don't see right now the need for such a call in the generic
interface but would gladly accept patches for a sub-interface :)

--
Rapha�l Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
convinced :)

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>