On Fri, Feb 24, 2017 at 9:27 AM, Mike Walch <[email protected]> wrote: > This is a great idea. How would users configure their UserObserversFactory > in fluo.properties? Would there still be observer properties in > fluo.properties or just application properties?
I am thinking there will be a new property for configuring the users ObserverFactory. I was also thinking that the new property would be mutually exclusive with the old the properties for configuring observers. At initialization, if both are seen then an exception would be thrown. I think per observer properties could be deprecated and we would only have application configuration. I think the new Factory + app properties enables the same functionality that per observer properties provided. > > On Thu, Feb 23, 2017 at 5:36 PM Keith Turner <[email protected]> wrote: > >> The current way observers are set up in Fluo requires specifying a >> class for each observers in configuration. This is cumbersome and >> prevents using lambdas and anonymous inner classes. It also makes it >> hard to follow what a Fluo Application is doing. This cumbersome way >> of setting things up propagates forward into higher level constructs >> in Fluo Recipes making them also cumbersome to use. >> >> I think it would be much simpler if the user only had to specify one >> factory class in configuration that created all observers. This >> factory would be free to pair a lambda with a column for an observer. >> Observed columns would no longer be tightly coupled with a specific >> class. I am thinking the factory would look something like the >> following. >> >> interface ObserversFactory { >> Map<ObservedColumn, Observer> getObservers(SimpleConfiguration >> applicationConfig); >> } >> >> A user would implement this interface with a class that creates all of >> their observers. >> >> class UserObserversFactory implements ObserversFactory { >> Map<ObservedColumn, Observer> getObservers(SimpleConfiguration >> appConfig) { >> //all of users observers are setup here in code, which is much >> easier to follow than current way of configuring each observer class >> individually. >> HashMap observers = ...; >> observers.put(col1, tx,row,col -> ....); //an observer that's a lambda >> ExportQueue.addObserver(observers, appConfig, "queueId", exports >> -> ....); //using a lambda to handle exports... >> } >> } >> >> The user would configure Fluo to use the above observer factory. >> >> I am thinking of trying to implement this for 1.1, but wanted to see >> if anyone had any input before I started. If it seems to work well, I >> was thinking of deprecating the current way of configuring observers. >> I would update webindex and fluo recipes in parallel to evaluate the >> changes. >>
