Is it possible, or more precisely how is it possible to use RX.Net to listen to a number and different variety of (WinForms) controls' .TextChanged/.RowsChanged/.SelectionChanged events and whenever one condition is fullfilled (ControlA.Text isn't empty, ControlB.RowsCount > 0 etc) enable that one DoSomething button.
I am asking because currently we have a lengthy if/then statement in each of these events' handlers and maintaining them if the condition changes is, due to duplicate code, quite error prone and that's why, if possible, I think it would be nice to take the stream of events and put the condition in one place.
Has anyone done that?
You can use Observable.FromEventPattern in combination with Join patterns, with Observable.When, Observable.And and Observable.Then, to create observables which will fire depending on various conditions, like combinations of events. For example, consider my answer here: Reactive Extensions for .NET (Rx): Take action once all events are completed
You should be able to use .FromEventPattern() to create observables for each of those events and then use CombineLatest() to do your logic on the current overall state and determine whether your button should be enabled, in one place.
Related
Running through the full loop for a scenarios-based workflow and noticed that the scenario once applied is NOT auto-deleted. What is considered best practice to prevent users from accidentally applying a scenario twice? Is it best to delete them afterwards? If so, why is auto-delete not enabled?
you could delete but usually I would add a flag called "applied" and filter my list of displayed scenarios by "applied" == false or something like that.
If you ever want to use your scenarios for metrics. E.g. how many scenarios have been applied / maybe write some stats to the scenario object on apply this data is all lost if you're deleting on apply. I believe that's also why it's not part of the workflow by default. The idea is that you should make that decision for your use case.
I have an always one application, listening to a Kafka stream, and processing events. Events are part of a session. And I need to do calculations based off of a sessions data. I am running into a problem trying to correctly run my calculations due to the length of my sessions. 90% of my sessions are done after 5 minutes. 99% are done after 1 hour. Sessions may last more than a day, due to this being a real-time system, there is no determined end. Session are unique, and show never collide.
I am looking for a way where I can process a window multiple times, either with an initial wait period and processing any later events after that, or a pure process per event type structure. I will need to keep all previous events around(ListState), as well as previously processed values(ValueState).
I previously thought allowedLateness would allow me to do this, but it seems the lateness is only considered for when the event should have been processed, it does not extend an actual window. GlobalWindows may also work, but I am unsure if there is a way to process a window multiple times. I believe I can used an evictor with GlobalWindows to purge the Windows after a period of inactivity(although admittedly, I did not research this yet, because I was unsure of how to trigger a GlobalWindow multiple times.
Any suggestions on how to achieve what I am looking to do would be greatly appreciated, I would also be happy to clarify any points needed.
If SessionWindows won't do the job, then you can use GlobalWindows with a custom Trigger and Evictor. The Trigger interface has onElement and timer-based callbacks that can fire whenever and as often as you like. If you go down this route, then yes, you'll also need to implement an Evictor to dispose of elements when they are no longer needed.
The documentation and the source code are helpful when trying to understand how this all fits together.
In the Flux examples, the two action types I noticed are view actions & server actions. Are there any other action types to be concerned about from a large app perspective? I'm just thinking of appropriate patterns to use for the long term.
https://github.com/facebook/flux/tree/master/examples
Actions are just actions. If there's an action you use when getting the current user from the server, you could also create that action some other time (such as getting the user from local storage, etc.).
The two most common sources of events are from the UI and the server, however you could also have actions triggered on a timer (setInterval) or from a global event handler (e.g. window's resize), or third party libraries which get it from any source.
Perhaps a better word for and 'action' in flux would be an 'intent'. It doesn't actually do anything on its own, it just suggests something be done; the dispatcher dispatches the intent, and stores can do something (i.e. take action) based on the intent.
"view actions & server actions" is either too specific or too vague. You should either consider all actions equal (my personal take), or consider there to be hundreds of action types.
I'm just thinking of appropriate patterns to use for the long term.
I don't quite see how classifying actions affects patterns you use. Grouping of actions is more about which ones you want to generally expose to which other modules. For example ChatServerActionCreators is only used by utils/ChatWebAPIUtils. It's a matter of encapsulation rather than grouping by related functionality.
Thanks, I suppose I was also indirectly asking why these event sources
exist.
Also there is this discussion on google forums answered by Bill Fisher from FB:
Q: The todo-list example mentions a possible handleServerAction in
addition to handleViewAction - can someone give some color as to why
you might want to handle server actions differently from view actions?
I'm guessing a server action is triggered through polling, sockets, or
some external event, but is there a common case/example where it's
useful to check between the two types of actions? Just curious here,
as nothing obvious jumped out (i.e. marking an item as a favorite
should trigger the same codepath, regardless of where it came from).
A: As far as the server actions vs. the view actions goes, I think it's
more common to detect a view action and act differently upon it. For
example, you might want to only run a validation when the data comes
from user input, rather than on server initialization. I left that in
there just to show that you can do whatever you want with the payload,
that there can be this kind of structure providing metadata around the
Action, allowing you to group different actions together for whatever
purpose you need. You don't have to use these handleViewAction or
handleServerAction or handleServerInitializationAction (etc) methods,
but I've found it to be occasionally useful.
I have a collection of "active objects". That is, objects that need to preiodically update themselves. In turn, these objects should be used to update a WPF-based GUI.
In the past I would just have each object include it's own thread, but that only makes sense when working with a finite number of objects with well-defined life-cycles. Now I'm using objects that only exist when needed by a form so the life cycle is unpredicable. Also, I can have dozens of objects all making database and web service calls.
Under normal circumstances the update interval is 1 second, but it can take up to 30 seconds due to timeouts.
So, what design would you recommend?
You may use one dispatcher (scheduler) for all or group of active objects. Dispatcher can process high priority tasks at the first place then other ones.
You can see this article about the long-running active objects with code to find out how to do it. In additional I recommend to look at Half Sync/ Half Async pattern.
If you have questions - welcome.
I am not an expert, but I would just have the objects fire an event indicating when they've changed. The GUI can then refresh the necessary parts of itself (easy when using data binding and INotifyPropertyChanged) whenever it receives an event.
I'd probably try to generalize out some sort of data bus, if possible, and when objects are 'active' have them add themselves to a list of objects to be updated. I'd especially be tempted to use this pattern if the objects are backed by a database, as that way you can aggregate multiple queries, instead of having to do a single query per each object.
If there end up being no listeners for a specific object, no big deal, the data just goes nowhere.
The core updater code can then use a single timer (or multiple, or whatever is appropriate) to determine when to get updates. Doing this as more of a dataflow, and less of a 'state update' will probably save a lot of sanity in the end.
Assume, I have a form ...lets say WinForm... with 'n' number of controls.
I populate them with a default value during the LOAD. Then, the user gets to play with all the controls and set different values for the controls and submit the form. Here is where I find myself writing a series of "if" conditional statements handling the value of each of the controls for (but not restricted to) avoiding nulls, doing validation etc.
Though it works, is there some other more efficient way of doing this instead of disparate "ifs" ?
You may not avoid the 'ifs' entirely, but sometimes it helps to gather related bunch of controls on your Form into User Controls. Then you can move the validation and all from the Form class into individual User Controls, thus reducing clutter.
You should know that WinForms has build in facilities for both validation and data binding. Using these built-in capabilities will definitely result in code that is better structured and easier to write and maintain than hand coding data and validation operations. Beth Massi has done a series of videos that demonstrates these features, you can find them on the MSDN web site.
** Edited **
I don't have a catch-all, as this will vary from form to form, but some general advice.
By the way, I love this question because it's all about keeping your code clean, readable, and doing things as simply as possible.
Use the included validation controls when possible rather than writing if statements to validate code. (see instruction video for winforms (based on the question I'm assuming you mean .Net winforms.) here)
Always look to see if you can write a function to handle repetitive tasks. It takes a line of code to call a function, and if your function is only fivelines long, but you call it tentimes, that means you've saved yourself a lot of duplicate lines of code.
If you can write that function to be smart enough and be able to loop through your controls, so much the better.
In short, look at your code and determine to try to do the job with the least amount of code possible while making it easily readable and understandable, and without resorting to bad practices. Experiment in your spare time on non-production "test" code to refine your technique as you learn, but if you get used to thinking about clean code you get better at writing it.
Create a set of Validators to match 1-for-1 with your controls. Derive from the base Validator a ControlXValidator, which take a ControlX as its constructor, and implements isValid() in the special way that ControlX must evaluate as valid, and implements getDiagnosticMessage to display an appropriate message if the validation fails. Then at the end of your form construction code, create a list of Validators containing the Validator subclass for each control.
Then your validateForm() method can just do something like:
allvalid = True;
foreach(Validator vtor in allValidators)
{
if (!vtor.isValid())
{
StatusBar.Caption = vtor.getDiagnosticMessage();
allvalid = False;
break;
}
}
If you are validating by data-type (dates should look like dates), you could use a function that validates your data and pass the function both the user input and a "sample" of valid data. Valid samples could be stored in an array, keyed by the data-type.
And if the data is not valid, the function returns false and you have one if statement that says "if function returns false, punch the user".
Assume a decently strong language:
Create a hash (a.k.a Map) with the keys as the control identities and the values as functions. Retrieve the function and call.
restrict your control.....life in text box you can set limit of inputr chars ...etc....
not specific to any language: use Guard Clauses is usually a good way to get rid ifs. It is a excellent way to check nulls and validations.