The In Action Pattern

Building extensible and maintainable applications

JAY GARCIA, TDG INNOVATIONS

A little about me... Author of Ext JS in Action

Evangelist since 2006

Community Supporter

Extensions & Plugins

Producer of Screencasts

Agenda

Define the In Action Pattern

Along the way...Learn about benefits

Define rules for naming classesWalk through code organization

The In Action Pattern

The In Action Pattern

A set of suggestions that define how web applications

can be developed with reusability and maintainability

in mind.

It’s also...

A way of thinking of your code as a set of modular and

reusable pieces instead of balls of code or

“Function Soup”

Code segmentationClass naming guidelinesNamespace organization

Class abstraction techniquesSimple coding practices

Code Segmentation

- Our first rule is about code segmentation

Suggestion #1

One class per JavaScript file

- developers are placing many classes in a single file or developing their entire app- obviously this is not good practice- Let me walk you through a quick example of what I’ve seen out in the field

- Instead of looking through each file, I run some unix commands to parse through the application code.- These are the top 5 largest JS files in their code base- Seeing numbers like these are concerning.

- One file “appointmentForms” is over 5 thousand lines long!!- Its name is a clear indication that there is more than one Form- Lets take a closer look

- Again, I use the unix grep command to find instances of Ext.extend inside the file- We can see that many lines appeared as a result- For those of you who can’t see in the back

Eleven!

- *That’s eleven instances* of Ext.extend in *one file!*-

- Looking at the output, we can quickly spot a pattern.

- Inside of the file, they named their classes rather well- All of these classes sure would be much easier to manage if they were in separate files.

Why single class per file?

Code is manageable.

Reduces debugging pains.

Helps you focus!

- Naturally, code that is broken up into chunks is more manageable.- Scrolling through thousands of lines for one file is just unproductive.- Debugging a few hundred lines is much easier than a few thousand. - It is exponentially easier to focus on code that is broken up.- OK, we know to break up our code into classes. How do we organize them?

Naming classes(and files)

- Here’s where we get into the discussion about naming your classes properly, which will lead us into our second and third rules.(aside) Some of this stuff will seem familiar to you, if you do a lot of programming on the server side with lower level languages.

Suggestion #2

Name classes according to purpose.

- While this may seem obvious to some, I’m always surprised how developers name their classes.- Lets go through another example of what I’ve seen out there.

XFi.grid.GridPanel

- While doing a code review for a customer, I found file named XFi.grid.GridPanel- This GridPanel was used for reporting screens in their application.

XFi.grid.GridPanel

- It should be quite obvious that the name “GridPanel” for a class used in an application is vague.

XFi.grid.GridPanel

XFi.grid.ReportingGridPanel

- So, I suggested they change the name to ReportingGridPanel- Prepending the word “Reporting” in the class name immediately tells us the purpose this class serves.- After some time, I learned that this class was actually not instantiated, rather was extended for various reporting screens.- Time for another name change!

XFi.grid.ReportingGridPanel

XFi.grid.AbstractReportingGridPanel

- Since this class is not directly instantiated, and is /abstract/, it should be named as such.- Prepending the word “Abstract” to “ReportingGridPanel” tells us exactly what purpose it serves.- Given this exercise, we can deduce a simple formula to name our classes.

Abstract Reporting GridPanel

Abstract ? Purpose Superclass

- We can break out class names into three pieces- The Abstract portion can be omitted if this is not a base class.- The negative side effect of this pattern is the potential for long class and file names.- I’d rather have to deal w/ that than not knowing how classes are purposed.- OK, we know how to name our classes, but how do we organize them?

Suggestion #3

Organize namespace by screens/purpose

- While this may seem obvious to some, I’m always surprised how developers name their classes.- Lets go through another example of what I’ve seen out there.

- For this customer, I found files that were named in a way that provided some level of organization, but these files were all in the root of their javascript directory.- For the most part, the names told the tail of the screen, section, and purpose.- This could be better managed if they simply used directories to organize their files.(aside) If you find yourself mixing hyphens and underscores in names, please stop.

We’ll use Suggestion #1, to clean things up a bit..

XFi Namespace

configMgmt

configExplorer

ArchivePanel

ExplorerPanel

TemplatesContainer

job

RunNowPanel

JobMgmtPanel

