Jacob Kaplan-Moss wrote: > > Hey Robert -- > > As always, great questions... > > On Dec 20, 2005, at 8:36 AM, Robert Wittams wrote: > >> 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. > > > I talked with Wilson about the idea of multi-level edit-inline, and > although we both agree it's a really cool idea, it's probably nigh- > impossible to make a generic UI for it that isn't confusing. I like > the idea of allowing it at the manipulator level, though. That way if > you want to create a specialized multi-level edit-inline (with a UI > that fits your app) you can, and we can always tackle a generic UI for > it later.
I agree that the UI could be very difficult to do on a generic level, just don't want to preclude it on user code. I guess one idea would be to have a tree instead of a list on the side of the edit inline stuff in the ticket 13 mockup. But that can wait. > Where are you on refactoring manipulators? If that's something that > you're going to get to quick I'll hold off on starting the major work > until the manipulators stabilize. I'm pretty fired up to work on this, > though :) Cool ;-) Really, the only thing that really needs to be done is ripping apart the automatic manipulator saving code, so that it doesn't do anything other than saving itself and its children. The other evil bit here is FileFields. They need a few api changes so that they only save the file when the object itself is saved, currently there is funny special casing in the manipulator for them. This will of course break the current inline editing thing, which is why I was holding off. So if you are getting started ( are you going to do this in magic-removal), it will be ok to break it. >> Also, not sure about the point of maintaining the core= option if we >> are changing >> so much other stuff. > > > I could go either way here. The main reason I said this is that I've > got... let's see... just over 300 models (yikes!) to remove core from > (along with all the edit_inline options) and I'd rather let the > validator tell me where to look than chase down KeyErrors (or > whatever). If you (or anyone) feels strongly about it I'll just give > 'em the axe. Yeah, I see your point. Maybe the way to deal with this is to store it in a different place in the instance for now, so we can easily find other code trying to access it (mainly manipulator stuff). Maybe even stuff into something like a self.deprecated_args list.... > > Yeah, I that's probably the best-case scenario. I'll see if I can make > this work and use my idea as a fallback. > > Not sure about the back button tricks; it doesn't seem to make sense to > have back undo ordering or whatever. Dojo makes it pretty easy to > register history events, though, so I'll use it where appropriate. Yeah, I know what you mean, its always hard to know exactly how web pagish and how applicationish you want to be. What is your plan with dojo? eg how should it be served, should it be its own "app", so it can be shared by the admin and other stuff? Robert
