World Wide Tutorial

Introducing SAX
Simple API for XML or SAX is a general API for reading an XML. There are implementations of this API in all languages that you probably know (in any case exists for the implementation C + +, C #, Java, Pascal, Perl, PHP, ...) because XML was widely imposed today in the world of software for exchanging information. There are two major API to read the XML: DOM and SAX. SAX event is (we will discover details) while DOM transforms the tree XML tree target language. The major interest of DOM is the opportunity it offers to come and go at your convenience in the tree, its major drawback is the cumbersome nature of treatment. Indeed, as SAX events, his salary is over inflow.

I said that is SAX events, which means that there events in an XML file? Well, if one considers the incoming XML, it becomes easier to find events: an opening tag is an event, a closing tag another event ... So much for any say most of this API, hence its name Simple API for XML, once you know respond to these two events, you can already handle a XML to use an XML configuration file. It is surprisingly simple, and finally extremely powerful as we will découvrir.Quand you discovered this API, it is likely that you choose to replace all your files properties type pair key / value by an XML file and a rereading SAX . The advantage of XML configuration is its ability contextual, which is difficult to represent in a properties file. Indeed, in the form of name / value pairs, the notion contextual is generally poorly represented by key with a form of path (mon.chemin.vers.ma.propriete).

We look a little more detail, the API which is a bit more complicated than I have presented for the moment, especially because it reacts much more than the simple events of opening and closing tags . We find in particular those events for the opening and closing the xml document, events for the opening and closing of meta information.
Discover API

Content Handler
Let's begin how we can respond to these famous events generated by the SAX parser. To do this we done enough to implement the ContentHandler interface which is in the org.xml.sax package, then instantiate the parser giving what content manager will have to use it (ie ours) and the tour will be played virtually. Here is an overview of the central interface of your developments SAX: ContentHandler manager or content. The manager is indeed the one who does the real work of analysis while the other interfaces of the API made satellites work like managing errors, identify the "slider" in the flow during the analysis. These interfaces satellites are not to neglect but have a less central role in your development.

setDocumentLocator
A locator allows you to locate the "slider" for the treatment of flows for example allowing you to know the number of row and column being analysed. This is a very interesting feature at debug but it must at all costs avoid, as I say, you prohibit use for the treatment itself. In the API Helper sax, you provide a default implementation of all interfaces. If the implementation default ContentHandler is strictly unnecessary, the Locator should amply sufficient to 99% of developments, therefore I do not dwell on this point.

start Document
This method is called by the parser one and only once at the start of the analysis of your feed xml. It is called before all other methods of the interface, with the single exception, of course, the method setDocumentLocator. This event should help to initiate anything that has to be before the start of the trail of the document.

end Document
And its opposite, this method is called at the end of the trail flow after all other methods. It may be useful at this time to notify other objects that the work is finished.

processing Instruction
This event is raised for each instruction operation encountered. These instructions are those that you find out the tree xml itself such as instructions on dtd or simply the statement:
<? xml version = "1.0" encoding = "ISO-8859-1"?>

startPrefixMapping
This event is launched whenever a mapping in advance, which is a beacon in a namespace (name space), is met.

endPrefixMapping
The event obviously, it means the end of treatment in a namespace.

start Element
Starting an XML element ... Finally! And yes, you can indeed to start with SAX itself to understand this event and its treatment and its opposite to analyze a flow xml a very powerful and effective. We will therefore look a little more about this event.

start Element (String namespace Uri, String local Name, String raw Name, Attributes acts);
* Where namespace Uri is the string containing the URI full namespace tag or an empty string if the tag is not included in a namespace,
* Local Name is the name of the tag without the prefix if there were one,
* Raw Name is the name tag xml version 1.0 i.e. $ prefix: $ local name,
* Finally attributes is a list of attributes of the tag that will investigate a little further.

end Element
Unlike signature event much easier, since only the full name tag needs to be known. Indeed, the closure of the XML tag, no attribute is required.

characters
Anything that is in the tree but is not an integral part of a tag, triggering the lifting of this event. In general, this event is therefore lifted simply by the presence of text between the opening tag and the closing tag like this:

<maBalise> a little text </ maBalise>

The presence of "some text" provokes the lifting of the event characters. Warning: it is noteworthy that the SAX API does not nothing about the implementation of this event. In the case of a text scattered around tags girls tag underway, the reactions can be diverse. Thus the flow xml following:
<maBalise> a little
<baliseImbriquee nom="coucou"/> text <baliseImbriquee scattered nom="toto"/>
</ maBalise>

It can either give rise to three events containing the text "a little", "text", "scattered" is a single event containing the full text to say "a few scattered text." As the API does nothing, you will have to think about the fact that the parser that you have on hand may not be that of your customers and act accordingly, ie managing the two types of possible reactions so they provide the same conduct final in both cases.

ignorableWhiteSpace
Used to treat multiple spaces and tabs, since they normally have no value xml. One or two or 10 spaces, 1 space and a tab and 3 returns, etc. are spaces normally ignored in XML. This event is therefore lifted whenever spaces normally ignored met. In fact, the parameters of the method contain the complete chain of characters and indexes start and end of the series of spaces ignorables. It's up to you if you want to override the recommendation that considers these areas as being unnecessary.

skipped Entity
Avoid touching them, this method is raised each time an entity (a tag and the whole tree down) is ignored. It will if you asked the parser not validate the document and that the tag will be poorly trained. In short, you face a dangerous situation for your application, you then decide to leave on default values or, and this is usually the best, you stop treatment for failure in the environment.