[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cobbler-devel
Subject:    generic item.printable and to_datastruct
From:       mdehaan () redhat ! com (Michael DeHaan)
Date:       2009-04-23 15:34:36
Message-ID: 49F08A8C.1050203 () redhat ! com
[Download RAW message or body]

Vreman, Peter - Acision wrote:
> > > 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. 
> 
> 
> 

It looks good to me in terms of fields, possibly adding the "group" 
field to keep some things together might be useful (see how the web app 
is color coded today and keeps certain fields next to each other).
> 
> 
> 
> > 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.  

Sounds good to me!

> 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. 
> 
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel
> 


[prev in list] [next in list] [prev in thread] [next in thread]