Event-Driven Programming: Introduction, Tutorial, History
"), you are in effect entering a state. All succeeding elements in the document occur within the context of that state until you encounter the corresponding end tag (i.e. "
Download 264.36 Kb.
|
- Navigate this page:
- Ways to remember state
- Conclusion
- Appendix A – Abstract methods in Python
- Appendix B – SAX parsing in Python
"), you are in effect entering a state. All succeeding elements in the document occur within the context of that state until you encounter the corresponding end tag (i.e. "").Here is a snippet of SAX processing code (in Python) that checks to make sure that the input doesn't contain any " " tags or heading tags nested inside other heading tags.
Compare the structure of this code to the code that parsed letters and spaces. The parsing program was quite simple, so that once we were inside the handleSpace or handleLetter functions, the parsing program knew everything it needed to know about the transaction that it was processing. That's not enough in this program. Here, once we are inside the startElement or endElement methods, we need to do further checking to see what kind of tag we're processing. But once we know what kind of event we're processing, the processing is quite similar. Basically, it involves setting and checking status information (e.g. inHeadingStatus) and state-vector information (e.g. currentHeadingTag), and accepting or rejecting transactions based on the current state of the application. Ways to remember stateMany stateful applications need to remember their state only as long as they are actually running. Such applications have no problem remembering their state information – they simply store it in memory. In our parsing program, for instance, we used the state and outstring global variables. In our SAX content handler, we used the inHeadingStatus and currentHeadingTag instance variables of the content handler object. But other stateful applications need to suspend execution, which means that they need to store their state information somewhere other than in memory. Such an application may:
or it may:
Web applications are good examples of this kind of stateful application, because they often use both of these strategies in remembering state information. Consider nozama.com, an imaginary Web shopping application in which a typical user with a Web browser:
At any given time, there may be hundreds or thousands of simultaneous users in the middle of the shopping process. Nozama must handle a stream of service requests in which requests are interleaved from different shoppers in different stages of the shopping process. Unfortunately, simple Web technology doesn't supply Nozama with a direct link to any given shopper. HTTP is a stateless protocol: it provides no built-in way for a server to recognize a sequence of requests all originating from the same user.... The HTTP state problem can best be understood if you imagine an online chat forum where you are the guest of honor. Picture dozens of chat users, all conversing with you at the same time. They are asking you questions, responding to your questions.... Now imagine that when each participant writes to you, the chat forum doesn't tell you who's speaking! All you see is a bunch of questions and statements mixed in with each other. In this kind of forum, the best you can do is to hold simple conversations, perhaps answering direct questions. If you try to do anything more, such as ask someone a question in return, you won't necessarily know when the answer comes back. This is exactly the HTTP state problem. The HTTP server sees only a series of requests—it needs extra help to know exactly who's making a request.11 What Nozama and similar applications need is a way to identify a conversation with a particular client. Such a conversation is called a session. What Nozama needs is a way to manage the process of creating, maintaining, and remembering session information. Here's how it does it. When a user opens the Nozama web site, Nozama creates a temporary session object 12. As the user goes through the shopping process, Nozama adds information that the user supplies– his product choices, his billing and shipping information– to the state information of his session object. Finally, the life of the session ends when the user submits his order. Nozama tracks sessions by giving each session a session ID and by storing the session's state vector (its state information) in a database in which the session ID is the key of the state vector. 13 Once a session has been started, Nozama includes the session ID in every Web page that it sends to the user, encoded in such a way14 that it will be sent back to Nozama as part of every page request by the user. When Nozama receives a page request containing a session ID, it uses the session ID as a key to retrieve the session state vector information from the database. After Nozama has processed the user's request, it updates and replaces the state vector in the database, and returns a response to the user.  Remember that we said that a stateful application could remember its state information by storing the information on some persistent medium, or by delegating responsibility for remembering the information to its caller. Nozama uses both of these strategies. It remembers the actual state information by storing it on disk, in a database. But it also gives the caller – in this case, the client's browser – the responsibility of remembering one piece of state information: the session ID. An alternative strategy would be for Nozama to pass the entire session state back and forth to the browser, and let the browser remember it. If Nozama did this, it wouldn't need to use a database to store session information, and it could be much simpler. But transmitting potentially large amounts of state vector information back and forth to/from the client's browser could slow down response time considerably. The alternative strategy does have one distinct advantage. If the user aborts the shopping process before completion, it leaves no orphaned session information in the database. In contrast, with the database strategy, Nozama must implement the notion of a session time-out to detect aborted sessions. When a session's state information has not been accessed after a certain amount of time (say 30 minutes), Nozama will consider the session to have been aborted, and must delete the session state information from the database. ConclusionThis concludes our brief introduction to event-driven programming — really, to the Handlers pattern and its variants – and related programming issues. As you can see, understanding event-driven programming is the key to being able to perform many software development tasks: object-oriented programming, object-oriented systems analysis and design, parsing XML with a SAX parser, GUI programming, Web programming, and even lexing and parsing. Good luck with your event-driven programming! Appendix A – Abstract methods in PythonIn Python 2.4 and later, it is possible to use a decorator to create abstract methods. # define a decorator function for abstract methods def abstractmethod(f): methodName = f.__name__ def temp(self, *args, **kwargs): raise NotImplementedError( "Attempt to invoke unimplemented abstract method %s" % methodName) return temp class TestClass: # an abstract class, because it contains an abstract method @abstractmethod def TestMethod(self): pass t = TestClass() # create an instance of the abstract class t.TestMethod() # invocation of the abstract method raises an exception For a more sophisticated approach to creating abstract methods in Python, see: http://www.lychnis.net/blosxom/programming/python-abstract-methods-3.lychnis Appendix B – SAX parsing in Python"""Use a SAX parser to read in an XML file and write it out again.""" import sys, os import xml.sax from xml.sax.handler import ContentHandler from xml.sax.saxutils import escape class CustomizedHandler(ContentHandler): def setOutfileName(self, argOutfileName): # Remember the output file so we can write to it. self.OutfileName = argOutfileName self.Outfile = open(self.OutfileName, "w") def closeOutfile(self): self.Outfile.close() def write(self, argString): self.Outfile.write(argString) def startDocument(self): pass def endDocument(self): pass def setDocumentLocator(self, argLocator): self.myDocumentLocator = argLocator def startElement(self, argTag, argAttrs): # argAttrs is a list of tuples. # Each tuple is a pair of (attribute_name, attribute_value) attributes = "" for name in argAttrs.getNames(): value = argAttrs.getValue(name) attributes = attributes+(' %s="%s"' % (name, value)) self.Outfile.write("<%s%s>" % (argTag, attributes)) def endElement(self, argTag): self.write("" % argTag) def characters(self, argString): self.write(escape(argString)) def ignorableWhitespace(self, argString): self.write(argString) def skippedEntity(self, argString): self.write("&%s;" % argString) def handleDecl(self, argString): self.write("" % argString) def processingInstruction(self, argString): # handle a processing instruction self.write("" % argString) def main(myInfileName, myOutfileName ): myContentHandler = CustomizedHandler() myParser = xml.sax.make_parser() myParser.setContentHandler(myContentHandler) myContentHandler.setOutfileName(myOutfileName) myInfile = open(myInfileName, "r") # open the input file myParser.parse(myInfile) # parse it myInfile.close() # close the input file myContentHandler.closeOutfile() # close the output file def dq(s): # Enclose a string argument in double quotes return '"'+ s + '"' if __name__ == "__main__": print "Starting SaxParserDemo" infileName = "SaxParserDemo_in.txt" outfileName = "SaxParserDemo_out.txt" # -------- create an input file to test our program ------------- infile = open(infileName, "w") infile.write(""" This is an ampersand: & This is a gt sign: > and an lt sign: < and lt sign < ]]> Download 264.36 Kb. Share with your friends:
|