JP, As it is, I am creating my own local version of Slide with your previous changes. I might add this change too to my local version if I can, if not I will hack it with extra config files and hard-coded relative paths for now.
Thanks. Akil ----- Original Message ----- From: "Jean-Philippe Courson" <[EMAIL PROTECTED]> To: "Slide Users List" <[EMAIL PROTECTED]> Sent: Wednesday, January 30, 2002 9:16 AM Subject: Re: Configuration of extension classes in Slide e.g. UserQuota..Interceptor, etc > Yes it is. > > Would be cleaner to have the possibility of adding parameters in that > way : > > <content-interceptor class="CLASSNAME"> > <parameter name="PARAMETER_NAME">PARAMETER_VALUE</parameter> > ... > </content-interceptor> > > The NamespaceConfig would only have to retrieve parameters associeted to > a given contentInterceptor and give them to the contentInterceptor > instance. > > I can do it, but not now :-( > If you can wait one or two weeks > > JP > > Akil wrote: > > > Is there a mechanism to configure Slide Extension classes? > > > > e.g. Consider the following scenario: > > > > John create a new class that implements the ContentInterceptor interface. > > John wants to make this class configurable at Run-Time. > > John adds this class as one of the content interceptors in the Slide > > configuration by > > adding appropriate XML element to the appropriate configuration file. > > How does John specify the configurable values for his class? > > > > As far as I can make out, there is no mechanism in Slide. > > One can always create another configuration file and put it in a well-known > > relative path location. > > This is not very clean. It would be much more compact to enable Slide to > > configure all such extension classes. > > > > I propose the following: > > > > The interceptor element specification entry in the Slide configuration file > > should be passed to the Object created for the Class specified in the entry. > > This object could then configure itself. > > > > Scenario contd: > > > > John could then add any configuration parameters needed as either attributes > > of the contentInterceptor specification entry or as Children of this entry. > > > > Any thoughts on this? Other Ideas? > > > > Akil > > PS > > JP, does this sound like an attractive solution to the problem of passing > > the NameSpaceConfig object to the UserQuotaContent..... methods? > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
