On Sun, May 04, 2014 at 08:08:49PM +0800, Jinquan Liu wrote:
Jinquan,
I've attempted to answer and comment on several of your messages
below rather than send separate messages. Hope these answers help
a bit.
By, the way, I notice that your messages have several image files
attached, but I don't know what to make of them. Unless there is
something that you want me to look at in those images, I'd like to
ask that you not attach them so that we save some space in our
email folders. Thanks.
> Hi Dave,
>
> Thank you for your response. Here I want to report another issue. See below
> vcloud response xml:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <vmext:VimServer
>
[snip]
>
> </vmext:VimServer>
>
> And below is the instance parsed from above xml.
>
> As you can see, the type of this instance is not VimServerType, but which
> has been generated properly with generateDS. All sub elements could not be
> found in this object, such as Username, Url, etc. And I find the
> original_tagname_ is None for it. Is it a bug? And one more thing,
> VimServerType is also the content of VCloudExtention node, which I mentioned
> in the last mail. Some association between these two issues?
>
Notice that the export method in each generated representation class
takes an option argument named "name_". From what you write above,
it seems that it's the tag of the root element that is the issue.
If so, you can control that by passing the name_ argument to the
export method.
>
> class VimServerType(ServerType):
>
# ==============================================================
Here are a few more answers and comments.
>
> I found some issues today. If you have time, please take a look. :)
>
> 1. If I parse a VApp.xml from vcloud, I can find
> <VirtualHardwareSection/Item>¡¯s were parsed to object properly. But if I
> parse Item.xml, the subelements could not be found in the object. Is it
> normal?
>
I do not understand this question. Is Item.xml supposed to be the
input? If so, it does not contain a VirtualHardwareSection. And,
the definition of ItemType that I find in the Vcloud schema does not
define the child content that is in <Item> in Item.xml.
>
> 2. If we use xml.etree.ElementTreen as the underlying xml engine, it
> fails to parse the xml to object. Seems nsmap is not a property of ET node.
> Could we support ET as well, because some environment may have no lxml
> installed.
Lxml is a requirement for running generateDS.py. I'm not sure about
the code that is *generated* by generateDS.py. Perhaps you can get
that to workwith xml.etree.ElementTree.
At one time I believed that I could. But, I suspect that we need
the namespaces support that lxml gives us. Perhaps there are
restricted cases, where xml.etree.ElementTree will also work.
However, since I know that there are problems with that, I do not do
any testing except with lxml.
Dave
# ==============================================================
> Hi Dave,
>
> Just found one more issue: I tried parse <Vm> xml (Vm is root) to object.
> But I found the object type is VAppTemplate. But actually, it should be
> VmType. And I found the map in generated py file. The Vm is mapping to
> VAppTemplateType. It¡¯s unnormal¡
>
> 'Vm': VAppTemplateType,
>
> Also, I tested the serialization with below code. You can find the original
> xml and generated xml attached (I replaced ¡°\n¡± with whitespace already).
> Does it have some methods like toString(), and we can just call it to get
> xml string without formatting?
There is no toString() method, but since each export method writes to
a file, it is easy to write a function that serializes an object and
returns a string. For example:
import StringIO
def obj_to_string(obj):
file1 = StringIO.StringIO()
obj.export(file1, 0, pretty_print=True)
str1 = file1.getvalue()
return str1
Note that each export method takes additional optional arguments,
and so the above may need to be modified for you cases.
And, if you want that string to *not* be formatted, then replace
that one "export" line above with:
obj.export(file1, 0, pretty_print=False)
>
> Anyway, the generated xml does not keep the original namespaces prefixes and
> some prefixes are not defined in original xml. And the original root is
> <Vapp>, but instead in generated xml, it¡¯s <VAppType>¡ Well, I think I can
> find more issues, if you have time to take a look at these issues and if you
> have plans to fix them, just let me know. I¡¯m glad to test more.
>
Please be aware that what namespace prefix is used is unimportant as
long as it is used consistently and it refers to the correct
namespace.
However, generateDS.py and its generated code does have issues with
namespaces. So, I suspect that there *is* a real problem here.
I'll try to devote some time to looking at that later. And, in the
meantime, if you have suggestions or possible fixes, please send
them to me.
Dave
--
Dave Kuhlman
http://www.davekuhlman.org
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
