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(a)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.