[wp-hackers] Question about the architecture of the admin widgets.php

[John BouAntoun]

Thanks for the more in-depth analysis Andy. Sounds like I got what I was
looking for, which was a semi-confirmation that the dirty work-arounds I put
in place are the most practical for right now.

using the blur event for the triggerSave() may well be usefull, but it still
exposes the re-ordering issue. When you reorder the ajax items, the way it
is done effectively destroys the link between the mce editor and it's
textarea. You literally need to remove the editor from the DOM and recreate
it, which is why I override the edit button's click event, to re-create and
reload the editor.

This is what led me to believe that if the WP widgets page architecture
provided some form of client side hook/feature capability (as WP does on the
server side), like the ability to catch a pre/post sort and a pre/post save
event, things would be far more easier.

Unfortunately the only way to do ordered binding in jQuery is with a new
delegation plugin (not default jQuery binding) and is a common gripe about
it.So I don't think that's going to be workable anytime soon.

Also, I don't see the reasoning for moving from the object.bind('click') to
the object.live('click') approach except that it allows jQuery to handle the
binding for newly (later) created items that match the selector. The thing
is the WP architecture is always going to know about the new items as it
does the creating, so delegating the responsibility of event binding to
jQuery is just taking more control away from the devs for minimal benefit.
It's not like the click binding code has to be copied and pasted for every
instance of a widget, it's going to be in an iteration or loop of some kind
at object creation anyhow.

JBA

On Tue, Jan 5, 2010 at 1:33 PM, Andy Skelton <skeltoac at gmail.com> wrote:

> On Mon, Jan 4, 2010 at 5:59 PM, John BouAntoun <jbouantoun at gmail.com>
> wrote:
> > On Tue, Jan 5, 2010 at 9:45 AM, Andy Skelton <skeltoac at gmail.com> wrote:
> >> Study the way WordPress modifies the behavior of TinyMCE. Then do as
> core
> >> does.
> > It's not so much about modifying the behaviour of TinyMCE, which I think
> > I've figured out, but am open to suggestions. The issue is that since the
> > widget admin screen was cleaned up in WP circa 2.8 (to support auto
> > multi-widgets), the widget options forms are preloaded and saved using
> > boiler plate code that isn't complex enough to understand how to extract
> the
> > html form a rich text editor, which is why I needed to play silly buggers
> > with the javascript to trigger a save on the save button's click.
>
> I dug deeper. It's been a while since I parsed jQuery core and
> live/die are new to me. They are cleverly efficient but not very
> friendly for creating exceptional behaviors in matching elements.
>
> The jQuery serialize function boils down to "return elem.value;". I
> was hoping for something like PHP's __get magic method but I couldn't
> find anything like that in javascript or jQuery.
>
> In both 2.8 and 2.9 the core logic assumes your form elements have the
> intended values by the time you click Save. The problem is that
> TinyMCE doesn't do that for you. But if you could guarantee your form
> elements had the correct values prior to the click event you would
> have the save problem solved.
>
> I don't know whether you can trust the editor's blur event with
> TinyMCE.triggerSave() but if so, that would be an elegant solution.
>
> None of this does anything about the broader issue: you don't have
> simple control over the order of bound events, as in the queue you
> proposed, which reminds me of the core filter/action system. jQuery
> doesn't let you bind with priorities the way WordPress does. That
> would be a nice feature.
>
> There may be an audience for this sort of thing but, as you have shown
> in your solution, there are already ways around.
>
> Andy
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>