With RIAs growing in complexity, JavaScript developers today have to make tough choices on how to organize their code and do so in a manner that both allows for growth and ease of management. Often the wrong choices are made, impacting the maintenance cycles of the applications. In this session, we'll discuss exactly how to organize your code from ground up by exploring popular patterns used by today's industry leaders.

2. The In Action Pattern
Building extensible and maintainable
applications
JAY GARCIA,
TDG INNOVATIONS

3. A little about me...
Author of Ext JS in Action
Evangelist since 2006
Community Supporter
Extensions & Plugins
Producer of Screencasts

4. Agenda
Define the In Action Pattern
Along the way...
Learn about benefits
Define rules for naming classes
Walk through code organization

5. The In Action Pattern

6. The In Action Pattern
A set of suggestions that
define how web applications
can be developed with
reusability and maintainability
in mind.

7. 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”

8. Code segmentation
Class naming guidelines
Namespace organization
Class abstraction techniques
Simple coding practices

9. Code Segmentation
- Our first rule is about code segmentation

10. 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

11. - 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.

12. - 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

13. - 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

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

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

16. - 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.

17. 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?

18. 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.

19. 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.

20. 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.

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

22. 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!

23. 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.

24. 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?

25. 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.

26. - 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.

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

28. ArchivePanel
XFi ExplorerPanel
Namespace configExplorer
TemplatesContainer
RunNowPanel
job JobMgmtPanel
jobs CustomIssuesPanel
configMgmt
PolicyDesignPanel SpecsPanel
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.

29. Code Segmentation
- For this, we’ll discuss another facet of code segmentation

30. 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.

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

32. App
Ext JS
- 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.

33. Reusability layer
Ext JS
- 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.

34. Abstract Reporting GridPanel
Abstract ? Purpose Superclass
- Remember the AbstractReportingGridPanel?

35. el
Pan
G rid
ing Abst
p ort ractE
d
e itorW
ra ctR indow
Abst
Reusability layer
Ext JS
- 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.

36. Workflow/business logic
Reusability layer
Ext JS
- 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.

37. Workflow/business logic
Reusability layer
Ext JS
- 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.

38. App1 App2 App3 App4
Reusability layer
Ext JS
- 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.

39. Abstraction guidelines
- For this, we’ll again discuss code segmentation

40. Suggestion #4
Abstract repeatable patterns
OK

41. Configuring a
Paging GridPanel
Store
ColumnModel
ViewConfig
SelectionModel
PagingToolbar
- 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.

42. - 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:

43. - 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.

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

45. Suggestion #1
One class per JavaScript file

46. Suggestion #2
Name classes according to
purpose.

47. Suggestion #3
Organize namespace by
screens/purpose

48. Suggestion #3
Break code up into layers

49. Suggestion #4
Abstract repeatable patterns

50. In closing...

51. ...on the book front
Announcing
Ext JS in Action Second Edition
(4.0)
Sencha Touch In Action

52. Thank you!
http://manning.com/garcia
http://tdg-i.com
Twitter: @_jdg, @tdgi
jgarcia@tdg-i.com