cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: ClientAddressChooser
Date Wed, 05 Jul 2000 11:00:39 GMT
Niclas Hedhman wrote:
> 
> My first try to put together a Chooser, and I selected to do one for
> ClientAddress validation.
> 
> There is one thing that comes into view though.
> IMO, this should not be aware of Http being the transport. But there is
> no parameter or method in Request that gives me this, so I have taken
> the liberty (awaiting something else) to define that "client-address"
> parameter is known by the Request object, and that it returns a String
> with the hostname followed by the ipnumber, separated by a slash. eg.
> envision.asiaconnect.com.my/202.190.60.242
> If the slash is not present, it assumes it to be an IP number is the
> first character is a digit, otherwise a host name.

Next design step is to define Cocoon API that are as powerful as the
Servlet API but are cleaner about protocol abstraction and more friendly
to the whole Cocoon architecture.

Expect this discussion shortly.
 
> Hostnames are matched to the domain/host names in the allow and deny
> sections, by check-and-remove-left sequence, and IP number is by
> check-and-remove-right. It means that if you give;
> <host>202.190.60</host>, all hosts from 202.190.60.1 to 202.190.60.254
> is matched true.

Hmmmm, use wildcards, they are easier to read.

<host>202.190.60.*</host>

and allow higher classes such as

<host>202.190.*.*</host>
 
> In the Sitemap;
> 
> definition
>    <map:chooser type="clientaddress"
> src="class:///org.apache.cocoon.choosers.ClientAddressChooser">
>      <param name="order" value="allow,deny" />
>      <param name="all" value="false" />

Why this?

Look at what this forces you to do in the code..

>     /** Sets the Configuration for the Chooser. */
>     public void setConfiguration(Configuration conf)
>         throws ConfigurationException
>     {
>         Enumeration params = conf.getConfigurations("param");
>         while (params.hasMoreElements())
>         {
>             Configuration param = (Configuration)params.nextElement();
>             String name = param.getAttribute("name");
>             String value = param.getAttribute("value");
>             if ( "order".equals(name) )
>                 allowThenDeny = "allow,deny".equalsIgnoreCase(value);
>             if ( "all".equals(name) )
>                 all = "true".equalsIgnoreCase(value);
>         }

This code _knows_ the parameter schema and configuration have no notion
of precedence, to me it's much simpler to write

   <map:chooser type="clientaddress"
 src="class:///org.apache.cocoon.choosers.ClientAddressChooser">
     <order>allow,deny</order>
     <all map:value="false"/>

then write

 String order = conf.getConfiguration("order").getValue();
 boolean all = conf.getConfiguration("all").getBoolean();
 
which simplified _both_ parameter readability _and_ code readability.

NOTE: since

 <all map:value="false"/>

is transformed into

 <all>false</all>

by the sitemap compilation phase, you can always assume the most
important things is the element text (even if attributes are available
in Configuration but less important)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message