signals in web2py

[Niphlod]

I feel like signals in web2py could resolve lots of issues. If coded correctly, it would save us from lots of headaches and argument-bloat in our code.

I'm experimenting with blinker (flask uses it) and seems to work fine. Needs to be adjusted as usual for web2py's execution model, but it's quite perfect to let different part of the code speak.
I'm researching this mainly because because I need something better than response.custom_commit() for the redis-based scheduler, which could be a-hell-of-a-lot-faster if there was something among the lines of blinker to let queue_task do something AFTER the commit.
Usecase scenario ? on the top of my head right now: all DAL callbacks, all Auth "on_something" actions, login gateways and corresponding actions, easy callbacks in the next version of cache (like "it expired"), after_request, error handlers, easier integration of plugins, etc

@all: opinions ?

[Leonel Câmara]

This is a good idea, hence why we're basically already doing this except we are peppering the code with callback lists, which is ugly implementation wise (the reason people make signals/pubsub libraries) but for the user the API is pretty decent.  

  

Backwards compatibility could be insured by making _after_insert/_before_delete, etc. that would instead connect to the signal so that's not a big stopper, but it would fill our codebase with cruft for all the previous places where we had callback lists (although it would also clean a lot of repeated logic calling the callbacks).

I'm not sure if we want the DAL to be blinker dependent now that we made it framework agnostic,

I think signals would be very interesting from a plugin development perspective.

My problem with signals is that when they aren't used just by the users (I would consider the scheduler a user here) to extend web2py base functionality and they're used between parts of the code in the framework itself, that makes the code very hard to read and follow in my opinion.  

 

I'm in favour as long as we agree to be very careful with this last caveat. I think it's worth considering some sort of backwards compatibility breakage if we go forward as this would imply a pretty big refactor but I don't know how to do that without alienating our users.

[刘志军]

any changes now?

web2py really need this in the framework level by exposing the api.

在 2015年4月2日星期四 UTC+8上午4:47:20，Niphlod写道：

[Massimo DiPierro]

Can we do this in Web3PY instead?

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[刘志军]

That's great! cons!

web2py is the best python web framework that simple and extensible.

But without the pub-sub api it's hard to write reusable and extensible components that running on the framework.

I can give some reference based on my knowledge:

take https://www.laravel.com/docs/5.2/events as an api interface and

could we take https://github.com/godaddy/Thespiant as the implementation follow the actor model?

sorry for my poor english.

Thank you!

Zhijun

在 2016年4月7日星期四 UTC+8上午7:02:12，Massimo Di Pierro写道：