jobs CustomIssuesPanel

SpecsPanelPolicyDesignPanel

TriggeredJobsPanel

ConfigMgmtPanel

- This diagram represents the “configMgmt” namespace (or package), which resides inside of the XFi namespace.- In this case, configMgmt is a major screen with sub-screens. Each sub screen that has multiple classes are split into their own namespace.- Organizing code in this fashion will allow your code to be much more manageable, not to mention clean up the root of your JS directory!- This level of code organization can benefit your projects, but can quickly get cluttered, this is where further code segmentation can come into play.

Code Segmentation

- For this, we’ll discuss another facet of code segmentation

Suggestion #3

Break code up into layers

- As we’ll soon learn, breaking your code up into packages is good, but is not the final step in JS code organization.- For this we’ll have to break code up into layers.- We’ll begin by discussing how web apps are built with base frameworks.

Ext JS

- Any other base framework could exist, but for argument’s sake, we’ll use Ext JS.

Ext JS

App

- Application code typically rides on top of your base framework.- This is OK for smaller apps, but for medium to larger apps, this quickly gets to be unmanageable.- Not to mention, components that are reusable all around the app has no logical separation from the app namespace.

Ext JS

Reusability layer

- Enter the “Reusability layer”. - In the reusability layer, you typically place components that have little to no workflow/application logic.- So-called “preconfigured” classes could exist here.

Abstract Reporting GridPanel

Abstract ? Purpose Superclass

- Remember the AbstractReportingGridPanel?

Ext JS

Reusability layerAbstra

ctReportingGridPanel

AbstractEditorWindow

- Such a class belongs in the Reusability layer.- Think of it as your own custom framework of extensions that Extend Ext JS or any other library.- It is after we have a place for our reusability later that we can place our application layer.

Ext JS

Reusability layer

Workflow/business logic

- The app layer (dubbed workflow/business logic), is now placed on top of the reusability layer, which sits on top of our base framework of choice.

Ext JS

Reusability layer

Workflow/business logic

- In this model, the app layer implements the usability layer *and* base framework layers.- The reusability layer only implements the base frameworks, and knows nothing of the app layer above.(aside)Keep in mind that the base layer, could contain one or more JS libraries, such as Ext JS, raphael, and more.- After working through this model for a rather large single page app, I realized that this model could be further expanded for larger applications or multiple projects requiring portions of the resusable layer.

Ext JS

Reusability layer

App1 App2 App3 App4

- In this extension to our layer model, we have multiple applications riding on top of our reusability layer.- I’ve worked on some projects where multiple single page apps required to share classes across apps. This is where this model really shines.- With tools like JSBuilder, you could develop specific packages of your reusable components for deployment to production.

Abstraction guidelines

- For this, we’ll again discuss code segmentation

Suggestion #4

Abstract repeatable patterns

OK

Configuring a Paging GridPanel

StoreColumnModelViewConfigSelectionModelPagingToolbar

- Configuring a paging GridPanel is a repeatable pattern.- If you think about it, there is a lot of duplicated code when doing this by hand every single time.- This is a good case for an abstract class.

- In this slide, we have an abstract class for our reusable layer that will take care of all of the repeatable patterns for us.- What we see are factory methods to construct the various complex configuration options for the GridPanel.<DEMO :: Look at the real code behind this class>- Here’s what an extension to this class might look like:

- When looking at this extension to the AbstractPagingGridPanel, we can see that all the code is going to be responsible for is constructing the fields for the records and columns.- This class would exist in our application tier, and extends a piece from our reusable tier.- Some have asked, “why the factory pattern instead of using generic arrays?”- My answer is simple : “To give the end-class the choice on whether or not it will execute some business-specific logic before returning the configuration.

Summary

- OK, we’ve gone through a lot. Lets sum things up.

Suggestion #1

One class per JavaScript file

Suggestion #2

Name classes according to purpose.

Suggestion #3

Organize namespace by screens/purpose

Suggestion #3

Break code up into layers

Suggestion #4

Abstract repeatable patterns

In closing...

...on the book frontAnnouncing

Ext JS in Action Second Edition (4.0)

Sencha Touch In Action

Thank you!http://manning.com/garcia

http://tdg-i.com

Twitter: @_jdg, @tdgi

jgarcia@tdg-i.com