WEBINAR:On-Demand

1. Configurations for LBXML Operator

LBXML Operator runs over the .NET platform. 2.0, the latest version of LBXML Operator, has been tested successfully over the .NET 2003 platform.

It is easy to install LBXML Operator. Two DLLs, as follow, are what you need to care about. To install it, what you need to do is to make just two references in your C# applications for the two DLLs.

com.lblabs.tools.csharp.dll
com.lblabs.xmltool.dll

To program with LBXML Operator, declare the following statements at the beginning of your C# code:

using com.lblabs.xmltool.csharp;
using com.lblabs.xmltool;

It is noted that LBXML Operator is just developed in an initial phase. In the further versions, more types of operations will be designed to support more powerful functionalities.

Another issue is that LBXML Operator is not responsible for validating the XML file. So, when using any APIs in LBXML Operator, users need to make sure that the XML file must be validated after the particular operation, such as modification, insertion, and removal. Otherwise, the XML parser may interrupt the system execution.

2. Examples of Using LBXML Operator

The operations on XML are categorized into four types: insertion, modification, searching, and removal. This section discusses the four types of operation one by one. All the operations are included in the CSharpLBXMLOperator class.

To make a clear explanation, a typical XML file is selected and example of operations are shown on it. The XML and its DTD are listed as follows.

After the operation, the XML file of List 1 is changed. The new tag, VocabularyName, and its value, CurrentCash, are inserted below the Vocabulary tag. Because the Vocabulary tag appears two times in the XML file, the inserted tag, VocabularyName and its value, CurrentCash, also are inserted two times. The XML file after the operation is shown as follows.

2.1.2 insertNodeByParentTagAndParentSibling()

It is possible that the tag, Vocabulary, and its value, CurrentCash, should be inserted only below the first tag, Vocabulary. Under this situation, the method is insertNodeByParentTagAndParentSibling(). The format is shown as follows.

The difference between insertNodeByParentTagAndParentSibling() and insertNodeByParentTag() is that new parameters, parentSiblingTag and parentSiblingValue, are specified. Through the two parameters, the LBXML Operator is able to figure out the position to insert the new tag and its value. The following list shows in the new XML after the operation.

WEBINAR:On-Demand

2.2 Removal

At present, the removal operation of LBXML Operator provides only one method, removeNodeByTagValue(). More powerful APIs will be implemented soon. The format of the method is shown as follows.

bool removeNodeByTagValue(String xmlFile, String tag, String value)

The operation is too simple. The tag and value parameters are similar to the key and key value for the same level XML tags. If you specify the tag and value parameters, all the same level tags and corresponding values are removed. For example, to remove the part between the NewSAT tag, the tag and value parameters of the method should be Organization and BigBug.com. The corresponding code is shown as follows.

2.3 Modification

2.3.1 changeByValue()

changeByValue() is a simple method to modify XML files by value. When specifying the oldValue and newValue parameters, the oldValue is changed to newValue. The format of changeByValue() is shown as follows.

bool changeByValue(String xmlFile, String oldValue, String newValue)

For example, to change the old value, CreditCheckingContract, to the new value, CreditContract, the code is written as follows.

2.3.2 changeByTag()

changeByTag() is also a simple method to modify XML. Because only a tag and corresponding new value are specified in the parameters, the values of all the tags appeared in an XML are changed after the operation. The format of the method is shown as follows.

bool changeByTag(String xmlFile, String tag, String newValue)

For example, if the value of the VocabularyName tag needs to be changed to null, the code can be written as follows.

2.3.3 changeByTagNewValue()

Compared with changeByTag(), changeByTagNewValue() provides a new parameter, oldValue. Users specify the parameter to change the value of a tag. If so, only the value of the tag that is equal to the oldValue is changed. The format of the method is shown as follows.

2.3.4 changeByNoTagNewValue()

changeByNoTagNewValue() is similar to changeByTagNewValue(). The difference is that the value of a tag is specified by the sequential number of the tag in the XML file instead of by the old value of the tag. The format of the method is shown as follows.

For example, if users want to do the same change as the example in the 3.3.3, i.e., the value, CreditRequestNo, of the VocabularyName tag to CreditResponseNo, the code can also be written as follows using changeByNoTagNewValue().

Here, the sequential number of the VocabularyName tag is 2 (starting from 0) in the XML file. After the operation, the changed XML file is the same as the one in List 8.

2.3.5 changeBySiblingTagNewValue()

Although changeByTagNewValue() and changeByNoTagNewValue() provide the functionality to figure out which tag's value is to be changed, both of them have drawbacks. If more than one tag's values are equal to the specified old value, changeByTagNewValue() cannot differentiate which one should be changed so that all the tags' value that is equal to the old value is changed to the new value.

