On Sat, 25 Jan 2014, Mike Rylander wrote:
Overall I like the suggestion, but I wonder if we shouldn't just subclass a generic event publisher with a "confirm" and "alert" classes. They would inherit a channel to publish to, and supply the flags required to cause the confirm/yes/no behavior appropriate for the class. That would make the code more explicit at the call sites, would keep us from using magical or idiomatic parameters, and allow us to change/improve one or the other or both as needed down the road.
I agree that my suggested calling convention is slightly magical in that it behaves differently according to exactly what is passed in. I envision that a designer will experiment between wanting a progress, an alert, or a confirmation, and so messing with the inputs rather than renaming the function name is 'easier'. I think the main point is that a notification is being requested; whether it's of a particular kind is secondary, and so having a fixed name for the function serves that purpose. Minor point. I think the biggie for me is to have the loose coupling based on publishing to an event stream. In angularjs terminology, egNotify would probably be a controller, not a service. It should probably be 'activated' as soon as possible and would live for the duration of the client session.
I'm not certain if there's something shaped just like what we want, but I bet there's something similar. Dojo has a "toaster" UI component that can require confirmation or just fade away, and I bet Angular has something like that.
Yeah, a toaster widget is nice. In the jQuery plugin world, there are several implementations as well. -- steven <[email protected]> bc libaries co-op/sitka
