xml1-wire-devel

[Xml1-wire-devel] javadoc

[Sean K. <ke...@ad...>]

I've just fleshed out the javadocs in our classes so far.
Running "ant doc" creates a pretty nice set of reference
documentation.  Do a "cvs update" to get the latest.

While doing so, there was something that rubbed me wrong
about the Switches, LevelSensors, etc., methods.  What
happens when we add class OWMemoryCan ... then we'll need
OWMemoryCans(Reader) and OWMemoryCans(Reader, String)
methods.  Then add OWThermometer, with its two
Thermometer methods.  The TagParser interface is going to
get huge.

Let's take an approach similar to
java.io.File.list(FilenameFilter).  The user passes in a
filtering object which gets a chance to approve or
disapprove of each OWDevice (or subclass) about to be
created.  The filter object implements a specified
interface.

It'd be something like this:

public interface Filter {
    boolean accept(String className, String clusterName,
        int familyCode, String netAddress);
}

Then, class TagParser would have these methods:

public class TagParser {
    ...
    /** Return all devices. */
    public Enumeration devices(Reader in) {
        return devices(ALWAYS_PASS_FILTER);
    }

    /** Return all devices passing the given filter. */
    public Enumeration devices(Reader in, Filter filter)
        throws SAXException, IOException {
        ...
    }

    /** This filter always passes all devices. */
    public static class AlwaysPassFilter implements Filter {
        public boolean accept(String className,
            String clusterName, int familyCode,
            String netAddress) {
            return true;
        }
    }

    /** One of these is all you'll ever need. */
    public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
}

Calling TagParser.devices(Reader) returns all devices, as
you'd expect.  Calling TagParser.devices(Reader, Filter)
returns a devices that pass the filter.  The user gets a
chance to filter based on four criteria.

Since the Fitler interface is lightweight, anonymous inner
classes would make this a breeze to use, too.

Comments?

--Sean

RE: [Xml1-wire-devel] javadoc

[Byron K. A. <b.k...@ie...>]

The filter interface sounds like a good idea. We could still write a package
of filter implementations for the commonly used objects. One issue that has
occurred to me is, how to handle nested clusters. Currently, if you ask for
the switches in a particular cluster, you will get all the switches in that
cluster and all of its subclusters. Is this the desired behavior, or should
you only get the devices that are not nested further? Or is some more
flexible interface required? We will eventually also have similar issues
with branches, which I am thinking will probably be a subclass of clusters.

Byron



> -----Original Message-----
> From: xml...@li...
> [mailto:xml...@li...]On Behalf Of Sean
> Kelly
> Sent: Monday, December 18, 2000 9:21 PM
> To: XML 1-Wire Tag List
> Subject: [Xml1-wire-devel] javadoc
>
> Let's take an approach similar to
> java.io.File.list(FilenameFilter).  The user passes in a
> filtering object which gets a chance to approve or
> disapprove of each OWDevice (or subclass) about to be
> created.  The filter object implements a specified
> interface.
>
> It'd be something like this:
>
> public interface Filter {
>     boolean accept(String className, String clusterName,
>         int familyCode, String netAddress);
> }
>
> Then, class TagParser would have these methods:
>
> public class TagParser {
>     ...
>     /** Return all devices. */
>     public Enumeration devices(Reader in) {
>         return devices(ALWAYS_PASS_FILTER);
>     }
>
>     /** Return all devices passing the given filter. */
>     public Enumeration devices(Reader in, Filter filter)
>         throws SAXException, IOException {
>         ...
>     }
>
>     /** This filter always passes all devices. */
>     public static class AlwaysPassFilter implements Filter {
>         public boolean accept(String className,
>             String clusterName, int familyCode,
>             String netAddress) {
>             return true;
>         }
>     }
>
>     /** One of these is all you'll ever need. */
>     public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
> }
>
> Calling TagParser.devices(Reader) returns all devices, as
> you'd expect.  Calling TagParser.devices(Reader, Filter)
> returns a devices that pass the filter.  The user gets a
> chance to filter based on four criteria.
>
> Since the Fitler interface is lightweight, anonymous inner
> classes would make this a breeze to use, too.
>
> Comments?
>
> --Sean
>
>
>
>
>
> _______________________________________________
> Xml1-wire-devel mailing list
> Xml...@li...
> http://lists.sourceforge.net/mailman/listinfo/xml1-wire-devel
>

[Xml1-wire-devel] New Changes

[Byron K. A. <b.k...@ie...>]

I have just committed changes implementing the below described suggestion of
Sean's. I have also changed parserTester to use this interface. OWDevice
objects now have a field with accessor and mutator methods to get the name
of the cluster within which the device is contained. There is also a package
net.sourceforge.xml1wire.devicefilters which contains implementations of a
filter to get switches and levelsensors.

The code needs a little cleanup which I will get to shortly.

Byron K. Appelt
Universal Vinculum Incorporated


> While doing so, there was something that rubbed me wrong
> about the Switches, LevelSensors, etc., methods.  What
> happens when we add class OWMemoryCan ... then we'll need
> OWMemoryCans(Reader) and OWMemoryCans(Reader, String)
> methods.  Then add OWThermometer, with its two
> Thermometer methods.  The TagParser interface is going to
> get huge.
>
> Let's take an approach similar to
> java.io.File.list(FilenameFilter).  The user passes in a
> filtering object which gets a chance to approve or
> disapprove of each OWDevice (or subclass) about to be
> created.  The filter object implements a specified
> interface.
>
> It'd be something like this:
>
> public interface Filter {
>     boolean accept(String className, String clusterName,
>         int familyCode, String netAddress);
> }
>
> Then, class TagParser would have these methods:
>
> public class TagParser {
>     ...
>     /** Return all devices. */
>     public Enumeration devices(Reader in) {
>         return devices(ALWAYS_PASS_FILTER);
>     }
>
>     /** Return all devices passing the given filter. */
>     public Enumeration devices(Reader in, Filter filter)
>         throws SAXException, IOException {
>         ...
>     }
>
>     /** This filter always passes all devices. */
>     public static class AlwaysPassFilter implements Filter {
>         public boolean accept(String className,
>             String clusterName, int familyCode,
>             String netAddress) {
>             return true;
>         }
>     }
>
>     /** One of these is all you'll ever need. */
>     public static final ALWAYS_PASS_FILTER = new AlwaysPassFilter();
> }
>
> Calling TagParser.devices(Reader) returns all devices, as
> you'd expect.  Calling TagParser.devices(Reader, Filter)
> returns a devices that pass the filter.  The user gets a
> chance to filter based on four criteria.
>
> Since the Fitler interface is lightweight, anonymous inner
> classes would make this a breeze to use, too.
>
> Comments?
>
> --Sean