Jacob Kaplan-Moss wrote: > > Hey folks -- > > I'm starting to gear up on the removing core fields bit, and before I > get too deep into it I want to run my plan by everyone: > > First, "core" as a field option will die. Until 1.0 it will be > accepted and ignored -- but django-admin validate will complain about > it. 1.0 will remove the option entirely along with all the other > deprecated features.
Hi, What are you planning to do with the automatic manipulators? I had planned to make the manipulators "recursive", ie a parent manipulator would hold a list of child manipulators for each inline-editable collection. This would allow fairly easy multi-level edit inline. The main reason I didn't do this yet is the core fields nightmare. Also, not sure about the point of maintaining the core= option if we are changing so much other stuff. I didn't envisage turning off the whole of edit-inline for non-js people either. My thought was that in the non-JS case, a request would be made for each change "move this item up/down, delete this item, add a new item". In the JS case, these would be queued up, and all sent in the one save request, with gui and back button tricks. So the other question here was paging when there are a lot of inline editable objects, I think it could be done explicitly in the non-Js case with next, prev links , and behind the scenes eg with scrolling in the JS case. +1 on Dojo, it seems to do what we need. Robert
