You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or
API help for more information.
<?xml version="1.0"?>
<api>
<query-continue>
<allpages gapcontinue="ReaderJunits" />
</query-continue>
<query>
<pages>
<page pageid="374" ns="0" title="ReadCycle Class Hierarchy">
<revisions>
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">The sensors plugins in the Sensor Abstraction Layer produce ReadCycle objects that are put into Esper. Because you query objects (rather than tables) in Esper, you need to know the class hierarchy of ReadCycle in order to write queries.
[[Image:ReadCycle.png|thumb|400px]]
=Built-in Hierarchy=
This section details the current classes that hold data gathered from sensors which can be queried in Esper.
==ReadCycle==
A ReadCycle represents one cycle of interaction with a sensor. It can contain 0 to many TagReadEvent objects. A cycle of interaction might entail polling the sensor for data or perhaps the sensor is pushing data to the edge server. It is also important to realize that since the Edge Server supports the concept of logical readers, a single ReadCycle might contain tag reads from multiple physical readers.
==TagReadEvent==
A TagReadEvent represents a single tag read from an RFID reader. The TagReadEvent object is a wrapper around a DataContainerEvent in order to provide information about the tag that is not written on the tag itself. For example, suppose you are interested in knowing the antenna that saw the tag. The antenna number is not information that is stored in the tag's memory bank. You can instead put this kind of information in the TagReadEvent object.
==DatacontainerEvent==
The DatacontainerEvent is an abstract class that represents information (such as the EPC) that is stored on the tag. This class is meant to be extended to support many kinds of tag types.
==EpcGeneration1Event==
The EPCGeneration1Event represents the information read from an EPC Gen1 tag.
==EpcGeneration2Event==
The EPCGeneration2Event extends the EPCGeneration1Event and represents the information read from an EPC Gen2 tag.
=Extending the Hierarchy=
The current hierarchy is flexible and can be extended to meet the various of different kinds of applications. The two places that extensions are forseen are TagReadEvent and DatacontainerEvent
==Extending TagReadEvent==
You might want to extend TagReadEvent if, for example, you are interested in data about a tag that is collected when the tag is read. For example, suppose the reader you are working with can give you the speed the tag is moving. The speed is not information that is stored on the tag, so it should go in The TagReadEvent. You can extend the TagReadEvent object to include a setSpeed() and getSpeed() methods. Now when you collect the data from the RFID reader in the Sensor Layer, you can store the speed data in your new TagReadEvent class.
Furthermore, you can query the data in your esper statements. For example, you can ask for all tags where the speed of the tag is greater than 4 m/s like this:
<pre>
Select * from ReadCycle[select * from tags(cast(speed?,Integer) > 4)]
</pre>
==Extending DatacontainerEvent==
You would extend the DatacontainerEvent when the tag you are using in your RFID system is not an EPC Gen1 or Gen2 tag. For example, if you are using active tags which do not follow the EPC Gen2 specification, then you will want to make up a new Class that represents the kind of tags you are using.
==Adding new Event Types in Esper==
If you need to query the new event types that you created by extending the other classes, you will need to add those event types to Esper with code like this:
<pre>
esperService.getProvider().getEPAdministrator().getConfiguration.addEventType("MyNewEvent",MyNewEvent.class);
</pre></rev>
</revisions>
</page>
<page pageid="180" ns="0" title="Reader.xml">
<revisions>
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">[[category:developerDoc]][[category:emulatorDoc]]
Reader.xml is a file that contains the mapping between handler methods and the command names. It tells the command processor where to find the proper handler method, given a particular command. See [[READERNAME_CATEGORY_Handler.java]] for more information about the command handlers.
=Command=
The command xml tag is the basic tag in the reader.xml file. It contains the information for the mapping of a single reader command to a single handler method. For example, it lets the command processor of the symbol reader know that if it receives a command with the number '22', it should go to the 'readFullField' command handler method to process this command.You will need one of these tags for every command that you want to support in the reader.
==Sub elements==
# queryName - The queryName is the unique name of the incoming command. It should be able to be derived from the incoming command messages somehow. For example, with the symbol and LLRP readers, all commands have numbers associated with them that identify the type of command. For the alien reader, which is text-based, the commands all have a unique textual name, such as 'taglist', or 'persistTime'.
# displayName - The display name is used if the properties view is enabled in the IDE. It is the name that should be used if a certain property is able to be displayed
# CommandState - This is a classifier for what state the reader should be in to use the command. It is not all that important, and should be set to interactive for most readers.
#CommandHandlerDetails - Information about the commandHandler method that will handle this command
##HandlerClass - the packagae name of the command. For example, 'org.rifidi.emulator.reader.symbol.commandhandler.BitEncodedCommands'
##handlerMethod - the method name. For example, 'readFullField'
##argumentType - If the command is used like a property, such as it is in the alien reader, this is the type of the property. Most readers should probably just use 'string'
#actionTag - should be set to 'IGNORE'
#category - again, if the property view is enabled, the category this property should be in. Most readers should use 'NONE'
#defaultValue - If this command is a property, the default value of it. Again, most readers other than the Alien do not use this, and it should be set to 'OFF'
==Reference Implementation==
This is the command tag for the Read full field command in the symbol reader. The important parts are the queryName, and the commandHandlerDetails.
<pre>
<Command>
<queryName>22</queryName>
<displayName>READ_FULL_FIELD</displayName>
<commandState>Interactive</commandState>
<commandHandlerDetails>
<handlerClass>org.rifidi.emulator.reader.symbol.commandhandler.BitEncodedCommands</handlerClass>
<handlerMethod>readFullField</handlerMethod>
<argumentType>String</argumentType>
</commandHandlerDetails>
<actionTag>IGNORE</actionTag>
<category>NONE</category>
<defaultValue>OFF</defaultValue>
</Command>
</pre>
Because the Alien Reader treats all of its commands as properties that have values that can be displayed, it uses the fields that most readers do not need.
<pre>
<Command>
<queryName>getPersistTime</queryName>
<queryName>setPersistTime</queryName>
<displayName>PersistTime</displayName>
<commandState>Interactive</commandState>
<commandHandlerDetails>
<handlerClass>org.rifidi.emulator.reader.alien.commandhandler.AlienTag</handlerClass>
<handlerMethod>persistTime</handlerMethod>
<argumentType>Integer</argumentType>
</commandHandlerDetails>
<actionTag>EDITABLE</actionTag>
<category>TAG</category>
<defaultValue>-1</defaultValue>
</Command>
</pre></rev>
</revisions>
</page>
</pages>
</query>
</api>