XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application- P10

XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application- P10: Là một nhà phát triển Web, bạn biết những thách thức trong việc xây dựng các ứng dụng mạnh mẽ trên nhiều nền tảng. Tạo các ứng dụng di động trở nên thật sự có thể bằng cách sử dụng Java cho code và XML để tổ chức và quản lý dữ liệu. "XML, XSLT, Java, và JSP: Một trường hợp học" sẽ giúp bạn tối đa hóa khả năng của XML, XSLT, Java, và JSP trong các ứng dụng web của bạn....
Nội dung trích xuất từ tài liệu:
XML, XSLT, Java, and JSP: A Case Study in Developing a Web Application- P10432 Chapter 11 XML Data Storage Class: ForestHashtable wally::Hey! I’m here charlie. Are you there? 965506098557.965501551999.965501551959 965503142126.965501552059.965501551959 965503119944.965501551999.965501551959 11.12.1 Chat Data in the XML Data Example At the time the bonForum data was dumped to an XML file, two chats had been started.The nicknames and ages of the two chat hosts are stored inside host elements as children of the actors element. Only one guest has joined a chat, and that guest’s nickname and age are stored in a guest element also as a child of the actors element. Adam is the host of a topic with the subject Vehicles.Trucks.Other and the topic “my other truck is a ferrari.” Adam is still awaiting his first guest, and only his own single message appears in the chat. It could be displayed as follows: [Saturday 05 09:08:09 2000] adam::this is dynamite! Charlie is the host of a chat with the subject Animals.Fish.Piranhas and the topic “pet piranha stories.” Charlie and his guest,Wally, have each entered one message to the chat, which could be displayed as follows: [Saturday 05 09:19:02 2000] charlie::Is anybody there? [Saturday 05 10:09:35 2000] wally::I’m here, charlie. 11.13 More ForestHashtable Considerations In this last part of this chapter, we will mention a few final things that are important to the understanding and future development of the ForestHashtable class. 11.13.1 Some Important Data Characteristics In the example of bonForum XML data content at runtime shown previously, you can notice the following two characteristics of the way the chat data is kept in the ForestHashtable: 11.13 More ForestHashtable Considerations 433 1. The objects stored in a Hashtable have no order.Therefore, the order of sibling elements in the XML document has no meaning. For human readability, if that is needed, some XML elements could be sorted by modifying the XSLT style sheet. Sorting could also be implemented by changing the underlying data struc- ture to a SortedMap implementer, such as TreeMap, or by keeping an external sorted index in the manner of an RDB. 2. The NodeKey values are referred to by other key attributes, to relate the informa- tion in different elements together. For example, a chat element has a hostKey child that contains the value of the chat’s host’s NodeKey.That is why we pre- serve the NodeKey values in NodeKey” attributes within each element when the XML is output from the ForestHashtable.11.13.2 Setting ForestHashtable CapacityBy reading the API documentation on the java.util.Hashtable class, you can learnabout the issue of the capacity of a Hashtable object.The only way we have dealtwith this so far is to provide a constructor for the class that takes an argument calledcapacity, which (surprise!) sets the capacity of a ForestHashtable. The idea is that this capacity setting can be determined by the Web application,perhaps by having it saved as a parameter in the Web app deployment descriptor(web.xml) of the application. For the bonForum Web chat application example, we setthe capacity to 5000.This number was selected by estimating 200 bytes per node.More testing is necessary to tune this factor, which is very important for the experi-ence of using the Web application. Setting the capacity correctly can minimize theinevitable rehashing time.11.13.3 XPATH Modeling PlannedOne premise behind the design of ForestHashtable is that is could be easier or fasterto manipulate a triple-valued key than to work with the (infinitely) long path expres-sions that can be present in an XML data document.The hierarchy of nodes can bemodeled as a forest of trees by a table with a double- or triple-valued key. A plan for the future is to see if we can create methods that fulfill all the XPATHfunctionality solely by processing the keys in the table.11.13.4 Self-Healing XML DocumentsAnother idea of ours is to create an XML document representation that would create,by default, any “missing” set of nodes.These nodes that would be supplied form anode path connection between a “disconnected” XML fragment and the “closest”existing related node. Why do that? Because that means you can put a tree-fragment into empty space inthe forest.Then you cou ...