API Provide a thin alternative to loadPanel/submitForm.

[mateusz]

This is needed in some situations when we only want to update a
small single component, sometimes even using a different controller to
the one implied in the URL.

An example here is reloading dynamically the subsite dropdown without
reloading the entire page, updating a filter sidebar or suchlike.

[adrexia]

👍

[chillu]

Really well coded and documented, as usual - thanks Mateusz :)

[stojg]

[MarcusDalgren]

Sorry for being late to the party here but is there a reason for not returning the xhr from the loadFragment() function?
You're kindof gimping the $.ajax functionality by not allowing the calling function to add .then() or .success() directly on the loadFragment() being made for doing some custom stuff.

[chillu]

Yeah we should uses promises more, Mateusz can you send fix+commit that? No need for a PR

[mateusz]

There is no reason, apart from my own ignorance! Thanks @MarcusDalgren
137aa53

Now that I look at it, does it actually make sense to keep the loadfragmenterror trigger at all? I'm on a fence here: one the one hand this makes the code more cluttered, on the other it allows to write Entwine handlers which make a good job of preventing memory leaks.

[MarcusDalgren]

I'm not an Entwine buff so I'm not sure in what contexts loadFragment() gets used.
When I made the comment I was thinking of the use case that the loadFragment() call comes from another Entwine element and you want to do stuff with the data when its returned or something. The most "natural" place for that code in some cases would be in the same context that made the loadFragment() call.

However you might want to setup some kind of generic handlers on the Entwine element which gets hit by the loadFragment() and in that case you use afterloadfragment and/or loadfragmenterror depending on your needs. The Entwine afterloadfragment/loadfragmenterror events will capture all loadFragment() calls made on that element while binding directly to the returned promise only affects that specific loadFragment() call.

At least that's my understanding of it.

[MarcusDalgren]

What I'm trying to say is I'd keep both options just the way it is now.

[mateusz]

Agreed then, leaving both in :-)