The drawback of the changeByNoTagNewValue() method is that sometimes it is hard to know the sequential number of a particular tag in an XML file, especially when the XML file is large.

changeBySiblingTagNewValue() overcomes the above drawbacks. By specifying the sibling tag of the tag whose value to be changed, LBXML Operator is able to figure out which tag's value should be changed exactly. The format of the method is as follows.

For example, users need to change the CreditCheckingContract value of the first tag, ContractName (there are two such tags in the XML file). In this case, the sibling tag is also ContractName, but its value is WholesaleContract. So, the code can be written as follows.

WEBINAR:On-Demand

2.3.6 changeBySiblingTagUpdateTagNewValue()

Although changeBySiblingTagNewValue() overcomes some drawbacks of changeByTagNewValue() and changeByNoTagNewValue(), problems still exist in it. In general, changeBySiblingTagNewValue() demands by default that the tag whose value to be changed is the same as its sibling tag. For example, the section 2.3.3, the ContractName tag, whose CreditCheckingContract value needs to be changed, is specified by its sibling tag, another ContractName tag, just beyond it.

However, it is common to see that a tag is different from its sibling tag. For example, the sibling tag of the User tag in the XML file is Organization. In this case, changeBySiblingTagNewValue() does not work at all. In this situation, changeBySiblingTagUpdateTagNewValue() is able to do that instead of changeBySiblingTagNewValue() because the method does not require the tag whose value to be changed is the same as its sibling tag. The format of the tag is shown as follows.

List 11. The XML file after the changeBySiblingTagUpdateTagNewValue() operation

2.3.7 changeByKeyTagKeyValueUpdateTagNewValue()

changeBySiblingTagNewValue() and changeBySiblingTagUpdateTagNewValue() provide modifications based on sibling tags. However, some tags must have no sibling tag. For example, the third ContractName tag, whose value is CreditCheckingContract, has no sibling tag. If the tag's value needs to be changed, only the changeByNoTagNewValue() method can be used. As mentioned before, usually it is hard to get the sequential number of the tag whose value to be changed especially, when the XML file is large. So, it is essential to have other approaches to deal with such problems.

changeByKeyTagKeyValueUpdateTagNewValue() modifies XML files based on key tags, not sibling tags. The format of the method is shown as follows.

The above code changes the value of the third ContractName from CreditCheckingContract to CreditContract. The method accesses the tag's value through its key tag, Organization, and its value, RequiredCreditChecking.com. After the operation, the changed XML file is shown as follows.

List 12. The XML file after the operation, changeByKeyTagKeyValueUpdateTagNewValue()

2.3.8 changeByKeyTagKeyValueSiblingTagUpdateTagNewValue()

Sometimes, it is necessary to modify a tag's value based on both of key tags and sibling tags. For example, users would like to modify the value, CreditRequestNo, of the VocabularyName tag. The changeByTagNewValue() method can be used to do that. For a small XML file, it must work correctly. However, if the XML file is large, this method is easy to impact other tags' value because it does not provide enough information to figure out which tag's value is to be changed.

changeBySiblingTagNewValue() does not work properly because there is another VocabularyName whose sibling tag's value is the same as the one to be changed. changeBySiblingTagUpdateTagNewValue() cannot deal with the case either. Although the method provides a new parameter to specify the tag to be changed, the sibling tag is the same as the tag to be changed in this case.

changeByKeyTagKeyValueUpdateTagNewValue() does not work either because there are two identical tags (VocabularyName) whose key tag (Organization) is also the same. If you use the method, both of the values of the two tags (VocabularyName) will be changed.

To handle this problem, a new method, changeByKeyTagKeyValueSiblingTagUpdateTagNewValue(), which combines the changeBySiblingTagUpdateTagNewValue() and changeByKeyTagKeyValueUpdateTagNewValue(), is designed. The format of the method is shown as follows.

2.3.9 changeByMultipleTagsAndWhere()

changeByMultipleTagsAndWhere() is the most powerful method to modify XML files. It is used to modify more complicated XML files than the ones mentioned above. For example, by using changeByKeyTagKeyValueSiblingTagUpdateTagNewValue(), only three-level XML files can be changed. The three levels are key tag, sibling tag, and update tag. Although in most cases it is not so difficult to figure out three levels to do modification even in a complicated XML file, it is better to design a method that supports no limited levels XML files modification. changeByMultipleTagsAndWhere() is the method to do that.

WEBINAR:On-Demand

2.4 Searching

LBXML Operator provides ten methods to search XML files. Similar to other methods in LBXML Operator, searching conditions are specified through method interfaces (APIs). Another feature is that searching results are returned into C# powerful data structures, such as String and Hashtable, which are convenient for further processing.

