[xsde-users] RE: Processing variable length root elements as part of message parsing / serializing

[O'Laughlin, Terry]

Hi Boris,

Thanks for the prototype.  I'd just stumbled upon this type of thing earlier today, your example makes it more robust.

How about adding examples of 'variable-length' elements to the distribution?

Down the road, why not add this type of extra code to the code generation compiler?

OR

Treat every element as if it were 'variable-length'.
Return a pointer to the object model, which you do now, parserAggr.post().
Then for each element, you have a '_copy()' method.  Is this a deep copy?


I would rather not:

1) Have to treat elements differently just because they are variable-length.
2) 'look' under the cover of all the code that's generated to learn this stuff.

I'm taking your suggestion, I'm figuring that the only thing I need to work with is the object model code, plus the modified 'document_pimpl' in the 'multi-root' example, and even that, can't you guys generate the code for me?

I've got more to learn with XSD/e.  I think the tool is good.  It does a TON of stuff, so I can see that it would be hard to please all the people all the time.


Cheers,

Terry O'



-----------------------------------------------------
Please consider the environment before printing this email.

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com]
Sent: Tuesday, November 23, 2010 10:56 AM
To: O'Laughlin, Terry
Cc: xsde-users at codesynthesis.com
Subject: Re: Processing variable length root elements as part of message parsing / serializing

Hi Terry,

O'Laughlin, Terry <Terry.O'Laughlin at ipc.com> writes:

> I'm adapting the 'multiroot' example as we are using XML as the basis
> for messaging in a communications protocol. Works great with fixed-
> length messages. What do I need to do to adapt it to using variable
> length root elements?

If the root element type is variable-length, then you can store a
pointer to the object model instead of the value. Here is how one
can adapt the document_pimpl class from the 'multiroot' example
(only changed parts are shown):

  class document_pimpl: ...
  {
  public:
    ~document_pimpl ()
    {
      free ();
    }

    request_type
    result_type () const
    {
      return result_type_;
    }

    // Return the object model and release ownership.
    //
    protocol::balance*
    balance () const
    {
      protocol::balance r = balance_;
      balance_ = 0;
      return r;
    }

    protocol::withdraw*
    withdraw () const
    {
      protocol::withdraw r = withdraw_;
      withdraw_ = 0;
      return r;
    }

    virtual void
    reset ()
    {
      free ();

      xml_schema::document_pimpl::reset ();

      balance_p_.reset ();
      withdraw_p_.reset ();
    }

  private:
    void
    free ()
    {
      switch (result_type_)
      {
        case balance_type:
        {
          delete balance_;
          break;
        }
        case withdraw_type:
        {
          delete withdraw_;
          break;
        }
        unknown_type:
        {
          break;
        }
      }

      result_type_ = unknown_type;
    }

  private:
    request_type result_type_;
    protocol::balance* balance_;
    protocol::withdraw* withdraw_;
  };

Then, in main(), the relevant changes are as follows:

    // Print what we've got.
    //
    switch (doc_p.result_type ())
    {
    case balance_type:
      {
        balance* b = doc_p.balance ();
        cerr << "balance request for acc# " << b->account () << endl;
        delete b;
        break;
      }
    case withdraw_type:
      {
        withdraw* w = doc_p.withdraw ();
        cerr << "withdrawal request for acc# " << w->account () << ", "
             << "amount: " << w->amount () << endl;
        delete w;
        break;
      }
    case unknown_type:
      {
        cerr << "unknown request" << endl;
        break;
      }
    }

Boris

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.