8:13 p.m.
This is a multi-part message in MIME format.
--------------060000080308030607050901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi all,
Now I'm using the code generation suites of ovirt-engine-sdk, I find it
is very troublesome.
IMO, we can simplify the process. And I want to engaged in it.
there are two tools parse the api.xsd and generate the params.py code.
They are generateds_gui.py and generateDS.py.
but there still some code can not be generate by these tools. now we
should add these codes manually.
the not NOT_GENERATED codes are as follow in the current params.py code:
1. import python module
2. a new attribute of GeneratedsSuper class
3. modify the get_root_tag function.
4. modify the parseString function to shut up the stdout.
5. _rootClassMap
6 . _elementToClassMap
7. findRootClass
And I have two ideas about the code generation.
For we should not modify the generateDS.py tools.
But we can improve it.
I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
So I want to add an configure file to tell how to add the extra code
that are not generated by generateDS.py tools.
And new python program, as extension of generateDS.py to read the
configure file and generate these codes.
Or without the configure file, just make the new python program that
supports an interactive commands.
--------------060000080308030607050901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all, <br>
<br>
Now I'm using the code generation suites of ovirt-engine-sdk, I find
it is very troublesome.<br>
<br>
IMO, we can simplify the process. And I want to engaged in it.<br>
<br>
there are two tools parse the api.xsd and generate the params.py
code. They are generateds_gui.py and generateDS.py.<br>
but there still some code can not be generate by these tools. now we
should add these codes manually. <br>
<br>
the not NOT_GENERATED codes are as follow in the current params.py
code:<br>
1. import python module <br>
2. a new attribute of GeneratedsSuper class<br>
3. modify the get_root_tag function.<br>
4. modify the parseString function to shut up the stdout. <br>
5. _rootClassMap <br>
6 . _elementToClassMap<br>
7. findRootClass <br>
<br>
And I have two ideas about the code generation.<br>
For we should not modify the generateDS.py tools. <br>
But we can improve it. <br>
<br>
I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be
configured.<br>
So I want to add an configure file to tell how to add the extra code
that are not generated by generateDS.py tools.<br>
And new python program, as extension of generateDS.py to read the
configure file and generate these codes.<br>
<br>
Or without the configure file, just make the new python program that
supports an interactive commands. <br>
<span style="color: rgb(51, 51, 51); font-family: arial, sans-serif;
font-size: 24px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(245, 245,
245); display: inline !important; float: none; "></span>
</body>
</html>
--------------060000080308030607050901--
7:48 p.m.
Hi,
On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
Hi all,
Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very
troublesome.
I completely agree with you, automating python entities generation is on top
of my TODO stack see [1],
Along with this, there was always something more important to do, and
it was delayed time after time, so your help is most welcome.
[1] http://www.ovirt.org/wiki/SDK#codegen
IMO, we can simplify the process. And I want to engaged in it.
there are two tools parse the api.xsd and generate the params.py code. They are
generateds_gui.py and generateDS.py.
but there still some code can not be generate by these tools. now we should add these
codes manually.
the not NOT_GENERATED codes are as follow in the current params.py code:
1. import python module
2. a new attribute of GeneratedsSuper class
3. modify the get_root_tag function.
4. modify the parseString function to shut up the stdout.
5. _rootClassMap
6 . _elementToClassMap
7. findRootClass
And I have two ideas about the code generation.
For we should not modify the generateDS.py tools.
But we can improve it.
I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
So I want to add an configure file to tell how to add the extra code that are not
generated by generateDS.py tools.
And new python program, as extension of generateDS.py to read the configure file and
generate these codes.
sounds good, btw 5,6 can be constructed programmatically using __all__ generated by
generateDS
and finding element name in xsd by type (from __all__).
Or without the configure file, just make the new python program that supports an
interactive commands.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
7:06 p.m.
On 05/26/2012 01:48 AM, Michael Pasternak wrote:
Hi,
On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
> Hi all,
>
> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very
troublesome.
I completely agree with you, automating python entities generation is on top
of my TODO stack see [1],
Along with this, there was always something more important to do, and
it was delayed time after time, so your help is most welcome.
[1] http://www.ovirt.org/wiki/SDK#codegen
> IMO, we can simplify the process. And I want to engaged in it.
>
> there are two tools parse the api.xsd and generate the params.py code. They are
generateds_gui.py and generateDS.py.
> but there still some code can not be generate by these tools. now we should add these
codes manually.
>
> the not NOT_GENERATED codes are as follow in the current params.py code:
> 1. import python module
> 2. a new attribute of GeneratedsSuper class
> 3. modify the get_root_tag function.
> 4. modify the parseString function to shut up the stdout.
> 5. _rootClassMap
> 6 . _elementToClassMap
> 7. findRootClass
>
> And I have two ideas about the code generation.
> For we should not modify the generateDS.py tools.
> But we can improve it.
>
> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
> So I want to add an configure file to tell how to add the extra code that are not
generated by generateDS.py tools.
> And new python program, as extension of generateDS.py to read the configure file and
generate these codes.
sounds good, btw 5,6 can be constructed programmatically using __all__ generated by
generateDS
and finding element name in xsd by type (from __all__).
should all the element name
in xsd by type be added to _rootClassMap,
and no element can be exception?
> Or without the configure file, just make the new python program
that supports an interactive commands.
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
8:56 a.m.
On 05/27/2012 08:06 PM, ShaoHe Feng wrote:
On 05/26/2012 01:48 AM, Michael Pasternak wrote:
> Hi,
>
> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
>> Hi all,
>>
>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it is
very troublesome.
> I completely agree with you, automating python entities generation is on top
> of my TODO stack see [1],
>
> Along with this, there was always something more important to do, and
> it was delayed time after time, so your help is most welcome.
>
> [1] http://www.ovirt.org/wiki/SDK#codegen
>
>> IMO, we can simplify the process. And I want to engaged in it.
>>
>> there are two tools parse the api.xsd and generate the params.py code. They are
generateds_gui.py and generateDS.py.
>> but there still some code can not be generate by these tools. now we should add
these codes manually.
>>
>> the not NOT_GENERATED codes are as follow in the current params.py code:
>> 1. import python module
>> 2. a new attribute of GeneratedsSuper class
>> 3. modify the get_root_tag function.
>> 4. modify the parseString function to shut up the stdout.
>> 5. _rootClassMap
>> 6 . _elementToClassMap
>> 7. findRootClass
>>
>> And I have two ideas about the code generation.
>> For we should not modify the generateDS.py tools.
>> But we can improve it.
>>
>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
>> So I want to add an configure file to tell how to add the extra code that are not
generated by generateDS.py tools.
>> And new python program, as extension of generateDS.py to read the configure file
and generate these codes.
> sounds good, btw 5,6 can be constructed programmatically using __all__ generated by
generateDS
> and finding element name in xsd by type (from __all__).
should all the element name in xsd by type be added to _rootClassMap, and no element can
be exception?
basically yes, cause _rootClassMap is <name, type> holder which used for (by name)
type retrieval,
only exception is if certain type is not referenced by any other type (then none will look
for
it during the type construction), but i would not implement this logic.
>> Or without the configure file, just make the new python program that supports an
interactive commands.
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
9:26 a.m.
On 05/28/2012 02:56 PM, Michael Pasternak wrote:
On 05/27/2012 08:06 PM, ShaoHe Feng wrote:
> On 05/26/2012 01:48 AM, Michael Pasternak wrote:
>> Hi,
>>
>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
>>> Hi all,
>>>
>>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it
is very troublesome.
>> I completely agree with you, automating python entities generation is on top
>> of my TODO stack see [1],
>>
>> Along with this, there was always something more important to do, and
>> it was delayed time after time, so your help is most welcome.
>>
>> [1] http://www.ovirt.org/wiki/SDK#codegen
>>
>>> IMO, we can simplify the process. And I want to engaged in it.
>>>
>>> there are two tools parse the api.xsd and generate the params.py code. They
are generateds_gui.py and generateDS.py.
>>> but there still some code can not be generate by these tools. now we should
add these codes manually.
>>>
>>> the not NOT_GENERATED codes are as follow in the current params.py code:
>>> 1. import python module
>>> 2. a new attribute of GeneratedsSuper class
>>> 3. modify the get_root_tag function.
>>> 4. modify the parseString function to shut up the stdout.
>>> 5. _rootClassMap
>>> 6 . _elementToClassMap
>>> 7. findRootClass
>>>
>>> And I have two ideas about the code generation.
>>> For we should not modify the generateDS.py tools.
>>> But we can improve it.
>>>
>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
>>> So I want to add an configure file to tell how to add the extra code that are
not generated by generateDS.py tools.
>>> And new python program, as extension of generateDS.py to read the configure
file and generate these codes.
>> sounds good, btw 5,6 can be constructed programmatically using __all__ generated
by generateDS
>> and finding element name in xsd by type (from __all__).
> should all the element name in xsd by type be added to _rootClassMap, and no element
can be exception?
basically yes, cause _rootClassMap is<name, type> holder which used for (by name)
type retrieval,
only exception is if certain type is not referenced by any other type (then none will
look for
it during the type construction), but i would not implement this logic.
Hi Michael,
what's your account on ovirt IRC channel?
>>> Or without the configure file, just make the new python
program that supports an interactive commands.
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
9:54 a.m.
On 05/28/2012 03:26 PM, ShaoHe Feng wrote:
On 05/28/2012 02:56 PM, Michael Pasternak wrote:
> On 05/27/2012 08:06 PM, ShaoHe Feng wrote:
>> On 05/26/2012 01:48 AM, Michael Pasternak wrote:
>>> Hi,
>>>
>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
>>>> Hi all,
>>>>
>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I
>>>> find it is very troublesome.
>>> I completely agree with you, automating python entities generation
>>> is on top
>>> of my TODO stack see [1],
>>>
>>> Along with this, there was always something more important to do, and
>>> it was delayed time after time, so your help is most welcome.
>>>
>>> [1] http://www.ovirt.org/wiki/SDK#codegen
>>>
>>>> IMO, we can simplify the process. And I want to engaged in it.
>>>>
>>>> there are two tools parse the api.xsd and generate the params.py
>>>> code. They are generateds_gui.py and generateDS.py.
>>>> but there still some code can not be generate by these tools. now
>>>> we should add these codes manually.
>>>>
>>>> the not NOT_GENERATED codes are as follow in the current
>>>> params.py code:
>>>> 1. import python module
>>>> 2. a new attribute of GeneratedsSuper class
>>>> 3. modify the get_root_tag function.
>>>> 4. modify the parseString function to shut up the stdout.
>>>> 5. _rootClassMap
>>>> 6 . _elementToClassMap
>>>> 7. findRootClass
>>>>
>>>> And I have two ideas about the code generation.
>>>> For we should not modify the generateDS.py tools.
>>>> But we can improve it.
>>>>
>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be
>>>> configured.
>>>> So I want to add an configure file to tell how to add the extra
>>>> code that are not generated by generateDS.py tools.
>>>> And new python program, as extension of generateDS.py to read the
>>>> configure file and generate these codes.
>>> sounds good, btw 5,6 can be constructed programmatically using
>>> __all__ generated by generateDS
>>> and finding element name in xsd by type (from __all__).
>> should all the element name in xsd by type be added to
>> _rootClassMap, and no element can be exception?
> basically yes, cause _rootClassMap is<name, type> holder which used
> for (by name) type retrieval,
> only exception is if certain type is not referenced by any other type
> (then none will look for
> it during the type construction), but i would not implement this logic.
>
Hi Michael,
what's your account on ovirt IRC channel?
seem I can not log on the #ovirt IRC
channel.
still some questions.
can I edit the generateDS.py directly in order to generate the params.py
code that we expect. and then rename the generateDS.py, put it into the
SDK directory?
or an new py program to call the functions of generateDS?
>>>> Or without the configure file, just make the new
python program
>>>> that supports an interactive commands.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
10:17 a.m.
On 05/28/2012 10:54 AM, ShaoHe Feng wrote:
On 05/28/2012 03:26 PM, ShaoHe Feng wrote:
> On 05/28/2012 02:56 PM, Michael Pasternak wrote:
>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote:
>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote:
>>>> Hi,
>>>>
>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
>>>>> Hi all,
>>>>>
>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I
find it is very troublesome.
>>>> I completely agree with you, automating python entities generation is on
top
>>>> of my TODO stack see [1],
>>>>
>>>> Along with this, there was always something more important to do, and
>>>> it was delayed time after time, so your help is most welcome.
>>>>
>>>> [1] http://www.ovirt.org/wiki/SDK#codegen
>>>>
>>>>> IMO, we can simplify the process. And I want to engaged in it.
>>>>>
>>>>> there are two tools parse the api.xsd and generate the params.py
code. They are generateds_gui.py and generateDS.py.
>>>>> but there still some code can not be generate by these tools. now we
should add these codes manually.
>>>>>
>>>>> the not NOT_GENERATED codes are as follow in the current params.py
code:
>>>>> 1. import python module
>>>>> 2. a new attribute of GeneratedsSuper class
>>>>> 3. modify the get_root_tag function.
>>>>> 4. modify the parseString function to shut up the stdout.
>>>>> 5. _rootClassMap
>>>>> 6 . _elementToClassMap
>>>>> 7. findRootClass
>>>>>
>>>>> And I have two ideas about the code generation.
>>>>> For we should not modify the generateDS.py tools.
>>>>> But we can improve it.
>>>>>
>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be
configured.
>>>>> So I want to add an configure file to tell how to add the extra code
that are not generated by generateDS.py tools.
>>>>> And new python program, as extension of generateDS.py to read the
configure file and generate these codes.
>>>> sounds good, btw 5,6 can be constructed programmatically using __all__
generated by generateDS
>>>> and finding element name in xsd by type (from __all__).
>>> should all the element name in xsd by type be added to _rootClassMap, and no
element can be exception?
>> basically yes, cause _rootClassMap is<name, type> holder which used for
(by name) type retrieval,
>> only exception is if certain type is not referenced by any other type (then none
will look for
>> it during the type construction), but i would not implement this logic.
>>
> Hi Michael,
> what's your account on ovirt IRC channel?
seem I can not log on the #ovirt IRC channel.
mpastern
still some questions.
can I edit the generateDS.py directly in order to generate the params.py code that we
expect. and then rename the generateDS.py, put it into the SDK directory?
or an new py program to call the functions of generateDS?
rewriting generateDS means that from now on we maintaining it (including bug fixes etc.),
i prefer new py module extending generateDS, and leaving maintenance of generateDS to
author/community.
>>>>> Or without the configure file, just make the new python program that
supports an interactive commands.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
1:49 p.m.
I have write an example. Now it can only add the import module
automatically .
see the attachment.
What about this way to add the NOT_GENERATED codes?
if OK, I will go ahead to add the left NOT_GENERATED codes.
such as how to add an attribute of an class.
On 05/28/2012 03:54 PM, ShaoHe Feng wrote:
On 05/28/2012 03:26 PM, ShaoHe Feng wrote:
> On 05/28/2012 02:56 PM, Michael Pasternak wrote:
>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote:
>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote:
>>>> Hi,
>>>>
>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote:
>>>>> Hi all,
>>>>>
>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I
>>>>> find it is very troublesome.
>>>> I completely agree with you, automating python entities generation
>>>> is on top
>>>> of my TODO stack see [1],
>>>>
>>>> Along with this, there was always something more important to do, and
>>>> it was delayed time after time, so your help is most welcome.
>>>>
>>>> [1] http://www.ovirt.org/wiki/SDK#codegen
>>>>
>>>>> IMO, we can simplify the process. And I want to engaged in it.
>>>>>
>>>>> there are two tools parse the api.xsd and generate the params.py
>>>>> code. They are generateds_gui.py and generateDS.py.
>>>>> but there still some code can not be generate by these tools. now
>>>>> we should add these codes manually.
>>>>>
>>>>> the not NOT_GENERATED codes are as follow in the current
>>>>> params.py code:
>>>>> 1. import python module
>>>>> 2. a new attribute of GeneratedsSuper class
>>>>> 3. modify the get_root_tag function.
>>>>> 4. modify the parseString function to shut up the stdout.
>>>>> 5. _rootClassMap
>>>>> 6 . _elementToClassMap
>>>>> 7. findRootClass
>>>>>
>>>>> And I have two ideas about the code generation.
>>>>> For we should not modify the generateDS.py tools.
>>>>> But we can improve it.
>>>>>
>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be
>>>>> configured.
>>>>> So I want to add an configure file to tell how to add the extra
>>>>> code that are not generated by generateDS.py tools.
>>>>> And new python program, as extension of generateDS.py to read
>>>>> the configure file and generate these codes.
>>>> sounds good, btw 5,6 can be constructed programmatically using
>>>> __all__ generated by generateDS
>>>> and finding element name in xsd by type (from __all__).
>>> should all the element name in xsd by type be added to
>>> _rootClassMap, and no element can be exception?
>> basically yes, cause _rootClassMap is<name, type> holder which used
>> for (by name) type retrieval,
>> only exception is if certain type is not referenced by any other
>> type (then none will look for
>> it during the type construction), but i would not implement this logic.
>>
> Hi Michael,
> what's your account on ovirt IRC channel?
seem I can not log on the #ovirt IRC channel.
still some questions.
can I edit the generateDS.py directly in order to generate the
params.py code that we expect. and then rename the generateDS.py, put
it into the SDK directory?
or an new py program to call the functions of generateDS?
>>>>> Or without the configure file, just make the new python program
>>>>> that supports an interactive commands.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:14 p.m.
New subject: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD
This is a multi-part message in MIME format.
--------------040905020303040609040101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi all,
as we all know the current params.py was not completely by the
generateSD.py, there are parts that have to be updated manually.
now I have post a primarypatch to improve it.
http://gerrit.ovirt.org/#/c/4880/
it can generate some codes, but still two parts codes can not be generated.
they aretwo dictionaries: _rootClassMap and _elementToClassMap.
However, for I do get any clue to know these two dictionaries from the
params.py.
there are some questions:
1.
And the __all__ list which include all the classes of _rootClassMap and
_elementToClassMap.
And there some classes both in _rootClassMap and _elementToClassMap.
2.
And some of class in _rootClassMap inherit GeneratedsSuper class, some
inherit BaseResource class, and two classes inherit Link class.
And it is the same with _elementToClassMap.
so what is the difference between _rootClassMap and _elementToClassMap.
What rule to generate these two dictionaries.
3.
And also, how to generate the keys in _rootClassMap and
_elementToClassMap.Any rule to generate them?
there are some items in these two dictionaries
"access_control_list" :
AccessControlList, # "_" among the word in key
"api" : API,
"body" : Body,
"iscsi" :
IscsiDetails, # key "iscsi" is one part of value
"IscsiDetails"
"storage_domain" : StorageDomain,
"topology" : CpuTopology,
"creation_status" : Status, #
key has a more word "creation" than the value.
"parent" : TagParent
--------------040905020303040609040101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font color="#000000">Hi all,<br>
<br>
</font><font color="#000000" size="3">as we all know
the current
params.py was not completely by the generateSD.py, </font><font
color="#000000"><font size="3">there are parts that
have to be
updated manually.</font><br>
<br>
now I have post a </font><font color="#000000"
size="3">primary</font><font
color="#000000"> patch to improve it.
<a class="moz-txt-link-freetext"
href="http://gerrit.ovirt.org/#/c/4880/">http://gerrit.ovirt...
<br>
it can generate some codes, but still two parts codes can not be
generated.<br>
<br>
they are</font><font color="#000000" size="3"> two
dictionaries:
_rootClassMap and _elementToClassMap</font><font
color="#000000">.<br>
<br>
However, for I do get any clue to know these </font><font
color="#000000" size="3"> two
dictionaries</font><font
color="#000000"> from the </font><font
color="#000000" size="3">
params.py</font><font color="#000000">.<br>
<br>
there are some questions:<br>
1.<br>
And the </font><font color="#000000"
size="3"> __all__ list which
include all the classes of _rootClassMap and
_elementToClassMap</font><font
color="#000000">. <br>
And there some classes both in </font><font
color="#000000"
size="3"> _rootClassMap and _elementToClassMap</font><font
color="#000000">. <br>
<br>
2.<br>
</font><font color="#000000">And some of class in
</font><font
color="#000000" size="3">_rootClassMap inherit
GeneratedsSuper
class, some </font><font color="#000000"
size="3">inherit
BaseResource class</font><font color="#000000"> , and two
classes
inherit Link class.<br>
And it is the same with </font><font color="#000000"
size="3">_elementToClassMap.<br>
<br>
so what is the difference between </font><font color="#000000"
size="3">_rootClassMap and _elementToClassMap.<br>
What rule to generate these two </font><font color="#000000"
size="3">dictionaries</font><font
color="#000000">.<br>
<br>
3. <br>
</font><font color="#000000" size="3">And also, how to
generate the
keys in </font><font color="#000000"
size="3">_rootClassMap and
_elementToClassMap.</font><font color="#000000">Any rule to
generate them?<br>
<br>
there are some items in these two </font><font color="#000000"
size="3">dictionaries</font><font
color="#000000"><br>
<br>
"access_control_list"
:
AccessControlList, # "_" among the word in
key<br>
"api"
:
API,
<br>
"body"
:
Body, <br>
"iscsi"
:
IscsiDetails,
# key "</font><font color="#000000">iscsi</font><font
color="#000000">" is one part of value
"</font><font
color="#000000">IscsiDetails"</font><br>
<font color="#000000">
"storage_domain"
: StorageDomain,<br>
"topology"
:
CpuTopology,
</font><br>
<font
color="#000000">
"creation_status"
:
Status,
</font><font
color="#000000"># key has a more word
"</font><font
color="#000000">creation</font><font
color="#000000">" than the
value.</font><br>
<font
color="#000000">
"parent"
: TagParent<br>
<br>
<br>
<br>
</font><br>
<br>
<span style="color: rgb(51, 51, 51); font-family: arial, sans-serif;
font-size: 24px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(245, 245,
245); display: inline !important; float: none; "></span> <br>
</body>
</html>
--------------040905020303040609040101--
8:04 p.m.
New subject: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD
On 06/07/2012 05:14 PM, ShaoHe Feng wrote:
Hi all,
as we all know the current params.py was not completely by the
generateSD.py, there are parts that have to be updated manually.
now I have post a primarypatch to improve it.
http://gerrit.ovirt.org/#/c/4880/
it can generate some codes, but still two parts codes can not be generated.
they aretwo dictionaries: _rootClassMap and _elementToClassMap.
However, for I do get any clue to know these two dictionaries from the
params.py.
The reason for these dictionaries is that "generateDS.py" generates
classes for the complex types inside the API .xsd, but it doesn't
generate anything for the tags that can appear as root tags in the XML
documents used by the API. The map helps the parser find the classes
that correspond to each of those tags.
It might be possible to generate this map from the list of classes using
a rule like this:
CamelCaseName -> camel_case_names
But there are exceptions like these:
VLAN -> vlan
IPs -> ips
IscsiDetails -> iscsi
You could write code that takes into account the exceptions and
generates the map. But I think it is not worth, and error prone. I would
rather take that chunk of code out of params.py and move it to an
external file or to a constant, like you do for other chunks of code in
paramsconf.py.
there are some questions:
1.
And the __all__ list which include all the classes of _rootClassMap and
_elementToClassMap.
And there some classes both in _rootClassMap and _elementToClassMap.
The "__all__" list is just a python mechanism to control the symbols
that are imported when you do something like "from whatever import *".
In this case "generateDS.py" is making sure that all the generated
classes are imported, which is not really relevant for us.
2.
And some of class in _rootClassMap inherit GeneratedsSuper class, some
inherit BaseResource class, and two classes inherit Link class.
And it is the same with _elementToClassMap.
so what is the difference between _rootClassMap and _elementToClassMap.
What rule to generate these two dictionaries.
I can't find any difference between those two dictionaries, they serve
exactly the same purpose. Maybe Michael had a future use in mind.
3.
And also, how to generate the keys in _rootClassMap and
_elementToClassMap.Any rule to generate them?
there are some items in these two dictionaries
"access_control_list" :
AccessControlList, # "_" among the word in key
"api" : API,
"body" : Body,
"iscsi" :
IscsiDetails, # key "iscsi" is one part of value
"IscsiDetails"
"storage_domain" : StorageDomain,
"topology" : CpuTopology,
"creation_status" : Status, #
key has a more word "creation" than the value.
"parent" : TagParent
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
7:30 p.m.
New subject: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD
still a question.
I find there are reduplicate items in _rootClassMap dictionary of
./src/ovirtsdk/xml/params.py file.
such as:
1.
in line 18924
"storage" : Storage,
in line 18931
"storage" : Storage,
above items has same key and value.
2.
in line 18905
"product_info" : ProductInfo,
in line 18934
"product_info" : ProductInfo,
above items has same key and value.
3.
in line 18953
"vm_pause_details" : VmPauseDetails,
in line 18962
"vm_pause_detail" : VmPauseDetails,
above items has value but different key.
is it OK ? or should I commit a patch to fix it?
On 06/08/2012 02:04 AM, Juan Hernandez wrote:
On 06/07/2012 05:14 PM, ShaoHe Feng wrote:
> Hi all,
>
> as we all know the current params.py was not completely by the
> generateSD.py, there are parts that have to be updated manually.
>
> now I have post a primarypatch to improve it.
> http://gerrit.ovirt.org/#/c/4880/
>
> it can generate some codes, but still two parts codes can not be
> generated.
>
> they aretwo dictionaries: _rootClassMap and _elementToClassMap.
>
> However, for I do get any clue to know these two dictionaries from the
> params.py.
The reason for these dictionaries is that "generateDS.py" generates
classes for the complex types inside the API .xsd, but it doesn't
generate anything for the tags that can appear as root tags in the XML
documents used by the API. The map helps the parser find the classes
that correspond to each of those tags.
It might be possible to generate this map from the list of classes
using a rule like this:
CamelCaseName -> camel_case_names
But there are exceptions like these:
VLAN -> vlan
IPs -> ips
IscsiDetails -> iscsi
You could write code that takes into account the exceptions and
generates the map. But I think it is not worth, and error prone. I
would rather take that chunk of code out of params.py and move it to
an external file or to a constant, like you do for other chunks of
code in paramsconf.py.
> there are some questions:
> 1.
> And the __all__ list which include all the classes of _rootClassMap and
> _elementToClassMap.
> And there some classes both in _rootClassMap and _elementToClassMap.
The "__all__" list is just a python mechanism to control the symbols
that are imported when you do something like "from whatever import *".
In this case "generateDS.py" is making sure that all the generated
classes are imported, which is not really relevant for us.
> 2.
> And some of class in _rootClassMap inherit GeneratedsSuper class, some
> inherit BaseResource class, and two classes inherit Link class.
> And it is the same with _elementToClassMap.
>
> so what is the difference between _rootClassMap and _elementToClassMap.
> What rule to generate these two dictionaries.
I can't find any difference between those two dictionaries, they serve
exactly the same purpose. Maybe Michael had a future use in mind.
> 3.
> And also, how to generate the keys in _rootClassMap and
> _elementToClassMap.Any rule to generate them?
>
> there are some items in these two dictionaries
>
> "access_control_list" :
> AccessControlList, # "_" among the word in key
> "api" : API,
> "body" : Body,
> "iscsi" :
> IscsiDetails, # key "iscsi" is one part of value
> "IscsiDetails"
> "storage_domain" : StorageDomain,
> "topology" :
> CpuTopology,
> "creation_status" : Status, #
> key has a more word "creation" than the value.
> "parent" :
> TagParent
8:57 a.m.
New subject: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD
On 06/08/2012 08:30 PM, ShaoHe Feng wrote:
still a question.
I find there are reduplicate items in _rootClassMap dictionary of
./src/ovirtsdk/xml/params.py file.
such as:
1.
in line 18924
"storage" : Storage,
in line 18931
"storage" : Storage,
above items has same key and value.
2.
in line 18905
"product_info" : ProductInfo,
in line 18934
"product_info" : ProductInfo,
above items has same key and value.
3.
in line 18953
"vm_pause_details" : VmPauseDetails,
in line 18962
"vm_pause_detail" : VmPauseDetails,
above items has value but different key.
is it OK ? or should I commit a patch to fix it?
should be single appearance of each element (it was handcrafted).
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
8:49 a.m.
New subject: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD
Hi,
On 06/07/2012 06:14 PM, ShaoHe Feng wrote:
Hi all,
as we all know the current params.py was not completely by the generateSD.py, there are
parts that have to be updated manually.
now I have post a primarypatch to improve it. http://gerrit.ovirt.org/#/c/4880/
(in review)
it can generate some codes, but still two parts codes can not be
generated.
they aretwo dictionaries: _rootClassMap and _elementToClassMap.
However, for I do get any clue to know these two dictionaries from the params.py.
there are some questions:
1.
And the __all__ list which include all the classes of _rootClassMap and
_elementToClassMap.
And there some classes both in _rootClassMap and _elementToClassMap.
2.
And some of class in _rootClassMap inherit GeneratedsSuper class, some inherit
BaseResource class, and two classes inherit Link class.
And it is the same with _elementToClassMap.
so what is the difference between _rootClassMap and _elementToClassMap.
What rule to generate these two dictionaries.
_elementToClassMap no longer relevant, you can place everything in _rootClassMap
3.
And also, how to generate the keys in _rootClassMap and _elementToClassMap.Any rule to
generate them?
you can traverse all elements in the schema creating data structure where key is the type
of the
schema element and value is the element name, for instance:
<xs:element name="special_objects" type="SpecialObjects"/>
_element_type_to_name_map {SpecialObjects, special_objects},
this way later when you go over items in __all__ [1] list, you can use each item as key
at _element_type_to_name_map to retrieve element name="special_objects".
[1] __all__ = [..., "SpecialObjects", ...]
there are some items in these two dictionaries
"access_control_list" : AccessControlList, #
"_" among the word in key
"api" : API,
"body" : Body,
"iscsi" : IscsiDetails,
# key "iscsi" is one part of value "IscsiDetails"
"storage_domain" : StorageDomain,
"topology" : CpuTopology,
"creation_status" : Status,
# key has a more word "creation" than the value.
"parent" : TagParent
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
4342
days inactive
4359
days old
12 comments
3 participants
participants (3)
-
Juan Hernandez -
Michael Pasternak -
ShaoHe Feng