SLIDE_1_0 and UserQuotaContentInterceptor

[Jean-Philippe Courson <co...@noos.fr>]

Hi,

Some time ago, I sent some patches that make slide support users quota, 
a feature requested by a lot of users.

These patches have never been commited to the cvs tree.
I asume it's because they were not considered clean enougth and/or too
big by commiters so, wishing to see them integrated into SLIDE_1_0,
I will take some time to make them cleaner and smaller.

To reach this purpose,
1) I would be pleased if some people who deeply know slide's internals
    could answer some questions.
2) Rather than sending in one time a lot of big patches, I will send
    several little patches that will be easier for commiters to manage.


1) Some questions :

- What to do with exceptions ?

Firstly, ContentInterceptors's preStoreContent method is called before
the content to be stored so if there is a problem with the node (node
doesn't exist, access to it is denied,...), exceptions may be thrown.

Secondly, ContentInterceptors may have to access stores (for retreiving
or updating data) to complete their processing and once again,
exceptions may be thrown.

So what ContentInterceptors could do else than throwing again these
exceptions ?

- ContentInterceptors parameters :

Would not it be great (and clean) to be able to give ContentInterceptors
parameters in the following way ?
<content-interceptor class="[contentInterceptorClass]">
   <parameter name="[paramName]">[paramValue]</parameter>
</content-interceptor>

- ContentInterceptors's methods new arguments :

As I just said above, ContentInterceptors may have to access stores or
namespace configuration to complete their processing, so would not it be
usefull to add a Namespace object to their methods arguments ?


2) "Patches planning"

As soon as I will have some feedback with the above questions, I will
propose a "patches planning" to make commiters work easier as possible.
I am planning to firstly send generic ContentInterceptors changes (one
by one) and secondly send changes to support users quotas.

Any feedback will be welcome

Thanks in advance for your help

JP


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

PATCH : ContentInterceptors parameters support (SLIDE_1_0)

[Jean-Philippe Courson <co...@noos.fr>]

Hi,

I would be very pleased to have some feedback on the above proposed
modifications, espacially with the exceptions problem.

I asume that if nobody has given an opinion on this, they should agree
with modifications so you will find enclosed my first proposed
modification : Adding parameters support to ContentInterceptors to allow
them to be plugged smothly and cleanly.

This patch affects org/apache/slide/common/NamespaceConfig.java and
org/apache/slide/content/ContentInterceptor.java and add parameters
support through Domain.xml file in this way :

<content-interceptor class="[contentInterceptorClass]">
     <parameter name="[paramName]">[paramValue]</parameter>
</content-interceptor>

ContentInterceptors parameters are stored into a new ContentInteceptor's
property (Hashtable parameters) accessible via method getParameters().

As Remy has suggested it some time ago, I've made ContentInterceptor
class abstract.

Regards

JP

ps : this patch is for banch SLIDE_1_0. I will port it (and the
      following) to HEAD branch as soon as it will be approved.

Jean-Philippe Courson wrote:
> Hi,
> 
> Some time ago, I sent some patches that make slide support users quota, 
> a feature requested by a lot of users.
> 
> These patches have never been commited to the cvs tree.
> I asume it's because they were not considered clean enougth and/or too
> big by commiters so, wishing to see them integrated into SLIDE_1_0,
> I will take some time to make them cleaner and smaller.
> 
> To reach this purpose,
> 1) I would be pleased if some people who deeply know slide's internals
>    could answer some questions.
> 2) Rather than sending in one time a lot of big patches, I will send
>    several little patches that will be easier for commiters to manage.
> 
> 
> 1) Some questions :
> 
> - What to do with exceptions ?
> 
> Firstly, ContentInterceptors's preStoreContent method is called before
> the content to be stored so if there is a problem with the node (node
> doesn't exist, access to it is denied,...), exceptions may be thrown.
> 
> Secondly, ContentInterceptors may have to access stores (for retreiving
> or updating data) to complete their processing and once again,
> exceptions may be thrown.
> 
> So what ContentInterceptors could do else than throwing again these
> exceptions ?
> 
> - ContentInterceptors parameters :
> 
> Would not it be great (and clean) to be able to give ContentInterceptors
> parameters in the following way ?
> <content-interceptor class="[contentInterceptorClass]">
>   <parameter name="[paramName]">[paramValue]</parameter>
> </content-interceptor>
> 
> - ContentInterceptors's methods new arguments :
> 
> As I just said above, ContentInterceptors may have to access stores or
> namespace configuration to complete their processing, so would not it be
> usefull to add a Namespace object to their methods arguments ?
> 
> 
> 2) "Patches planning"
> 
> As soon as I will have some feedback with the above questions, I will
> propose a "patches planning" to make commiters work easier as possible.
> I am planning to firstly send generic ContentInterceptors changes (one
> by one) and secondly send changes to support users quotas.
> 
> Any feedback will be welcome
> 
> Thanks in advance for your help
> 
> JP