An MVC Controller is a JAX-RS resource method annotated with @Controller. If a class is annotated with @Controller, then all resource methods of this class are regarded as controllers.
Here's a fun little experiment showing the power of Swift's Protocol Extensions to apply a CIGaussianBlur Core Image filter to any UIView with no developer overhead. The code could be extended to apply any Core Image filter such as a half tone screen or colour adjustment. Blurable is a simple protocol that borrows some of the methods and variables from a UIView: var layer: CALayer { get } var subviews: [UIView] { get } var frame: CGRect { get } func addSubview(view: UIView) func bringSubviewToFront(view: UIView) ...and adds a few of its own: Obviously, just being a protocol, it doesn't do much on its own. However, by adding an extension, I can introduce default functionality. Furthermore, by extending UIView to implement Blurable, every component from a segmented control to a horizontal slider can be blurred: extension UIView: Blurable { } The Mechanics of Blurable Getting a blurred representation of a UIView is pretty simple: I need to begin an image context, use the view's layer's renderInContext method to render into the context and then get a UIImage from the context: UIGraphicsBeginImageContextWithOptions(CGSize(width: frame.width, height: frame.height), false, 1) layer.renderInContext(UIGraphicsGetCurrentContext()!) let image = UIGraphicsGetImageFromCurrentImageContext() UIGraphicsEndImageContext(); Once I have the image populated, it's a fairly standard workflow to apply a Gaussian blur to it: guard let blur = CIFilter(name: "CIGaussianBlur") else { return } blur.setValue(CIImage(image: image), forKey: kCIInputImageKey) blur.setValue(blurRadius, forKey: kCIInputRadiusKey) let ciContext = CIContext(options: nil) let result = blur.valueForKey(kCIOutputImageKey) as! CIImage! let boundingRect = CGRect(x: -blurRadius * 4, y: -blurRadius * 4, width: frame.width + (blurRadius * 8), height: frame.height + (blurRadius * 8)) let cgImage = ciContext.createCGImage(result, fromRect: boundingRect) let filteredImage = UIImage(CGImage: cgImage) A blurred image will be larger than its input image, so I need to be explicit about the size I require in createCGImage. The next step is to add a UIImageView to my view and hide all the other views. I've subclassed UIImageView to BlurOverlay so that when it comes to removing it, I can be sure I'm not removing an existing UIImageView: let blurOverlay = BlurOverlay() blurOverlay.frame = boundingRect blurOverlay.image = filteredImage subviews.forEach{ $0.hidden = true } addSubview(blurOverlay) When it comes to de-blurring, I want to ensure the last subview is one of my BlurOverlay remove it and unhide the existing views: func unBlur() { if let blurOverlay = subviews.last as? BlurOverlay { blurOverlay.removeFromSuperview() subviews.forEach{ $0.hidden = false } } } Finally, to see if a UIView is currently blurred, I just need to see if its last subview is a BlurOverlay: var isBlurred: Bool { return subviews.last is BlurOverlay } Blurring a UIView To blur and de-blur, just invoke blur() and unBlur() on an UIView: segmentedControl.unBlur() segmentedControl.blur(blurRadius: 2) Source Code As always, the source code for this project is available at my GitHub repository here. Enjoy!
I am going to explain how to use Spring Security in a Spring MVC Application to authenticate and authorize users against user details stored in a MySQL Database.
Apache Struts 2 and SpringMVC, these two are the most popular and much talked about Java web frameworks today. Many of you might have worked with both of these frameworks, but which is one is better to use? What are the basic differences between both of these frameworks? Well, Apache Struts 2 is an elegant and extensible framework that is used for creating enterprise-level Java web applications. It is designed to streamline the development cycle, starting from building to deployment and maintenance of the application. In Struts, the object that is taking care of a request and routes it for further processing is known as “Action”. On the other hand, Spring MVC is a part of a huge Spring framework stack containing other Spring modules. This means that it doesn’t allow developers to run it without Spring, but the developers can run the Spring Core without Spring MVC. The Spring MVC (Model View Controller) is designed around a DispatcherServlet, which dispatches the requests to handler with configurable handler mappings, view resolution and theme resolution. While the objects responsible for handling requests and routing for processing in Struts called an Action, the same object is referred as Controller in Spring Web MVC framework. This is one of the very first differences between Spring MVC and Struts2. Struts 2 Actions are initiated every time when a request is made, whereas in Spring MVC the Controllers are created only once, stored in memory and shared among all the requests. So, Spring Web MVC framework is far efficient to handle the requests than Struts 2. If we talk about the features, Struts 2 and Spring MVC framework caters different level of business requirements. Let’s take a look at features offered by both of these frameworks. Struts 2 features Configurable MVC components, which are stored in struts.xml file. If you want to change anything, you can easily do it in the xml file. POJO based actions. Struts 2 action class is Plain Old Java Object, which prevents developers to implement any interface or inherit any class. Support for Ajax, which is used to make asynchronous request. It only sends needed field data rather than providing unnecessary information, which at the end improves the performance. Support for integration with Hibernate, Spring, Tiles and so on. Whether you want to use JSP, freemarker, velocity or anything else, you can use different kinds of result types in Struts 2. You can also leverage from various tags like UI tags, Data tags, control tags and more. Brings ample support for theme and template. Struts 2 supports three different kinds of themes including xhtml, simple and css_xhtml. On the other hand, Spring MVC framework brings totally different set of features. Spring MVC features Neat and clear separation of roles. Whether it is controller, command object, form object or anything else, it can be easily fulfilled with the help of a specialized object. Leverage from the adaptability, non-intrusiveness and flexibility with the help of controller method signature. Now use existing business objects as command or form object rather than duplicating them to extend the specific framework base class. Customizable binding and validation will enable manual parsing and conversion to business objects rather than using conventional string. Flexible mode transfer enables easy integration with the latest technology. Customizable locale and theme resolution, support for JSPs with or without Spring tag library for JSTL and so on. Leverage from the simple, but powerful JSP tag library known as Spring tag library. It provides support for various features like data binding and themes. Of course, Struts is one of the most powerful Java application frameworks that can be used in a variety of Java applications. It brings a gamut of services that includes enterprise level services to the POJO. On the other hand, Spring utilizes the dependency injection to achieve the simplification and enhance the testability. Both of these frameworks have their own set of pros and cons associated with it. Struts framework brings a whole host of benefits including: Simplified design Ease of using plug-in Simplified ActionForm & annotations Far better tag features OGNL integration AJAX Support Multiple view options and more However, the only drawback with Struts 2 framework is that it has compatibility issues and poor documentation. On the other hand, Spring MVC provides benefits like: Clear separation between controllers, JavaBeans models and views that is not possible in Struts. Spring MVC is more flexible as compared to the Struts. Spring can be used with different platforms like Velocity, XLST or various other view technologies. There is nothing like ActionForm in Spring, but binds directly to the domain objects. Code is also more testable as compared to the Struts. It is a complete J2EE framework comprising of seven independent layers, which simplifies integration with other frameworks. It doesn’t provide a framework for implementing the business domain and logic, which helps developers create a controller and a view for the application. However, like any other technologies or platforms, Spring MVC too suffers from several criticisms related to the complexity of the Spring framework. Final Verdict Either framework is a great choice. However, if you’re looking for the stable framework, Struts 2 is the right choice for you. On the other hand, if you’re looking for something robust, SpringMVC is perfect. Ensure that you review your exact requirements before choosing the framework!
In the series of step by step lessons of SSIS (SQL Server Integration Services), this is part six in which we are going to learn a new control: Data Conversion.
At Wix engineering, we’ve found that in most cases we don’t need a NoSQL database, and that MySQL is a great NoSQL database if it’s used appropriately.
Selenium WebDriver is widely used as a first-choice framework when it comes to testing web applications. In this article I would like to introduce you to two design patterns, that work great with selenium tests. In this post we will dig into Page Object pattern and combine it with Page Factory. As always, whole code for project is available on my github. Page Object Pattern Page Object is a concept that helps to reduce the number of duplicated code, and helps with test maintenance, resulting from changes in the structure and functionality of the web application. The main idea behind page object is to place the code relating to the functionality of subpages in separate classes. In a very simplified way, if your web application includes pages: home about contact We should create three separate page object classes: Home.java About.java Contact.java Each class should contain only those methods that support functionality for the corresponding subpage, and define selectors only for this subpage. We should also remember, that public methods in page object class are only those, that represents user’s workflow. One important point is that each public method in page object class should return object of page that user is on. For example, if a button on the page does not gets you to different subpage, this method should return this. Moreover, if a button is a link to another page, the method should return page object class of this subpage. Here is a code snippet of this approach using an example from previous article, where we wrote tests for Facebook login: public class LoginPage { private static By userEmailLoginInput = By.id("email"); private static By userPasswordLoginInput = By.id("pass"); private static By loginSubmitBtn = By.id("u_0_n"); private WebDriver driver; public LoginPage(WebDriver driver) { this.driver = driver; driver.get("http://facebook.com"); } public LoginPage enterUserLogin(String login) { WebElement emailBox = driver.findElement(userEmailLoginInput); emailBox.click(); emailBox.sendKeys(login); return this; } public LoginPage enterUserPassword(String password) { WebElement passwordBox = driver.findElement(userPasswordLoginInput); passwordBox.click(); passwordBox.sendKeys(password); return this; } public HomePage submitLoginCredentials() { WebElement submitBtn = driver.findElement(loginSubmitBtn); submitBtn.click(); return new HomePage(driver); } } In above example, methods enterUserLogin() and enterUserPassword() don’t transfer user to another subpage, but perform activities on the login page, so return type is object of LoginPage class (this). On the other hand, submitLoginCredentials() method moves user to home page (or to the page informing about the login failure), so it returns home page class object. In real life example, in HomePage.class we would have had methods that perform actions on the home page, but since it’s only an example code demonstrating pattern usage, we have only checkIfLoginSucceed() method here: public class HomePage { private WebDriver driver; public HomePage(WebDriver driver) { this.driver = driver; } public boolean checkIfLoginSucceed() { return driver.getPageSource().contains("fbxWelcomeBoxName"); } } …and test looks as follows: @Test public void shouldNotLoginWithIncorrectCreds() { LoginPage loginPage = new LoginPage(driver); loginPage.enterUserLogin("wrong@login.com"); loginPage.enterUserPassword("wrongPassword"); HomePage homePage = loginPage.submitLoginCredentials(); assert (!homePage.checkIfLoginSucceed()); } Page Factory pattern The main idea behind this pattern is to support page object classes, and to allow better page selectors management. Page Factory provide us with a set of annotations, which work great with selectors and enhance code readability. To understand this, let’s look at a standard initialization webelement through the selector: private static By email = By.id(“email”); WebElement emailBox = driver.findElement(email); Unfortunately, the readability leaves much to be desired. The problem is also that variable with selector and web element object require a separate initialization. Along with Page Factory, this is greatly simplified: private WebElement email; That’s all! Page Factory search page source code for element with id=”email” by default and assigns it to declared webelement. Of course, this minimalism can introduce some confusion, and therefore I recommend the use of @FindBy annotation: @FindBy(id = “email”) private WebElement userEmailLoginInput; We can also search selectors by other attributes, such as xpath, name, className, etc. Everything we have to do to use this pattern, is to initialize PageFactory in the page object class constructor: PageFactory.initElements(driver, this); Our LoginPage.class with page factory pattern will look like this: public class LoginPage { @FindBy(id = "email") private WebElement userEmailLoginInput; @FindBy(id = "pass") private WebElement userPasswordLoginInput; @FindBy(id = "u_0_n") private WebElement loginSubmitBtn; private WebDriver driver; public LoginPage(WebDriver driver) { this.driver = driver; driver.get("http://facebook.com"); PageFactory.initElements(driver, this); } public LoginPage enterUserLogin(String login) { userEmailLoginInput.click(); userEmailLoginInput.sendKeys(login); return this; } public LoginPage enterUserPassword(String password) { userPasswordLoginInput.click(); userPasswordLoginInput.sendKeys(password); return this; } public HomePage submitLoginCredentials() { loginSubmitBtn.click(); return new HomePage(driver); } } Important thing to notice is that every time we call a method on web element, page factory search for our element all over again through page sources. If page isn’t AJAX-based, we can use page factory cache to search an element only with page factory initialization, and then retrieve it from cache: @FindBy(id = “email”) @CacheLookup private WebElement userEmailLoginInput; Summary As in every aspect of software development, design patterns in test automations help us to develop tests faster and more efficient. Page Object and Page Factory are two simple patterns, that significantly improve maintenance and readability of selenium tests. For complete sources of examples in this article please visit my github. If you have any questions, feel free to leave a comment!
CORE
