[OPEN-ILS-DEV] prototype staff client, feedback/2

[steven]

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 <steven.chan at bc.libraries.coop>
bc libaries co-op/sitka