Randy Leonard wrote:
Have Issues JIBX-6, 8, and 38 been investigated and planned for resolution? If not, has it been determined they are difficult problems to resolve?
38 is xs:choice support for the generation from schema, and I'll let Cameron address that one. 8 is the equivalent for basic JiBX support. This does not present any great problems, but will be part of the changes going into the beta 4 code generation model once I have that working.
6 is just intended as an example of one particular way of using JiBX, for streaming; I don't know of any problems with doing this currently, but would like to have a concrete demonstration for users. The only tricky part in this would be the streaming of both input and output, since I'd like to show a document being modified on-the-fly. Implementing it would involve a special (JiBX-aware) streaming class at the level of the nested repeating components to be processed. So for example, this would handle the <c> elements in a document of this type:
<a> <b> <c>...</c> ... <c>...</c> </b> </a>
The streaming class would need to be used as a field of the containing object in the unmarshalled object hierarchy (so the object corresponding to element <b> in the above example). This hook class would implement a pre-set method, as well as an iter-method so that it could be treated as a collection when marshalling (it'd also need the get-method to support unmarshalling as a collection, but this would actually be bypassed by the internal operation). The repeating components would need to be <mapped> in the binding definition. Then here's the flow of how this would operate:
1. Normal unmarshalling to level of the streaming class
2. When pre-set method is called for the streaming class, it saves
the UnmarshallingContext and creates (or access from a predefined
location) a MarshallingContext and uses it to marshal from the
root of the object tree
3. When the marshalling reaches the hasNext() method of the streaming
class iterator, use the saved UnmarshallingContext to find the
IUnmarshaller class instance for the streamed child component and
see if an instance is present with a call to the isAt() method,
returning the result
4. When the next() method of the streaming class iterator is called,
unmarshal the next child component, process it with the
application call, and return it for marshalling (after which step
(3) will be repeated by the marshalling process)
5. Once no more child components are found in step (3), the
marshalling will just finish normally.This assumes that you don't really need to complete the unmarshalling process before completing the marshalling after the last of the streamed child components has been handled. If you *do* need to complete unmarshalling, a different approach with separate threads would need to be used. The threading overhead would hurt performance to some extent, but if the components are complicated enough to be worth streaming this would probably not be a major concern.
- Dennis
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ jibx-devs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-devs
