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.
(Can you tell I'm a big fan of incremental development?)
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 :)
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.
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.
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.
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.
That's the idea. The new interface makes dealing with a huge list of
related objects easier, plus I'm going to add the option to load edit-
inline objects in a collapsed state which will actually delay the
loading of the object information until you actually want to edit
it. That'll make pages with lots of related objects more snappy.
+1 on Dojo, it seems to do what we need.
Frameworkalicious.
Jacob
