I´m kind of new to the reactive pattern and now I have my first bigger question.
I have done a few asychronous requests in the reactive way. But what I wan´t to do now is a "Eventlistener".
I have a Session object, at the moment I have an SessionEventListener protocol. The Session has a list of listeners and informs all of them about a successfull login and an logout. This Listeners can subscribe and unsubscribe. This thing I want to create reactive now.
How would you do that?
My Idea is to define a BehaviourSubject:
public let loginEventBehaviourSubject = BehaviorSubject(value: true)
now I can send onNext true if the session logged in, and false if it was logged out:
loginEventBehaviourSubject.onNext(true) // on login
loginEventBehaviourSubject.onNext(false) // on logout
And my "listeners" can subscribe to it.
But I would prefere to have subjects for every event:
public let loginEventBehaviourSubject = BehaviorSubject(value: )
public let logoutEventBehaviourSubject = BehaviorSubject(value: )
But then I wouldn´t need the bool. Can I make a kind of "empty" Subject, that only fire "events" without submitting really data.
And then my last question:
Why do I have to add an instance to the initializer of the Subject. Why can´t I create it like: BehaviourSubject<Bool>()?
You need to give an initial value to behavior subject because of it's API. Indeed, it defines BehaviorSubject<T>.value() method, which returns a T. And it would not make sense to call value without a proper initial value. In the presented case, I think PublishSubject is a better representation of the task at hand. You can find more documentation on the available kinds of subjects on the reactivex website.
If you are only interested in the .next event of your subjects, you can do let loginSubject = PublishSubject<Void>() (using behavior subject, you could have written BehaviorSubject<Void>(value: ())) and will the be able to call loginSubject.onNext().
Note though that using any subject is often an anti-pattern. Indeed, subject are most of the time intended to bridge from the imperative to the reactive world and you can very often create things like loginEventObservable as a combination of other observables. For more information on this, I recommend reading To Use Subject Or Not To Use Subject?. It is written using the .Net implementation of Rx, but the theory stays the same.
Related
I currently have an action that creates a new link between an object of type A, named OA, and an object of type B, named OB.
Our workflow has a constraint such that any object of type B can at most, be linked to 4 objects of type A. As such, I would like to define a submission criterion in the action such that submission is blocked if OB is already linked to 4 objects of type A.
I couldn't find a straightforward way to do this using the Action configuration UI. How could I accomplish this?
The easiest way to accomplish this would be to turn your action into a function backed action. This would allow you to take the following steps to accomplish the desired functionality:
You can search around to all objects of type A that are linked to OB by writing something like:
// Search around to all objects of type A that are linked to OB
const linkedObjects = OB.objectTypeA.all();
// Now get the number of linked objects
const numLinkedObjects = linkedObjects.length;
Prevent the function from running by throwing a UserFacingError if there are more than 4 linked objects
if (numLinkedObjects >= 4) {
throw new UserFacingError("Objects of type B cannot be linked to more than 4
objects of type A");
}
For reference, here are some relevant pages in Foundry’s documentation:
Creating Function Backed Actions (https://www.palantir.com/docs/foundry/action-types/function-actions-getting-started/#getting-started)
Accessing link types in Functions (https://www.palantir.com/docs/foundry/functions/api-objects-links/#link-types)
Throwing UserFacingErrors from Functions (https://www.palantir.com/docs/foundry/functions/user-facing-error/)
While you can certainly do this in a Function-backed action, the tradeoff is that you won't get up front validation of the criteria, but rather the user will submit the action and then will received a toast showing the UserFacingError text. So while this technically achieves the validation, it is a sub-par user experience compared to disabling the button with a message or otherwise catching the condition upstream of the action itself in the workflow.
An alternative, iff you're using the action exclusively through Workshop, (this won't work if you want the action to "stand alone" in object explorer), you can create an object set variable that holds the result of the search around and pass that in as a hidden parameter to the Action. You can then set up the Action submission criteria as normal to check the length of that parameter and provide a message back to the user. You can also use that information in the app itself to, for example, conditionally show or hide some other workflow for the condition.
If you take this approach, make sure to add the hubble-oe:hide-action typeclass to one of the object parameters in the Action Form configuration so that the Action doesn't show up where users could use it through Object Explorer.
I'm currently building a HATEOAS/HAL based REST application with Spring MVC and JPA (Hibernate). Basically the application gives access to a database and allows data retrieval/creation/manipulation.
So far I've already got a lot of things done including a working controller for one of the resources, let's call it x.
But I don't want to give the API user the opportunity to create just an x resource, because this alone would be useless and could be deleted right away. He/she also has to define a new y and a z resource to make things work. So: Allowing to create all those resources independently would not break anything but maybe produce dead data like a z resource floating around without any connection, completely invisible und useless to the user.
Example: I don't want the user to create a new customer without directly attaching a business contract to the customer. (Two different resources: /customers and /contracts).
I did not really find any answers or best practice on the web, except for some sort of bulk POSTing, but only to one resource, where you would POST a ton of customers at once.
Now the following options come to my mind:
Let the user create the resources as he/she wants. If there are customers created and never connected to a contract - I don't care. The logic here would be: Allow the user to create /customers (and return some sort of id, of course). Then if he/she wants to POST a new /contract later I would check if the customer's id given exists and if it does: create the contract.
Expect the user, when POSTing to /customers, to also include contract data.
Option 1 would be the easiest way (and maybe more true to REST?).
Option 2 is a bit more complicated, since the user does not send single resources any more.
Currently, the controller method for adding a customer starts like that:
#RequestMapping(value = "", method = RequestMethod.POST)
public HttpEntity<Customers> addCustomer(#RequestBody Customers customer) {
//stuff...
}
This way the JSON in the RequestBody would directly fit in my customers class and I can continue working with it. Now with two (or more) expected resources included in the RequestBody this cannot be done the same way any more. Any ideas on how to handle that in a nice way?
I could create some sort of wrapper class (like CustomersContracts), that consists of customers and contract data and has the sole purpose of storing this kind of data in it. But this seems ugly.
I could also take the raw JSON in the RequestBody, parse it and then manually create a customer and a contract object from it, save the customer, get its id and attach it to the contract.
Any thoughts?
Coming back to here after a couple of months. I finally decided to create some kind of wrapper resource (these are example class names):
public class DataImport extends ResourceSupport implements Serializable {
/* The classes referenced here are #Entitys */
private Import1 import1;
private Import2 import2;
private List<Import3> import3;
private List<Import4> import4;
}
So the API user always has to send an Import1 and Import2 JSON object and an Import3 and Import4 JSON array (can also be empty).
In my controller class I do the following:
#RequestMapping(*snip*)
public ResponseEntity<?> add(#RequestBody DataImport dataImport) {
Import1 import1 = dataImport.getImport1();
Import2 import2 = dataImport.getImport2();
List<Import3> import3 = dataImport.getImport3();
List<Import4> import4 = dataImport.getImport4();
// continue...
}
I still don't know if it's the best way to do this, but it qorks quite well.
I've been reading a Concepts of Programming Languages by Robert W. Sebesta and in chapter 9 there is a brief section on passing a SubProgram to a function as a parameter. The section on this is extremely brief, about 1.5 pages, and the only explanation to its application is:
When a subprogram must sample some mathematical function. Such as a Subprogram that does numerical integration by estimating the area under a graph of a function by sampling the function at a number of different points. Such a Subprogram should be usable everywhere.
This is completely off from anything I have ever learned. If I were to approach this problem in my own way I would create a function object and create a function that accomplishes the above and accepts function objects.
I have no clue why this is a design issue for languages because I have no idea where I would ever use this. A quick search hasn't made this any clearer for me.
Apparently you can accomplish this in C and C++ by utilizing pointers. Languages that allow nested Subprograms such as JavaScript allow you do do this in 3 separate ways:
function sub1() {
var x;
function sub2() {
alert( x ); //Creates a dialog box with the value of x
};
function sub3() {
var x;
x = 3;
sub4( sub2 ); //*shallow binding* the environment of the
//call statement that enacts the passed
//subprogram
};
function sub4( subx ) {
var x;
x = 4;
subx();
};
x=1;
sub3();
};
I'd appreciate any insight offered.
Being able to pass "methods" is very useful for a variety of reasons. Among them:
Code which is performing a complicated operation might wish to provide a means of either notifying a user of its progress or allowing the user to cancel it. Having the code for the complicated operation has to do those actions itself will both add complexity to it and also cause ugliness if it's invoked from code which uses a different style of progress bar or "Cancel" button. By contrast, having the caller supply an UpdateStatusAndCheckCancel() method means that the caller can supply a method which will update whatever style of progress bar and cancellation method the caller wants to use.
Being able to store methods within a table can greatly simplify code that needs to export objects to a file and later import them again. Rather than needing to have code say
if (ObjectType == "Square")
AddObject(new Square(ObjectParams));
else if (ObjectType == "Circle")
AddObject(new Circle(ObjectParams));`
etc. for every kind of object
code can say something like
if (ObjectCreators.TryGetValue(ObjectType, out factory))
AddObject(factory(ObjectParams));
to handle all kinds of object whose creation methods have been added to ObjectCreators.
Sometimes it's desirable to be able to handle events that may occur at some unknown time in the future; the author of code which knows when those events occur might have no clue about what things are supposed to happen then. Allowing the person who wants the action to happen to give a method to the code which will know when it happens allows for that code to perform the action at the right time without having to know what it should do.
The first situation represents a special case of callback where the function which is given the method is expected to only use it before it returns. The second situation is an example of what's sometimes referred to as a "factory pattern" or "dependency injection" [though those terms are useful in some broader contexts as well]. The third case is commonly handled using constructs which frameworks refer to as events, or else with an "observer" pattern [the observer asks the observable object to notify it when something happens].
I need to use MTD with Json to dinamycally create forms, but also i need to check the user input:
Some fields may only accept numbers, and some other have a fixed length etc.
This can be done with an action that checks every EntryElement value against the specified conditions, and then using some messaging to tell the user about the necessary corrections.
If we have a low number of fields this is Ok, but when one has more than 50 fields then this turn out to be very awkward in terms of usability. The ideal solution would be to notify the user about corrections, in the moment the user ends typing in the EntryElement
Now MTD provides some sort of mechanism to do this:
JsonElement jsonElement;
jsonElement = JsonObject.Load("file.json");
((EntryElement) jsonElement["field_1"]).EntryEnded = delegate { doSomething();};
Provided that "field_1" is an EntryElement marked with the id attribute with "field_1" value
The above code works as expected, ie: When i change the focus to another part, the EntryEnded event activates. Now for the million dollar question:
How do i know to which EntryElement does the Event correspond? or in other words. How do i get the ID of the EntryElement when calling the Event?
If none of the above is possible which would be suitable solution?
Thanks in advance for any leads,
Found a way to do it:
((EntryElement)jsonElement ["field_1"]).EntryEnded += (object sender, EventArgs e ) =>
{
NSIndexPath pt = ((EntryElement)sender).IndexPath;
Console.WriteLine("section: "+pt.Section+" row: "+pt.Row);
};
This little thing will print the Section and the Row of the EntryElement that received
the EntryEnded event. This is not exactly as getting the id, but at least now i have information about its location, and from this i can get a lot more info (specially if i took care to save it somewhere else)
This is probably a basic trick, but i didn`t found it anywhere else!
let's consider a small method:
int MyFunction(string foo, int bar)
{
...
}
and some calls:
MyFunction("",0)
int x = MyFunction(foo1,bar1)
How would you explain this to a non-technical persons? Has anybody a nice metaphor?
I tried to explain method calling (or function application) several times, but I failed. Seems I can't find the right words here.
Regards,
forki
UPDATE: It is important for me to explain how the parameters are passed / matched.
(Highly non-technical solution)
It's like making an order:
Calling the method = dialing the right number
Passing the arguments = giving your details
the method does is job
Getting a return value = getting what you ordered
You could tell function is a process available into an object that could be called by other. Lets say "You" is an object with function "Work". Your "Boss" is the caller object. Your Boss then can call you to Work with different type (which is parameter).
In the end Your "Boss" can ask "You" to Work("encode this") or Work("check email") or Work("finish deadline"), etc.
How about delegating a task? Imagine you’re baking a cake and ran out of flour. Instead of buying some yourself you could just send your kid with instructions to buy flour. Input: money, output: flour.
It's difficult to understand the "method call" concept if you don't understand first the
flow of control.
A simple explanation is that methods, or routines, is a construct for packeting instructions
in order to reuse them and make the code more readable.
Calling a method, temporarily, switches the execution flow to that method.
C:: do(a ,b)
You are telling C to do something , given the condition a and b.
The best approach is probably to come up with a domain specific example which the person you are explaining to can relate to. If she is working with the post office, you should describe the function "send letter with this text to this recipient", where recipient is a parameter (containing the address) and message is the parameter for the textual content.
Parameter order is not important as long as you have a name for each parameter. Trying to explain why order is important in some arcane programming language is fruitless.
How about
Calling a function: Ask the software to perform xxx task
Returning value type function: Ask your software to perform xxx task and tell you the outcome of the operation
Calling a function with param: Given X is this value and Y is thisvalue, ask your software to perform xxx task (and tell you the outcome of the operation)
Think of the system as a teller at a desk. To call a function you fill in a form to ask the system to do something, hand it to the teller. They go off and do the work, then hand you back a piece of paper with the result written on it. Depending on what you want the system to do, you pick an appropriate form.
The form for MyMethod says:
MYMETHOD REQUISITION FORM:
String _______
int _______
This analogy can be extended in all kinds of ways. Wouldn't it be handy if the form told you what the purpose of the String and int were? That's where languages with named parameters come in.
For OO, instead of having one desk for the whole system, each object is its own teller, you hand a form to them, and in order to get the job done, they hand a lot more forms back and forth between each other. Etc.