kyle burns - Developer IT

JSF 2.2 Update from Ed Burns

- by arungupta

In a recent interview the JavaServer Faces specification lead, Ed Burns, gave an update on JSF 2.2. This is a required component of the Java EE 7 platform. The work is expected to wrap up by CY 2012 and the schedule is publicly available. The interview provide an update on how Tenant Scope from CDI and multi-templating will be included. It also provide details on which HTML 5 content categories will be addressed. The EG discussions are mirrored at jsr344-experts@javaserverfaces-spec-public. You can also participate in the discussion by posting a message to users@javaserverfaces-spec-public. All the mailing lists are open for subscription anyway and JIRA for spec provide more details about features targeted for the upcoming release. A blog at J-Development provide complete details about the new features coming in this version. And an Early Draft of the specification is available for some time now.

Read the article

Ed Burns' Servlet 4/HTTP 2 Session at JavaOne 2014

- by reza_rahman

For the Java EE track at JavaOne 2014 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference. To this end we recently interviewed Ed Burns. Ed is a veteran of Sun and now Oracle. He has been and is instrumental in pushing the JSF ecosystem forward as specification lead. Besides his specification lead work Ed is well regarded as an author and speaker on his own right. In addition to carrying the JSF torch Ed will be co-leading the key Servlet 4 specification for Java EE 8, along with Servlet specification guru Shing Wai Chan. The primary goal of Servlet 4 is to enable the fundamentally important changes in HTTP 2 for the entire server-side Java ecosystem. We wanted to talk to Ed about his Servlet 4 session at JavaOne 2014 and HTTP 2 generally: The details for the Servlet 4 session can be found here. Ed has several other key sessions on the track that we hope to talk to him about separately in the near future: What’s Next for JSF?: In this key session, Ed will be sharing the next steps for the continued evolution of the JSF specification in Java EE 8. Where’s My UI? The 2014 JavaOne Web App UI Smackdown: The UI space for web applications, especially in the Java ecosystem continues to be as hotly contested as ever. This is especially true with the (re)introduction of JavaScript based rich client frameworks like AngularJS. This lively panel brings together experts representing the diverse schools of thought for web UIs. Ed will be representing JSF of course. Neal Ford will moderate the panel as an independent and hopefully reasonably neutral party. Adopt-a-JSR for Java EE 7 and Java EE 8: Adopt-a-JSR has been a reasonable success for Java EE 7. With Java EE 8 we are planning to strengthen it far more as away of getting grassroots level participation in the specification efforts. This session will introduce Adopt-a-JSR, share how it worked for Java EE 7 and what we plan to do with it in Java EE 8. Ed will be sharing his perspectives on Adopt-a-JSR for both Java EE 7 and Java EE 8. Besides Ed's sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

Read the article

Ed Burns' Servlet 4/HTTP 2 Session at JavaOne

- by Yolande Poirier

Read the article

When is my View too smart?

- by Kyle Burns

