Edit in Place with TurboGears widgets
andrei...@hotmail.com
as in http://tool-man.org/examples/edit-in-place.html
with TurboGears widgets? or with MochiKit? maybe it's possible to use
any other js library ( i.e. prototype.js ) with TurboGears?
Karl Guertin
> Is there a possibility to achieve the same edit in place functionality
> as in http://tool-man.org/examples/edit-in-place.html
> with TurboGears widgets? or with MochiKit?
I don't know of any prepackaged edit in place widgets. It's not that
hard to do with MochiKit, but I don't think anybody has done it and
released the code.
> maybe it's possible to use
> any other js library ( i.e. prototype.js ) with TurboGears?
Scriptaculous is packaged as a widget (easy_install Scriptaculous) for
easy use in TurboGears or you can stick whatever javascript library
you want in your <head> tags.
Adam Jones
andrei...@hotmail.com wrote:
> Is there a possibility to achieve the same edit in place functionality
> as in http://tool-man.org/examples/edit-in-place.html
> with TurboGears widgets?
How would you plan on having the widgets communicate changes back? That
is the real issue. Taking an existing widget and marking it for edit in
place behavior is trivial, just have to add the class "inplace" to your
form element.
As for handling communications back to TG, that is where things get
interesting. I think this is why there are no existing widgets to
handle this, as there are simply too many options. Do you send the raw
HTML back to turbogears? What about the previous HTML? If not that,
then how do you format changes in a way that is intelligible. What
about additional information that helps you figure out what a change on
the page is related to? Interesting problem, far too many solutions.
That said you could put together a widget that automatically handles
including the edit in place javascript library pretty easily. With a
bit of interesting hacking could get it to re-render its own template
as an editable form when it is sent out to the page. That would save at
least some of the trouble. Since TinyMCE is also available as a widget
it would probably be a snap to hook that up to the whole thing. Then
the only tricky part is sorting out backend communications for your
specific needs.
Jonathan LaCour
> How would you plan on having the widgets communicate changes
> back? That is the real issue.
The bottom line here is that widgets are really designed for slapping
together all of the front-end behavior for very specific things. I
have worked around this limitation on my own by embedding controllers
specific to a widget *within* the widget package itself, so that I can
bundle backend behavior with front-end behavior. This allows you to
do things like this:
from mywidgets.widgets import InplaceEditablePersonWidget
person_widget = InplaceEditablePersonWidget()
class Root:
def person_updated(self, person_id, person_dict):
'''
gets called when a person gets updated so that you can do
any application-specific things that aren't handled by the
widget itself
'''
person = person_widget.create_controller()
person.on_update(person_updated)
This basically allows you to bundle controllers with your widgets so
that they aren't limited to frontend functionality. You could easily
use something like this to make repackagable inline-editable widgets.
--
Jonathan LaCour
http://cleverdevil.org
Kevin Dangoor
> This basically allows you to bundle controllers with your widgets so
> that they aren't limited to frontend functionality. You could easily
> use something like this to make repackagable inline-editable widgets.
I've been coming at it from the other angle (and FastData is an
example of this). Rather than trying to embed controllers in widgets,
I would make a package (ie an egg) that includes the controllers
(subclassable) and the widgets. The controllers remain in control and
the widgets remain strictly a view-layer item. I think this format
will make good sense, particularly as we work out the kinks for
multiapplication deployment. (Elvelind has gotten a good head start
on this, but he's keeping us in suspense since he hasn't checked it
in yet :)
Kevin
Jonathan LaCour
> I've been coming at it from the other angle (and FastData is an
> example of this). Rather than trying to embed controllers in widgets,
> I would make a package (ie an egg) that includes the controllers
> (subclassable) and the widgets. The controllers remain in control and
> the widgets remain strictly a view-layer item.
There isn't really all that much difference between the two approaches
here. Either way, you install an egg, and you have access to a nice
widget that can hook up to an already available controller. Its just a
matter of where the controller lives. Although, I like my callback
approach better than subclassing a controller... it just seems easier to
me for some reason.
I would actually like to see TurboGears have a more well-defined system
for this kind of thing, although I am not sure what something like that
would look like. Fast Data seems like an excellent place to experiment
though.