Vreman, Peter - Acision wrote:
The idea with Django is we need to move off of our custom "web framework" type infrastructure and stop relying on something as low level and non-standard as raw mod_python.
I think it's ok for you to go ahead and do what you are doing in Cobbler Web and we can easily port those ideas to the Django version as we get to them.
In the long term CobblerWeb will not be used, but nearly all of the code that is there is going to be ported. I think ideally we get the Django stuff a nice push (merging into devel very shortly) and we can get the init scripts and packaging done for it to where it will be easy to just add things to the Django bits.
Part of what I'd like to see for this, too, is a system that makes it much easier for people adding new fields to the web app. Right now it's a bit of core, which means some features in the CLI /aren't/ in the web app.
This /might/ mean a way of defining what the fields are, what HTML element to use, and what their tooltips are, and their orders are, in the item classes. This may also make the port easier.
I'm not entirely sure what that would mean for the network interface editor. Currently it's "very special" and could use some refactoring. I don't think this should end up being a straight port as there is obvious room for some eventual UI improvements.
When doing this we /do/ want to make sure all features get carried over though, so we are definitely not wanting to lose any of the nice work already done.
Getting the Django version moving ahead ASAP should enable this to be done easier.
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
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel
How about a method on each object that returns a list:
def get_web_elements_format
return
[ fieldname, fieldtype (text, select, etc) fieldwidth, tooltip, ], [], [..]
We'd also need to do something clever to populate the fields... though that would make dual maintaince of the CLI and templates mostly go away.
For 2.0 (i.e. not now) we could also add a method that adds the CLI options for any command, moving the code out of the CLI modules just a bit... though I think folks have much less problem adding things to those so it's less important.
Right now CobblerWeb is just kind of weird.
--Michael