In this posting, I will discuss the motivation behind keeping View code as thin as possible when using patterns such as MVC, MVVM, and MVP. Once the motivation is identified, I will examine some ways to determine whether a View contains logic that belongs in another part of the application. While the concepts that I will discuss are applicable to most any pattern which favors a thin View, any concrete examples that I present will center on ASP.NET MVC. Design patterns that include a Model, a View, and other components such as a Controller, ViewModel, or Presenter are not new to application development. These patterns have, in fact, been around since the early days of building applications with graphical interfaces. The reason that these patterns emerged is simple – the code running closest to the user tends to be littered with logic and library calls that center around implementation details of showing and manipulating user interface widgets and when this type of code is interspersed with application domain logic it becomes difficult to understand and much more difficult to adequately test. By removing domain logic from the View, we ensure that the View has a single responsibility of drawing the screen which, in turn, makes our application easier to understand and maintain. I was recently asked to take a look at an ASP.NET MVC View because the developer reviewing it thought that it possibly had too much going on in the view. I looked at the .CSHTML file and the first thing that occurred to me was that it began with 40 lines of code declaring member variables and performing the necessary calculations to populate these variables, which were later either output directly to the page or used to control some conditional rendering action (such as adding a class name to an HTML element or not rendering another element at all). This exhibited both of what I consider the primary heuristics (or code smells) indicating that the View is too smart: Member variables – in general, variables in View code are an indication that the Model to which the View is being bound is not sufficient for the needs of the View and that the View has had to augment that Model. Notable exceptions to this guideline include variables used to hold information specifically related to rendering (such as a dynamically determined CSS class name or the depth within a recursive structure for indentation purposes) and variables which are used to facilitate looping through collections while binding. Arithmetic – as with member variables, the presence of arithmetic operators within View code are an indication that the Model servicing the View is insufficient for its needs. For example, if the Model represents a line item in a sales order, it might seem perfectly natural to “normalize” the Model by storing the quantity and unit price in the Model and multiply these within the View to show the line total. While this does seem natural, it introduces a business rule to the View code and makes it impossible to test that the rounding of the result meets the requirement of the business without executing the View. Within View code, arithmetic should only be used for activities such as incrementing loop counters and calculating element widths. In addition to the two characteristics of a “Smart View” that I’ve discussed already, this View also exhibited another heuristic that commonly indicates to me the need to refactor a View and make it a bit less smart. That characteristic is the existence of Boolean logic that either does not work directly with properties of the Model or works with too many properties of the Model. Consider the following code and consider how logic that does not work directly with properties of the Model is just another form of the “member variable” heuristic covered earlier: @if(DateTime.Now.Hour < 12) { <div>Good Morning!</div> } else { <div>Greetings</div> } This code performs business logic to determine whether it is morning. A possible refactoring would be to add an IsMorning property to the Model, but in this particular case there is enough similarity between the branches that the entire branching structure could be collapsed by adding a Greeting property to the Model and using it similarly to the following: <div>@Model.Greeting</div> Now let’s look at some complex logic around multiple Model properties: @if (ModelPageNumber + Model.NumbersToDisplay == Model.PageCount || (Model.PageCount != Model.CurrentPage && !Model.DisplayValues.Contains(Model.PageCount))) { <div>There's more to see!</div> } In this scenario, not only is the View code difficult to read (you shouldn’t have to play “human compiler” to determine the purpose of the code), but it also complex enough to be at risk for logical errors that cannot be detected without executing the View. Conditional logic that requires more than a single logical operator should be looked at more closely to determine whether the condition should be evaluated elsewhere and exposed as a single property of the Model. Moving the logic above outside of the View and exposing a new Model property would simplify the View code to: @if(Model.HasMoreToSee) { <div>There’s more to see!</div> } In this posting I have briefly discussed some of the more prominent heuristics that indicate a need to push code from the View into other pieces of the application. You should now be able to recognize these symptoms when building or maintaining Views (or the Models that support them) in your applications.

Read the article

Why do we (really) program to interfaces?

- by Kyle Burns

One of the earliest lessons I was taught in Enterprise development was "always program against an interface". This was back in the VB6 days and I quickly learned that no code would be allowed to move to the QA server unless my business objects and data access objects each are defined as an interface and have a matching implementation class. Why? "It's more reusable" was one answer. "It doesn't tie you to a specific implementation" a slightly more knowing answer. And let's not forget the discussion ending "it's a standard". The problem with these responses was that senior people didn't really understand the reason we were doing the things we were doing and because of that, we were entirely unable to realize the intent behind the practice - we simply used interfaces and had a bunch of extra code to maintain to show for it. It wasn't until a few years later that I finally heard the term "Inversion of Control". Simply put, "Inversion of Control" takes the creation of objects that used to be within the control (and therefore a responsibility of) of your component and moves it to some outside force. For example, consider the following code which follows the old "always program against an interface" rule in the manner of many corporate development shops: 1: ICatalog catalog = new Catalog(); 2: Category[] categories = catalog.GetCategories(); In this example, I met the requirement of the rule by declaring the variable as ICatalog, but I didn't hit "it doesn't tie you to a specific implementation" because I explicitly created an instance of the concrete Catalog object. If I want to test the functionality of the code I just wrote I have to have an environment in which Catalog can be created along with any of the resources upon which it depends (e.g. configuration files, database connections, etc) in order to test my functionality. That's a lot of setup work and one of the things that I think ultimately discourages real buy-in of unit testing in many development shops. So how do I test my code without needing Catalog to work? A very primitive approach I've seen is to change the line the instantiates catalog to read: 1: ICatalog catalog = new FakeCatalog(); once the test is run and passes, the code is switched back to the real thing. This obviously poses a huge risk for introducing test code into production and in my opinion is worse than just keeping the dependency and its associated setup work. Another popular approach is to make use of Factory methods which use an object whose "job" is to know how to obtain a valid instance of the object. Using this approach, the code may look something like this: 1: ICatalog catalog = CatalogFactory.GetCatalog(); The code inside the factory is responsible for deciding "what kind" of catalog is needed. This is a far better approach than the previous one, but it does make projects grow considerably because now in addition to the interface, the real implementation, and the fake implementation(s) for testing you have added a minimum of one factory (or at least a factory method) for each of your interfaces. Once again, developers say "that's too complicated and has me writing a bunch of useless code" and quietly slip back into just creating a new Catalog and chalking any test failures up to "it will probably work on the server". This is where software intended specifically to facilitate Inversion of Control comes into play. There are many libraries that take on the Inversion of Control responsibilities in .Net and most of them have many pros and cons. From this point forward I'll discuss concepts from the standpoint of the Unity framework produced by Microsoft's Patterns and Practices team. I'm primarily focusing on this library because it questions about it inspired this posting. At Unity's core and that of most any IoC framework is a catalog or registry of components. This registry can be configured either through code or using the application's configuration file and in the most simple terms says "interface X maps to concrete implementation Y". It can get much more complicated, but I want to keep things at the "what does it do" level instead of "how does it do it". The object that exposes most of the Unity functionality is the UnityContainer. This object exposes methods to configure the catalog as well as the Resolve<T> method which is used to obtain an instance of the type represented by T. When using the Resolve<T> method, Unity does not necessarily have to just "new up" the requested object, but also can track dependencies of that object and ensure that the entire dependency chain is satisfied. There are three basic ways that I have seen Unity used within projects. Those are through classes directly using the Unity container, classes requiring injection of dependencies, and classes making use of the Service Locator pattern. The first usage of Unity is when classes are aware of the Unity container and directly call its Resolve method whenever they need the services advertised by an interface. The up side of this approach is that IoC is utilized, but the down side is that every class has to be aware that Unity is being used and tied directly to that implementation. Many developers don't like the idea of as close a tie to specific IoC implementation as is represented by using Unity within all of your classes and for the most part I agree that this isn't a good idea. As an alternative, classes can be designed for Dependency Injection. Dependency Injection is where a force outside the class itself manipulates the object to provide implementations of the interfaces that the class needs to interact with the outside world. This is typically done either through constructor injection where the object has a constructor that accepts an instance of each interface it requires or through property setters accepting the service providers. When using dependency, I lean toward the use of constructor injection because I view the constructor as being a much better way to "discover" what is required for the instance to be ready for use. During resolution, Unity looks for an injection constructor and will attempt to resolve instances of each interface required by the constructor, throwing an exception of unable to meet the advertised needs of the class. The up side of this approach is that the needs of the class are very clearly advertised and the class is unaware of which IoC container (if any) is being used. The down side of this approach is that you're required to maintain the objects passed to the constructor as instance variables throughout the life of your object and that objects which coordinate with many external services require a lot of additional constructor arguments (this gets ugly and may indicate a need for refactoring). The final way that I've seen and used Unity is to make use of the ServiceLocator pattern, of which the Patterns and Practices team has also provided a Unity-compatible implementation. When using the ServiceLocator, your class calls ServiceLocator.Retrieve in places where it would have called Resolve on the Unity container. Like using Unity directly, it does tie you directly to the ServiceLocator implementation and makes your code aware that dependency injection is taking place, but it does have the up side of giving you the freedom to swap out the underlying IoC container if necessary. I'm not hugely concerned with hiding IoC entirely from the class (I view this as a "nice to have"), so the single biggest problem that I see with the ServiceLocator approach is that it provides no way to proactively advertise needs in the way that constructor injection does, allowing more opportunity for difficult to track runtime errors. This blog entry has not been intended in any way to be a definitive work on IoC, but rather as something to spur thought about why we program to interfaces and some ways to reach the intended value of the practice instead of having it just complicate your code. I hope that it helps somebody begin or continue a journey away from being a "Cargo Cult Programmer".

Search Results

Search found 740 results on 30 pages for 'kyle burns'.

Page 1/30 | 1 2 3 4 5 6 7 8 9 10 11 12 | Next Page >

- by arungupta

- by reza_rahman

- by Yolande Poirier

- by Stan Spotts

- by Chris Farmer

- by DaleyKD

- by DaleyKD

- by Kyle Hodgson

- by Andrew Johnson

- by Kyle Lacy

- by R.Hunter

- by charlie.berger

- by Janice J. Heiss

- by Kyle B.

- by Kyle Burns

- by Kyle Burns

- by Kyle Burns

- by Kyle Burns

- by matt burns

- by Kyle Burns

- by Kyle Burns

1 2 3 4 5 6 7 8 9 10 11 12 | Next Page >