Michael DeHaan wrote:
James Cammarata wrote:
Thanks for the explanation.
I'll continue with the UI preferences using the current CobblerWeb. The core functionality is in the remote XMLRPC and can be reused.
I was also thinking that adding more information about the item fields is required. For example the header, default width of a column, output format, url format, action-function (e.g. for add/delete/rename).
Peter
I think adding settings to control output format is a Bad Thing. You should not have your code care about the output format. Any customization to the user interface should be controlled via CSS.
Replace "width" with "css_class" then? I like it a lot.
As for adding methods to the objects to tell the display code what fields are available (and type, list of options, etc), is a Good Thing, and what mpdehaan outlined is exactly what I was going to propose.
cobbler-devel mailing list cobbler-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
Additional, we can further automate this by including what writer each field uses and also what the CLI option is named.
If a field is "kernel_options" in terms of implementation, it might be --kopts, and the setter is "set_kernel_options".
That way we can build the CLI, as well as the code to apply the CLI changes (and the webapp) mostly programatically.
Minor snags will be hit when dealing with network interfaces, I'd suspect, we'll see.