> The patch will only add the method in the parent item class. All
child
> classes (e.g. system/distro) still have their old implementation. For
> the system item class I have added an initial get_field_info() tree.
> To (e.g. performance) test the new code also for the systems you can
> rename/remove the item_system.to_datastruct and item_system.printable.
I like where you are going here, but a few questions...
Looking over the item_system.py code, I see that a lot of the tooltip
fields are not set to what they were before in the web interface, and I
don't see changes to make the "cobbler system report" commands
use this data. So, given that, things look a little incomplete to me
right now. This is not saying we couldn't finish it, but it wasn't
what I was planning to work on; so I am going to hold off on applying
this for now. If you were planning on finishing this up, great!
The item_system.get_field_info() is generated by a shell script. It is incomplete because
I wanted feedback first if this is the right direction. That the output of
item_system.printable does not change much (except for the interfaces dictionary) is good.
The generic has item.printable() an argument nice_headers that will use a more readable
header insteaed of the variable name.
Something I really wanted to take a look at for 2.0 (not now) ...
was
come up with a better implementation that allows defining fields that
also reduces the boilerplate in the from/to datastruct methods and
elsehwere, while still preserving the various logic we use to enforce
validation at load time and such. TThis is something that I probably
need to do myself (not now, to be certain), so I can make sure the
upgrade cases are covered, though, so I think moving to replace all the
printable() functions moving forward and also share that with the web
app is a great thing that would be fine for 1.8
The item.to_datastruct was just a quick working example what is possible.
Do you plan on retrofiting the rest of the item_*.py objects to use
this
new way to defining fields, and also changing the Django web application
templates and "report" command code to use it? Another thing we'll
probably want is to be able to declare a group for fields, because the
current web application puts the fields in certain areas, like keeping
the networking information together. Things could show up as sorted
within the group.
I plan to use the current item_system.get_field_info first to code customizable tables in
the webui list pages. After that works the tooltips/headers can be cleaned-up.
Peter
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal
privilege. It should not be copied, disclosed to, retained or used by, any other party. If
you are not an intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.