Explaining Attributes

Attributes in GNU-Paperclips have magic qualities that normal servlet engine attributes do not have. This section describes those differences in (hopefully) as concise and helpfull a manner as possible.

Attribute objects

An Attribute is Paperclips is a Java object. It's a very simple object, having only two properties:

    Class Attribute
    {
        String name;
        Object value;
    }

This exactly mirrors the servlet-context definition of what an attribute is. You can't talk to an attribute's properties directly because they are private, instead there are methods:

    Class Attribute
    {
        //set and get the associated value
        void setValue(Object value);
        Object get();

//return the value as a String
String toString();

        //get the name
        String getName();
    }

The .toString() method needs some explanation. .toString() can be assumed to always return the correct String representation of the value object because it calls the value object's own .toString() method.

There are several Attribute types (one plain, one for integers and one for booleans) and they usually declare an approproate constructor, the IntAttribute looks like this:

IntAttribute(String name,int value);

All of this means that you can easily declare Attribute objects in your code.

None of that would make any sense though if you could not access those Attributes in the usual way, ie: through the ServletContext get/set methods.

ServletContext changes

The Paperclips HttpService (which acts as the ServletContext for Paperclips' hosted servlets) has a number of different setAttribute() methods.

`void setAttribute(String attrname,Object value)`	the standard `ServletContext` method for setting an attribute, a context specific registry is updated or added to with the value; the registry contains only objects of class `Attribute` (or sub-classes of it) and this method is responsible for creating an `Attribute` wrapper for the specified `Object;`
`Attribute setAttribute(Attribute a)`	adds the specifed `Attribute` object to the registry; the name and value are both encapsulated within the `Attribute` object.
`IntAttribute setAttribute(IntAttribute a)`	same as the vanilla `Attribute` method but specifically for integer based attributes.
`BooleanAttribute setAttribute(BooleanAttribute a)`	same as the vanilla `Attribute` method but specifically for boolean based attributes.

These methods allow you to enter attributes you create into the ServletContext registry.

The ServletContext.getAttribute(String name) method is designed to return the value of the attribute which is located in the registry by name. It will find the Attribute object in the registry (by searching all the Attribute objects in the registry and matching name) and will then return the value of the Attribute with the Attribute method .get().

Attribute value change protection

It is possible to have atributes protected when you create them. This facility is only available to those brave enough to extend the Attribute classes right now.

It works very simply, when you create an Attribute you can specify a type of access, the access levels are defined in class Attribute and are:

UNPROTECTED	the attribute's value can be altered and (if it is in the registry) then the attribute can be removed from the registry;
NODELETION	if the attribute is in the registry then it cannot be removed, it's value can still be changed however;
NOALTERATION	the value of the attribute cannot be changed even by `setAttribute(name,value)` neither can it be removed from the registry, once in your stuck with it.

Since this is only available to extenders right now I won't go on about it too much. However, it is there and if I get enough interest this feature will get promoted to public accessability.

Why adding to ServletContext attribute registry can't be automatic

It is tempting to think "why can't the Attribute object add itself to the ServletContext attribute registry automatically? rather than me having to put it there specifically?". It is tempting but to do that would require that Attributes are told about the ServletContext they are to work in. I did think about making a static linking system but of course static wouldn't work with multiple ServletContext's.

The current method seemed the simplest choice for the functionality. Though because this is a bit dirty I don't expect it to be added to the Servlet API in the near future. Perhaps you can think of an improvement to the system?

Extension to the admin interface for attributes

In a future release of GNU-Paperclips there will be a servlet to allow administrators to specify values for attributes.

Of course this will only be able to take a number of different base types as values (strings, integers, booleans).

Created: 1 July 1999

Last Updated:

Contact: webmaster

Author: Nic Ferrier