general before/after JavaScript mechanism

[fmpwizard]

"Lunching with JavaScript returns: http://groups.google.com/group/liftweb/browse_thread/thread/b3469ab5eb55c7f5/32a6b3f8f482a8b7

I think we need a general before/after JavaScript mechanism... and I have an idea of how it can be done with only 2 API calls:

SHtml.beforeAjax(jsCmd) { SHtml.afterAjax(jsCmd) { code that creates an AjaxCall } }

Those two calls will wrap the pre and post execution of the Ajax call and will work across all the Ajax call mechanisms. Further, they answer the need for an "in call" spinny control located near the item that's doing the Ajax call rather than the global spinny thing for Ajax calls."

See related thread http://groups.google.com/group/liftweb/browse_thread/thread/c0fa111d87a8beac

[github-importer]

Imported from Assembla: http://www.assembla.com/spaces/liftweb/tickets/1187

[Shadowfiend]

As we move forward I believe a better solution to this would be to encourage keeping client-side functionality on the client, rather than trying to bolt things onto the Lift side for every strange permutation of client-side JS demands. This also plays into the stricter security requirements of a strict Content-Security-Policy. So my vote is to close this. Thoughts/should we discuss on the list?

[fmpwizard]

Are you thinking of moving forward and not having things like JsCmds, etc? Maybe we can discuss it on the list. I remember having a need for something like this at least a couple of times after it was brought up on the list.

[Shadowfiend]

I definitely don't want to get rid of JsCmds—they're useful for example for AJAX responses—but I think we should heavily consider discouraging things like attaching to event handlers and emitting JS directly into the page. I still think one of Lift's best selling points is being secure by default, and allowing these on the page is kind of going against evolving security best practices. This isn't a terrible idea by any means, but I think saying “we will provide basic JS helpers and let you do more complex JS stuff yourself” is a better idea than trying to cater to all possible variants of client-side JS work in ways that are a little nasty.

Let's move this over to the list, though. I'll try and write up a post tomorrow unless you want to take it.