2.4.1 selectByKeyTag()

selectorByKeyTag() is utilized to search the value of the tag that is unique in an XML file. The format of the method is shown as follows.

String selectByKeyTag(String xmlFile, String keyTag)

For example, to search the value of the Version tag, the code is written as follows.

2.4.2 selectByTagAndWhere()

selectorByKeyTag() is not suitable to search the value of the tag that is not unique in an XML file. For example, to search the value of the User tag, it is a good idea to use selectByTagAndWhere() because User is not the unique tag in the XML file. The format of the method is shown as follows.

After the above is executed, the following result is displayed. The User's value is customer.

user = customer

2.4.3 selectByBelowTagAndWhere()

In the parameters of the selectByTagAndWhere() method, the key tag is beyond the tag to be searched. Sometimes it is probable that the key tag is below the tag to be searched. The selectByBelowTagAndWhere() method is used to handle this problem. The format of the method is shown as follows.

2.4.4 selectHash()

It is always possible that a tag has multiple entries in an XML file and sometimes users would like to obtain all the values of a particular tag. In this case, the selectHash() method is suitable to retrieve all the values of a particular tag and store them into a C# Hashtable. The format of the method is shown as follows.

Hashtable selectHash(String xmlFile, String hashTag)

For example, to retrieve all the values of the VocabularyName tag in the XML file, the code is written as follows.

2.4.5 selectSet()

Similar to the selectHash() method, the selectSet() method also deals with the problem to retrieve all the values of a particular tag in an XML file. The difference between them is that the result of selectSet() is stored into Hashtable in which the same value for different keys does not exist. The format of the method is shown as follows.

Hashtable selectSet(String xmlFile, String setTag)

For example, to do the same searching in Section 2.4.4, the code is written as follows.

It is noted that OrderedNumber appears two times in the result of selectHash(), but it has only one entry in the result of selectSet() because the result is stored in Hashtable instead of Hashtable.

2.4.6 selectByTagAndWhereForHash()

selectByTagAndWhereForHash() is the integration of the selectByKeyAndWhere() method and the selectHash() method. Because it is required to specify a key tag and its value in the parameters of the method, the number of searching results is smaller than that from selectHash(), i.e., only the values that are related to the key tag are returned into a Hashtable. The format of the method is shown as follows.

2.4.7 selectByTagAndWhereForSet()

Similar to the selectByTagAndWhereForHash() method, selectByTagAndWhereForSet() has the same functionality. The difference is that the searching result is returned into a Hashtable for set instead of a Hashtable. The format of the method is shown as follows.

2.4.8 selectByMultipleTagsAndWhere()

selectByMultipleTagsAndWhere() is a powerful searching approach. By using this method, users can specify more complex conditions to retrieve a value of a tag than the ones in the above sections. The method is suitable to XML files that have a lot of levels. Usually, when the level of an XML exceeds four, it is possible to consider using the method. The format of the method is shown as follows.

There are two Hashtables in the parameters of the method. The two Hashtables are used to store complex conditions to retrieve a value of a tag. The first one, keyTagHash, is used to store key tags and the second, keyValueHash, is used to store corresponding key values. With those constraints, the method is able to retrieve the value of a particular tag exactly.

To demonstrate the utilization of the method, the XML file is changed as follows.

For example, to search the value of the ContractName tag, which is underlined, all the methods in the above section are not suitable because there is no unique key in the XML file. Because the method provides the parameters to specify multiple key tags and values, it can be used here to deal with this case. The corresponding code is written as follows.

2.4.9 selectByMultipleTagsAndWhereForHash()

Although selectByMultipleTagsAndWhere() is able to handle searching complex XML files, there is a big drawback for it. Sometimes, after specifying all the tags and corresponding values, it is possible that the result is not unique as selectByMultipleTagsAndWhereForHash() expects. To handle this problem, selectByMultipleTagsAndWhereForHash() is a good choice because the result is allowed to be not unique and stored into a Hashtable. The format of the method is as follows, which is similar to selectByMultipleTagsAndWhere() and expects return values.

For example, there is an XML file shown in List 17. If users need to retrieve the value of the ExternalPropertyName tag for PC of the Organization, BigBug.com, none of the above methods can be used here. Multiple tags and corresponding values are required to be specified in this case; meanwhile, the searching results are not unique.

2.4.10 selectByMultipleTagsAndWhereForSet()

selectByMultipleTagsAndWhereForSet() is similar to selectByMultipleTagsAndWhereForHash() expect for the type of return values. By using selectByMultipleTagsAndWhereForSet(), the searching result is stored into a Hashtable for the set instead of a Hashtable. Because those two methods are almost the same, the example for the method is omitted. The format of the method is shown as follows.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date