I have heard about both terms Injectable and Embeddable many times, but I am not getting actual meaning of it.
Please help me to understand both clearly.
Injectable means that something can be created and added to the main script while the script is running.
Embeddable means something can be added to a script or code before running it i.e before compilation or running of the script.
For better understanding lets take a website with a textbox as a context.
Now, In the textbox, suppose its very basic one. So, I can add a javascript into the textbox and when I will submit, it will run my JS script. This way, I am injecting my own script into the main page.
Now, suppose, I add an Iframe of another website to the HTML file of my website. In this way, when the website will be viewed, it contains the iframe. In this way, the Iframe is embedded to the website.
Injectable means that the object can be created and injected at run time. This is a hint to the compiler that this object will be managed outside the scope of the compilation and can be used at runtime to determine if the object was intended to be injected.
Embeddable means that the object can be serialized and stored in a column instead of as a separate table when the containing object is persisted. That also implies the lifetime of the embedded object is the same as the lifetime of the containing object.
Related
This is about an API handling the validation during saving an object. Which means that the front-end client sends a request to the API to a specific end point, then on the back-end the API creates a new object if the right conditions are meet.
Right now the regular method that we use is that the models has a ruleset for each fields and then the validation is invoked when the save function is invoked, but technically the validation is done right before the object is saved into the database.
Then during today's code review I came across a solution which I wasn't sure if it's a good practice or not. And it was about that the front-end must send a specific parameter to the API every time. This is because other APIs are using our API as well, and we needed to know if the request was sent as and API request or a browser request. If this parameter is present then we want to execute an extra validation function on a specific field.
(1)If I would have to implement it, then I would check the incoming parameter in the service handler or in the controller level, and if I got one, I would invoke the validation right away, and if it fails I would throw an error.
(2)The implementation I saw however adds an extra variable to the model, and sets the model variable when there is an incoming parameter, then validates only when the save function is invoked on the object(which first validates the ruleset defined on the object fields, then saves the object into the database)
So my problem with (2) is that the object now grown bigger with an extra variable that is only related to a specific event. So I would say it's better to implement (1). But (2) also has an advantage, and that is when you create the object on different end point by parsing the parameters, then the validation will work there as well, even if the developer forget to update the code there.
Now this may seems like a silly question because, why would I care about just 1 extra variable, but this is like a bedrock of something good or bad. So if I say this is ok, then from now on the models will start growing with extra variables that are only related to specific events, which I think should be handled on the controller/service handler level. On the other hand the code would be more reliable if it's not the developer who should remember all the 6712537 functionalities and keep them in mind when makes some changes somewhere. Let's say all the devs will get heart attack tomorrow from the excitement of an amazing discovery, and a new developer has to work on the project while he doesn't know about these small details, and then he has to change something on the code that is related to this functionality - so that new feature should be supported by this old one as well.
So my question is if is there any good practice on this, and what do you think what would be the best approach?
So I spent some time on thinking on the solution, and I think the best is to have an array of acceptable trigger variables in the model class. Then when the parameters are passed to the model on the controller level, then the loader function can be modified that it takes the trigger variables from the parameters and save it in the model's associative array variable that stores the trigger variables.
By default this array is empty, and it doesn't matter how much new variables are needed to be created, it will only contain the necessary ones when those are used.
Then of course the loader function needs to be modified in a way that it can filter out the non trigger variables as well as it is done for the regular fields, and there can be even a rule set of validation on the trigger variables if necessary.
So this solves the problem with overgrowing the object with unnecessary variables and the centralized validation part, because now the validation can be always done in the model instead of the controller.
And since the loader function is modified to store the trigger variables in the model's trigger variables array variable, the developer never has to remember that this functionality was created. Which is good, because in the future when he creates a new related function or end point that should handle object creation, he will not miss it to validate it against the old functionality, because the the loader function that he modified in the past like this will handle it for him.
It needs to be noted tho, that since the loader function doesn't differentiate between the parameters, and where to load them other then checking the names of the parameters with the filter functions, these parameter names should be identical from each other, otherwise a buggy functionality can be created accidentally. Like if you forget that a model attribute with the same name was used, then you can accidentally trigger an event that was programmed to be triggered if the trigger variable with the same name is present. However this can be solved by prefixing the trigger variables for example.
We are trying to add one additional feature to our method for TBO. The feature needs to be executed only when a new document for that object type is imported and should not be executed in any other case like checkin checkout or any changes in attributes.
However the new code is getting called everytime we make any changes to attribute to that document.
We have put that code in doSave() method.
I tried isNew method for distinguish between newly imported Document and other scenarios, however could not get success, may be missing the usage details of the method.
Can anyone suggest anything?
We are on Documentum version 7.2.
I always use isNew() method to check is object new or versioned, I don't remember having problems with it at any DFC version.
Only one thing that comes in mind is to make sure you don't use super.doSave() while inside the code since right after it method will return false.
But this is expected behaviour.
If you really need to do this - some calulations based on programatically preset data - make sure you use value saved within local variable throughout your code.
If you think you are experiencing bug with the method try with another DFC version or report a bug to the Support.
I'm trying to create a custom build of noflo-ui that is effectively only a graph editor. Don't need it to connect to any runtimes.
I'm struggling to find where I can inject this code as it appears part of noflo-ui is written in noflo itself and I cannot find the scripts for those pieces.
For example, in graphs/main.fbp, there is this line:
'user,main,project,github,runtime,context' -> ROUTES Dispatch
Three questions on this:
Where is the source behind the Dispatch component?
If I add my own interface elements to Load data from an external api, where would be the best place to inject that data?
I see a lot of event driven code, so I'm guessing I would add a new polymer element, do my ajax call, the emit or fire something. I believe this is what happens when connecting to a noflo-nodejs runtime; I've traced the connection to line 51312 in a built noflo-ui.js
return port.send({
componentDefinition: definition
});
... but I can't figure out where it goes past here. A port on the main.fbp graph? As per my 1st question, I cannot find the source behind these core graphs.
And this leads to my last question
The code I pasted above from noflo-ui, I cannot find this code anywhere pre-build. I even searched the entire project tree for "componentDefinition: definition". Where is this coming from?
Any pointers on this would be greatly appreciated! Thanks
The FBP runtime protocol is the primary extension point of noflo-ui. You can implement a "runtime" which just provides components and graphs (for instance from a database), without a way to run these.
A network:persist message to let the UI indicate that "this is a good point to save the graphs" has been specced but is currently not implemented. For now you can just autosave latest state.
Passing Data from Page to Page for Windows Phone 8.1
i found this great article :
http://www.windowsapptutorials.com/windows-phone/how-to-pass-data-between-different-pages-in-windows-phone-application/
and i understood it very well,
there are few question i came after reading this article is :
[1] which method is better, in which scenarios ?
[2] what is the benefits of all 3 methods?
Small hint: Please state if you are using Silverlight or WinRT, as it makes a big difference.
I assume you are using Silverlight here.
Like demas already stated: Global variables are almost never a good idea.
Recommendation: Always use queryString and always only pass IDs in the query.
This means, keep your data in some kind of storage and always read it from there on any page.
If you want to pass complex objects, put them to your storage, tell the new page the id and on the new page load it from the storage.
If your app gets terminated (tombstoned) in the background and is
relaunched on your detail-pages, it may always be that your global
variables are empty.
It also improves your maintainability: All data accessed by a page will be loaded on that pages code/codebehind/viewmodel; You don't have to check other parts of the app to find out where that data comes from.
Further hint:
It helped me a lot, to think of a Silverlight app like a "web app": The pages are individual pages and the viemodels are the database servers. There is no way to pass data between these pages other than the query string.
Public property in App.xaml.cs and global variables causes namespace pollution and make the application less testable, so I prefer to use QueryString.
On the other hand, sometimes I need to pass complex object or even collections of complex objects and in this case public property in App.xaml.cs is more preferable in my opinion.
I have a big issue With Webdriver (Selenium 2).
In my test code, I find all the elements in the beginning of my test, and do some actions on them (like click(), checking attributes, etc.). My problem is that my page is refreshed and re-load my elements, and Webdriver don't know to recognize the elements again.
I know that I can find my elements again, but in some functions I don't know my XPath/ids, and I get just the WebElements, not XPath/IDs.
Am I right in saying that it's no possible to read elements into variables and re-use them?
WebElement element = driver.findElement(By.id("xyz"));
The above line will store the element object in element. You can certainly pass this element to other functions to make use of it over there.
We generally follow a pattern called PageObject patterns where we create all objects of a page as members of a class and instantiate them at once. This way we can use them any where in our project. For example all objects in Login page will be created as public static variables in a class called LoginPage. The constructor of LoginPage class will find elements and store them.
Next time any where you want to access an object of LoginPage, we access them as below(asuming that you have created elements userName and submit)...
LoginPage.userName.sendKeys("buddha");
LoginPage.submit.click();
However as Robie mentioned there is a chance for this objects to become unaccessible using the previously created object after page refresh. You can use the below modified approach for ensuring these objects are always found.
Instead of creating the objects as a member variable, create a getmethod for each object that you may need to use.
class LoginPage
{
public static WebElement getUserName()
{
return driver.findElement(By.id("xyz"));
}
}
Once LoginPage is defined that way, next time you want to use userName, you use below syntax.This way you don't have to give locators to the functions that needs to use these objects.
LoginPage.getUserName().sendKeys("buddha");
By using this approach, you can ensure that the objects are always accessible.
Buddha is incorrect in the following statement:
You can reuse it any number of times, however, it only works as long as the id doesn't change.
As you have correctly observed, if the page reloads, then elements become stale, even if the original object is still displayed on screen. In fact, refreshing of HTML via AJAX calls can also make objects stale even if the URL has not changed.
This is how Selenium works, and you have to understand this when deciding how to implement a test framework.
You can store elements, reuse them and pass them to functions, but understand when they will become stale and need to be refound.
In my current project, I have a very AJAX heavy application in which objects are continually becoming stale, so have extended WebElement to find and store it's HTML Id when constructed, then refinds by id if a stale element exception occurs and re performs the method that failed. However, this was achieved using Ruby and very specific to my application as I know every object has a unique HTML Id. I do not believe this approach would work for most applications under test.
I would also question whether storing elements in public static variables populated on construction, is actually following the Page Object pattern. I have never seen it implemented this way before, and can see lots of potential pitfalls. Lazy instantiation may be a better approach when following the Page Object pattern.