On Fri, Mar 25, 2011 at 5:10 AM, Vreman, Peter peter.vreman@acision.com wrote:
On Thu, 24 Mar 2011 14:20:15 -0400, Stephen Potter spp@unixsa.net wrote:
On 3/24/2011 9:52 AM, Scott Henson wrote:
On Wed, 23 Mar 2011 21:52:14 +0000, Jonathan
Underwoodjonathan.underwood@gmail.com wrote:
Is this different behaviour expected/by design, or have the cli
and
web interfaces diverged somewhat?
It isn't expected, but it is known. Basically the web interface doesn't have a good mechanism for telling what you actually
changed,
so it saves everything. You basically end up with getting the defaults of the web interface. I don't have any good thoughts on
how to fix it at this time though.
Both the CLI and the web interface should give the same defaults. As I remember the original post, the only things that were set with the CLI were the host name and the profile, everything else was default. It isn't a matter of knowing what was changed, the defaults should still be the same defaults no matter what the interface.
The nature of the web interface is that it fills out the web page with everything that it gets back from cobblerd in the xmlrpc response. Then it sends back the edit request with everything it gets from the web page. So you end up with things getting set that the user never intends to set. I don't really know of any way to fix this. I've been considering trying to fix this at the xmlrpc layer, but we would have to do session handling and that is slightly undesirable.
If anyone has ideas on how to fix this, I'd be open to hearing them. Basically we would need to figure out how to do lossless translation between the various formats used (internal cobbler, xmlrpc, web).
A possible solution is to use jQuery to save the original data of the input elements. And during a submitting only include the input elements that are changed. If detecting changes is implemented with a class then pending changes on the page can even be highlighted with css.
There are a couple of (dirty) form plugins available for jquery that can be used.
I'm also not sure why sessions are out of consideration, it's pretty simple to do that with django. In fact it's already done for the login part.
When editing, first check to see if the object being edited is stored in the session. If not, save the fields data in the session. When the object is saved remove the field data from the session.