RE: [jira] Commented: (AXISCPP-623) Support for the WSDL construct "all"

[Samisa Abeysinghe]

>>   3.Passer peek ahead. >>     Can we look ahead (without pulling) what element is the next? >>     Advantage of this is can keep the current DeSerializer code as it is. >>     Still additional check logic will be in generated code.   >1. To achieve this we can have add method to the DeSerializer code call "peekNextElement ()". >   From "peekNextElement ()" we can get which is the next element and it can use by the generated code. The method signature would be: char* peekNextElement(); Where the method returns the name of the next element to be pulled from XML stream   >2. In this "peekNextElement ()" method will call new method “peek ()”, which it is in XMLParserXerces.cpp file. >   This “peek ()” method will return the next node. Again the signature is: char* peek(); This calls the parseNext(m_ScanToken) method to pull the next xml element.   >3. To avoid to loose next element we have to change the “next ()” method to check whether “peek ()” is called >before and if it called then avoid call parseNext(m_ScanToken).   The generated code is supposed to be responsible for handling the logic for looking for the correct element, based on the expected construct as per the WSDL. This way we could keep the changed to the SoapDeSerializer methods to a minimum, but still be flexible enough to incorporate ‘all’ and ‘choice’ constructs.   Thanks, Samisa…       -----Original Message----- From: Chinthana C. Dinapala [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 10:50 AM To: Apache AXIS C Developers List Subject: RE: [jira] Commented: (AXISCPP-623) Support for the WSDL construct "all"     Hi all,     Do you guys have any comments on this?   Thanks   Chinthana     Subject: [jira] Commented: (AXISCPP-623) Support for the WSDL construct "all"        [ http://issues.apache.org/jira/browse/AXISCPP-623?page=comments#action_63752 ]      Chinthana Danapala commented on AXISCPP-623: --------------------------------------------   There are two kinds of changes that we have to looking in to this.       1. WSDL tool changes     2. DeSerializer changes.   1.) WSDL tool      1.1 How to decide if we have an "all" construct in WSDL?      1.2 When we come crosses "all" construct generate the code accordingly. Changes should be in DeSerialization part of the complex types.   2.) DeSerializer      2.1 Decide minOccurs 0 or 1.       If 1 then get (use current code.)       If 0 then check & get      2.2 Check & get        Here there are 3 possible changes.             1.We can have a list of element stored and can compare with the pulled one and select the matched one.           E.g.           List            Pulled one           A            B           B-->           C           D           Here we sellect the B from the list.           But in this option have additional check logic in generated code for each element. Also have to change current DeSerializer code.             2.Also we can go element in sequence order and if it is not matched with pulled one then go to next. But here need to figure out how to recover pulled element.             3.Passer  peek ahead.             Can we look ahead (without pulling) what element is the next?               Advantage of this is can keep the current DeSerializer code as it is.             Still additional check logic will be in generated code.