Please take a look at the way a frame is decoded.
A Decoder object guides the decode. It passes a DecoderStream (something like
that) to a parameter's member function. That member function asks for each
field in order and provides name and type information.
An XML decoder should be able to leverage the existing approach. Determine the
kind of parameter, instantiate one, ask it to pull out the fields which it does
with callbacks, then whatever is left is subparameters. Process the
subparameters placing them on the AllList. Once done, ask the original
parameters assimilate function to put them in the right place.
Hope this helps.
Regards,
-gww
________________________________
From: Klaus Holst Jacobsen [mailto:[email protected]]
Sent: Sunday, December 13, 2009 11:56 PM
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary format
Yes that "assimilate" function was exactly what I was looking for. With this
mechanism it is possible to create proper CElement derived objects without
knowing the exact type at time of creation.
But now I stumbled on the next challenge: Fields. Is there a similar mechanism
to add fields to parameters anonymously and then "assimilate" those fields
afterwards? Or will I have to use the specific get/set methods in the derived
CParameter classes?
//Klaus
________________________________
From: Gordon Waidhofer [mailto:[email protected]]
Sent: 11. december 2009 22:48
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary f ormat
The AllList holds parameters to aid deallocations, and to hold subparameters
during frame->internal conversion. The AllList plays no role in internal->frame
conversion.
During frame->internal conversion, all subparameters in the frame are placed on
the all list. Then an "assimilate" function places the subparameters on the
proper, specific member variables (like m_pROSpec). If a subparameter is not
recognized and, hence, there is no specific member to place it on, the
subparameter is still properly deallocated because it is on the AllList.
Order of subparameters is important for conformance. That's when the
internal->frame conversion is done by a function that uses the specific members
rather than the AllList. There is no constraint on order for things being in
the AllList.
In short, XML->internal for CPP would be nice. But because CPP has to work with
both Linux/Unix and Windows platforms, and because native XML infrastructure is
so radically different between the two, we've never had the time to work
through all the concerns.
Hope this helps.
Regards,
-gww
________________________________
From: Klaus Holst Jacobsen [mailto:[email protected]]
Sent: Thursday, December 10, 2009 12:00 AM
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary f ormat
Hey
Thanks for all the very quick responses.
Sounds like a good idea with perl and binary representation.
I have however not yet given up the thought of having cpp encode from xml
directly. On thing that struck me as kind of odd though is the following. Each
CElement has a list of parameters (m_listAllSubParameters), but at the same
time e.g. the CADD_ROSPEC message has a member variable (m_pROSpec) holding the
contained ROSpec parameter. But why not simply hold the ROSpec parameter of
CADD_ROSPEC in the Celement::m_listAllSubParameters instead of having a
dedicated member variable. This would make it so much easier to parse from XML
to objects without having to know the identity of the object you're parsing
right now in order to use special set methods.
Or said in other words:
What would happen if I added a CROSpec parameter to a CADD_ROSPEC message using
Celement::addSubParameterToAllList(...) instead of CAD_ROSPEC::setROSpec(...)
and then parsed that to binary and sent it to a reader?
//Klaus
-----Original Message-----
From: John R. Hogerhuis [mailto:[email protected]]
Sent: 10. december 2009 01:10
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary f ormat
On Wed, Dec 9, 2009 at 3:53 PM, Paul Dietrich <[email protected]> wrote:
> As an alternate to Johns idea, it may be possible to store your
> configurations in their binary format.
>
Excellent idea... as an extension of that concept, if you need to edit LTK-XML
interactively, LTK-Perl script could be used from the command line as an
intermediary for converting to/from binary format.
So if you edit LTK-XML with a text editor, you can compile it to binary with
Perl. Then LTK-CPP will allow you to manipulate the binary form. Similarly you
can take binary, use Perl to convert to XML, then edit it.
-- John.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
