“Frameworks are the shit”

Developer Frameworks like Cairngorn, Mate, PureMVC, Robotlegs all have a number of believers using those frameworks in their projects. The main motivations are:

1. Consistency, a unified way of working and project setup, leading to a better project base and making the project easier to transfer to other teams
2. Easier to do Project- and Code Transfer, as you use standards, the ones coming after you will be able to understand and pick up the project easier
3. Reducing development time due to the basic problems and nitty-gritty type of stuf like loading and handling data already solved
4. Increased robustness and scalability, due to the use of more advanced design patterns

The illusion of “standards”

“Standards” like “Swiz” and the likes in coding have a life span of 3 to 5 years. Within that time period new “standards” arise and become the new shit. So where your project might have been according the “standard” of two years ago, that “standard” is now probably no longer supported in your organization and any newbee has basically to learn something that has become close to obsolete except for the die-hards.

As any framework introduced their own “standard” as they usually emerge from some company using some specific way of working, this “standard” is only a “standard” within it’s own closed universe.

Where Frameworks work

Frameworks work when they solve a very specific (set) of problems. Like: “showing stuff in 3D in Flash” which is for instance provided by Papervision3D and Away3D or “load a zipped file and unzip it in Flash” like

Daymo

Since Daymo started as a “Framework”, you will find that term back in the Blog name. As the project – in which Daymo is evolving – progressed, the concept of a framework of the likes of Swiz and Robotlogs has been dropped in an early stage. Also any other framework “helping” the project has been cut out, unless it delivered visible results like the Charting components in Flex. Many of the reasons are listed in this post.

The illusion of better projects and better code

Any Framework that “helps you” coding in a different way is adding an extra layer of complexity on your project. And frameworks of the likes of Swize and Robotlegs specific also break with the benefits of Strong Typing and the good that an environment like Flex Builder and FDT offer you: when you break something in your code, or when you want to follow objects back to their origin, you can.

With defintitions in Robotlegs and Swiz for injection: [Inject( source="userService" )] and this [Inject( source="userModel.currentUser" )] the reference to an object and variable is made via a String value referring to some bean defined somewhere in your project.

With that, in one blow, you kill the benefits of Strong Typing, as you can no longer guarantee if the variable you inject is of the same type or not. You might as well go back to:

var myVar : * ; 
// accepts just any type of value,
// like we did in AS2

and back to:

function myFunction(myValue: *)
{
    var something:* = myValue; // Whatever

    // Let's try
    if (something == 1 || something =="one")
    {
        // Some action
    }
}

Also: Injection and Autowiring is already a known principle in the Flex framework, using the [Bindable] tag and assigning the [Bindable] variable to an item in MXML code.

// ActionScript class: MyValueObject
[Bindable]
public static var myVariable:String="";

// Flex MXML class somewhere else in your project
// Binding is in this example done via the
// static variable myVariable
// which will automatically our Label
// when the value changes
<mx:Label text="{MyValueObject.myVariable}">

Anywhere else, where MXML binding does not work, you use events and when needed – between classes not on the display list for instance – you use Event Dispatchers in Static variables.

// Global event dispatcher in class MyGlobalDispatcher
public static var dispatcher:EventDispatcher =
        new EventDispatcher();

// Add static functions to add and remove eventlisteners
// [...]

// Somewhere else in your project:
MyGlobalDispatcher.addEventListener(
         MyEvent.EVENTTYPE, myCallbackClass);

// And somewhere else in your project
MyGlobalDispatcher.dispatchEvent(
         new MyEvent(MyEvent.EVENTTYPE));

In the end, the extra layer of yet another way of programming and organizing things in an already existing framework, makes a project worse, as you have learn and understand not only the OOP principles and Design Patterns used, the structure in which the code has been setup, the foundation framework you are already using when using Flex or Flash or Java or any other language, but also the new and introduced “language” that frameworks like Swiz, Robotlegs and the likes are adding.

And you can not do things half when you choose a framework like that. It is either everything or nothing. Not partially. Why else use it?

The illusion of reduction of development time

All above mentioned Frameworks have a learning curve. Depending on how heavy they lean on specific “Design Principles” and “Design Patterns” and how specific these principles and patterns are used and how insane, rigid and single-minded the person was creating that specific approach  this learning curve can be very steep.

Each person stepping on a specific Framework Bandwagon will have to learn the specific rules and limitations of that way of working. Regardless of how good a coder he or she is, this will take time.

Apart from learning the framework, he or she might also have to learn the specific way of building projects and classes that you use: adding more learning time.

In the end, the main question is: what do you try to solve?

One trick ponies – One size does not fit all

Frameworks in general emerge from solid re-factoring in one or a number of successive projects towards a more solid and unified process. A specific approach to solving a specific problem is reworked and reworked until it is solid and consistent. This is completely swell, but does not mean that that specific approach will fly for all problems you will encounter in new projects.

A Framework is always limited due to the way it came to existence. And thus a (sometimes very sophisticated) one trick pony.

Pretzels and code bloating

Preztels fold back on themselves. Instead of following a straight line, the string of dough is weaved. Where simpel OOP might allow you to use short cuts and straignt lines to your goal, like calling Static Functions, using Singletons and Multitons, dispatching Events over your applicaton or via centralized Event Dispatchers, Frameworks – in many cases – force you to do some folding and bending to make it work according to the very specific rules that that framework enforces on you.

Where an experienced coder might be able to make these pretzels look nice, a less experienced user of that framework might end up with something like this:

It looks kind of like a pretzel, but is not quite what was intended by the person who invented the original or optimized the design.

Code bloating is where something that you could have easily done with one or two classes suddenly requires four or more because “the framework requires you to use”:

1. A Mediator for your Class
2. A Proxy to the Mediator
3. An Event (class) for your Proxy
4. An Event Handler for the Mediator responding to the Proxy
5. An Event Handler for your Class, responding to the Mediator
6. A Service for your Proxy, talking with a Web Service on the backend
7. An Event (class) for the Service
8. An Event Handler for the Proxy responding to the Service

As this is a hypothetical example, it is not uncommon to find these kind of constructions to “abstract” your code and your classes and “increase scalability” of your application.

“Blue is the new green”

Every Framework is sensitive for the fashion of that year. Like shoulder pads came up in the 1980′s dissapeared in the 1990′s and had some kind of revival in 2008 / 2009, Frameworks suffer the same problem. “Swiz” is the new “PureMVS” is the new “Cairngorn”. And maybe “Cairngorn Light” will become the new “Swiz” five years from now, starting a whole new cycle all over.

In the end – when you take all the fashion driven (self)marketing bla bla away – you very likely end up with code cramped and twisted and twirled in a very specific way, only understandable for the very few people who also did something with Method “X” and Framework “Y” and very likely totally useless three years from now when Method “P” and Framework “Q” are the whole new shit.

Methods change

Methods change as you and your team and your organization learns and grows. While it makes sens to document your way of working, it might be counter-productive to stick to long to one specific method as they evolved from one specific chain of events.

If code consistency, project scalability and application stability are your goals: make them your priority

Frameworks and Methods and new fashions are not the holy answer to every prayer. They usually introduce some nice new insights that you might like and might like to use, but the rest is very likely only going to slow you down.

Instead:

1. Define your main goals as a team.
2. Find solutions in the basic stuff your programming language offer you.
3. Build clean classes.
4. Document your approach.

This will help much more than “using Framework XYZ”

“Style” is how you do it

Style has nothing to do with “what is hot”. It takes the best elements from everything and combines that to a new whole. Instead of following new fashions and fads with blind belief, Style follows it’s own way.

Simplify your coding, refactor and clean up your projects

If you want to do the company you work for a service, follow some basic rules.

1. If you can follow a straight line, do so.
2. If you can simplify your code, do so.
3. If you can avoid any 3rd party bullshit, do so.
4. If you can re-use some neat little tricks you built up in the past, do so.
5. If you think it will help to clean up your code and refactor your classes, do so.

Wanna do shortcuts? Build libraries, reduce your classes and refactor your code

In any project you solve very specific problems. Here is how you increase speed:

1. Isolate your smart solutions into specialized classes in special corners of your code project.
2. Strive for re-usability.
3. Make sure you can refind your solutions when you are in a new project.
4. Refactor your special code until there is nothing more to refactor.
5. Reduce your classes in your project by working Smart instead of by Copy And Paste.

What?

Timeboxing… (see full Wikipedia entry here)

…is a time management technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget. Timeboxing is a core aspect of rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development.

Timeboxes are used as a form of risk management, especially for tasks that may easily extend past their deadlines.

The Wikipedia article also mentioned (August 21, 2010 – edited by me after writing the nuances down below):

The end date [deadline] is set in stone and may not be changed. If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled. Some timebox methods allow the team to adjust the scope of the task in order to meet the deadline.

Which is not covering the real issues.

What Timeboxing covers

1. The Deadlines are usually linked to a delivery date or release date which is linked to product launches in the market and/or promises to the End Client. Not delivering on time can result to:
   1. loss of credibility (to the market)
   2. loss of clients (when the competition is high and you do not deliver, they move somewhere else)
   3. probable loss of revenue (by not selling or compensating for late delivery).
2. “Cancelling the work” is not an option when this “work” covers crucial Application Requirements.
3. If the team exceeds the deadline, the team failed in proper planning and / or effective execution of the plan. This can be the result of:
   1. The wrong people on the wrong job (lack of experience, lack of commitment / drive / motivation, lack of speed)
   2. Underestimation of the (complexity of the) requirements
4. If the team exceeds the deadline, the following actions might be taken after conferring with the Client:
   1. Dropping requirements of lower impact (the ones that will not be directly missed by the user)
   2. Working overtime to compensate for the time lost
   3. Moving the deadline

Time Boxing takes a practical hands-on approach to things that needs done, based on team work, reduction of dependencies and using priorities as the main driver. There is no one “written in stone – always leading to success” way to do it and this article only shows the middle of the road to “Timebox” your project. Each team will find it’s own way and balance.

As planning, scoping and estimating the needed time per requirement is the work of a human and based on predictions based on past experiences, Timeboxing requires care in how it is executed.

Some more general articles and insights can be found here:

1. 15 Time Boxing strategies to get things done – Litemind
2. How to use Time Boxing for getting results – J.D. Meier
3. Dave Cheong on Time Boxing

In practice

With timeboxing a project, you divide that project up in smaller “logical units” where each “logical unit”:

1. Contains a specific set of requirements which are related to:
   1. Each other due to mutual dependencies, or because they are based on the same base-classes and grouping them will increase efficiency when developed in the same session
   2. The goals set for the Development Cycle it will be developed in
2. Has a specific amount of hours assigned to it
3. Gets assigned to a team of maximally two people
   
4. Has a clear deadline

These logical units are:

1. Development Cycles, each representing a clear phase and goal to be made (“Phase 1: basic functionalities”, “Phase 2: implementation of interaction models”, “Phase 3: loading and parsing external data”)
2. Requirement Clusters, each containing a specific set of interrelated requirements, selected and tuned to help fulfill the specific goals set for the Development Cycle these Requirement Clusters are part of.

Looking at the time span, Time Boxes for:

1. Development Cycles should be contained in a maximum of 4 weeks.
2. Requirement Clusters should not exceed the limit of 40 hours or 5 working days.

Scoping

With any project you have:

1. Deadlines and time constraints
2. Requested and required functionalities
3. Available and unavailable people and capabilities
4. Dependencies on other parts or people (you might have no direct control over)
5. People being dependent on you for their part of the project

When scoping a project, you need to know:

1. The priorities of the requested and required functionalities (see MoSCoW)
2. The amount of hours each functionality will likely take to build
3. How the work done for one group of functionalities will influence the work required for another set of functionalities
4. What amount of work needs to be done to prepare the project / the foundations of the project (code base, frameworks, libraries)
5. The deadlines of the project
6. Dependencies regarding others
7. Dependencies of others regarding you

When scoping:

1. Do the most essential and most difficult parts first.
2. Take as many quick wins / visible results next
3. Avoid the parts which are dependent on still unfinished work by others
4. Prepare the building blocks other people are dependent on later in the project
5. Work progressively towards the elements which are lower on the priority list in the following order:
   1. Essential things (these are usually the things you do to build the code-base that will function as the starting point for the application)
   2. Must have things
   3. Should have
   4. Would have
   5. Nice to have (when there is time left)

De-scoping

De-scoping is the process where your start scrapping functionalities to either make the deadline or stay within budget.

De-scoping takes place:

1. Before the project starts – based on feedback sessions with the client
2. During the project – based on experiences and unforeseen issues that slow down progress or turn out to be impossible in the given time.

De-scoping is done killing “Nice to have” functionalities first and working up to “Should have” and “Would have”. Only in very exceptional cases the “Must haves” are addressed in de-scoping.

Main differences with Scrum

Scrum offers a specific approach to Timeboxing, where funny names are added and used, management is usually done on micro-level and per requirement and all team members state in daily stand up meetings what they have finished the day before, what they are planning to do today and what problems are preventing him or her from achieving the goal.

The main differences with Scrum are these:

1. Time Boxes (in the shape of Development Cycles and Requirement Clusters) are leading units.
2. Real time Communication to the Team Leader or Facilitator instead of at the end of beginning of each day.
3. No real need for Daily Scrums or Stand up meetings. If and when problems occur, team members will ask for help. As communication could and should be done direct and real time, team members who need to know, are informed real time as well, either directly or via the Team Leader.
4. Focus on Deadlines, Goals, Development Cycles and Requirement Clusters. As each member has a clear set of Requirements to fulfill, management and self management is on deadlines for each Requirement Cluster.

Working from generic to detailed specifications

Each Development Cycle should deliver a Working Proof of Concept that could be shipped if required.

This means that you:

1. Aim at the broad and overall picture first: implementing all the main building blocks of the application ans strive to deliver a working result representing the core application as soon as possibile
2. Aim for the low hanging fruit first: which are the specifications and requirements which show the most results with the least amount of effort

Each next Development Cycle is either / or:

1. Adding more detail to your implementation each next Development Cycle: working from the requirements which are essential for functioning towards the requirements that make life easier and the application more flashy.
2. Adding the requirements which you did not implement the previous Development Cycles

Why?

Timeboxing is intended to simplify planning, by reducing dependencies and taking blocks of related tasks as units of measurement instead of individual tasks, but also by stearing clearly on “getting things done” on the set deadlines.

It:

1. Delivers clearly defined results at the end of each Development Cycle
2. Allows you to get rid of micro-management and to navigate the project to clear “macro level” goals.
3. Allows you to respond faster and more dynamically to changing parameters (people falling from the team, changing priorities)
4. Gives you a possibility to reach specific goals more effectively due to grouping and different way of planning than using a “requirement by requirement” approach.

How?

There are several approaches coming together in defining and assigning your time boxes. Here is a practical breakdown of most elements.

1. Organize your requirements
   1. List them
   2. Group them
   3. Prioritize them into the following priorities – working from “quick wins” and “highly visible” functionalities to a more and more granular level. (Also additionally see MoSCoW for “Must Have, Should Have, Could Have, Would Have” filtering)
      1. What is needed RIGHT NOW (Must Have)
         1. To be able to build the application
         2. To test specific functionalities
         3. Because others in the (other) project group are directly dependent of it
         4. Because the end user explicitly called for it
         5. Because the application is useless without it
      2. What is required LATER (but still before release: Must Have)
         1. To refine specific functionalities
         2. To cover specific exceptions
      3. What CAN BE DELAYED (until after release: Should Have)
         1. Containing very specific functionalities the end user will not immediately miss
   4. Specify the amount of hours required per requirement
2. Create time boxes
   1. Select a group of requirements
      
   2. Select the requirements (at that moment unfinished) based on:
      1. The highest ranking / priority in that group
      2. Dependencies - in many cases functionalities “chain up”, meaning that you can not start one without finishing the other
      3. Related functionalities – sometimes functionalities “sprout from others” meaning that when you finish “A”, functionaliteis “B”, “C” and “D” are very easy to build next
         
   3. Cluster those requirements into a new group (your Requirement Cluster Time Box)
   1. Keep it real and take at least 50% to 100% of the estimated time a person “thinks” he or she needs to perform the task when all goes well (ideal programming time). Things go wrong. Wrong turns are taken. Something that could be done in 1 hour can explode in a task consuming an entire day. Building in buffers helps compensating the moments this happens.
   2. Take your team and the experience levels into account. Some team members are fast like lightning. Others need more time due to several reasons including experience, working pace and thinking pace. Slow workers are not necessarily unexperienced or stupid.
   1. Add up the total amount of hours required to finish that time box
   2. Work in total units of days and people, not hours. For example:
      1. Time box “A” is 40 hours x 2 people.
      2. Time box “B” is 2o hours x 1 person.
   3. Keep it coherent/keep it sane. Do not add requirements to a Requirement Cluster Time Box that do not make any sense except for “filling it up” or “because you need to put it somewhere”.
   4. Put collaterals (stuff you can not put anywhere else) in a “collateral” Cluster / Time Box.
   5. Split a time box when the total amount of hours per team member is more than 40 hours
   6. Limit the maximum amount of people on one Time Box to 2 unless there is a good reason to team up 3 or more
3. Make a plan
   1. Define your development cycles
      1. By stating the goal or goals to be made in that cycle (“Basic functionlities defined”, “ready for integration test”, “ready for user acceptence test, phase 1″)
   1. Define your time lines:
      1. In cycles, numbering from “cycle 1″
      2. In time spans per cycle, counting either / or:
         1. The number of days (for short cycles)
         2. The number of weeks (for long cycles)
      3. In boxes of weeks, including the cycle (“cycle 1″) and stating the week: (“week 1″). Examples:
         1. “Cycle 1, week 2″- where week 2 is the second week of Cycle 1
         2. “Cycle 2, week 1″- where week 1 is the first week of Cycle 2
         3. “Cycle 5, week 2″ – where week 2 is the second week of Cycle 5
   2. Organize your Time Boxes across time in order of dependency and urgency. (Most urgent first, least urgent last)
      1. Where urgency is:
         1. Required NOW
         2. Required LATER
         3. CAN BE DELAYED
      2. And organization (ordering) is based on:
         1. Clearly defined goals you have discussed with the client. (These goals are be draw down as Cycles)
      1. Where you use Time boxes as Units of Time with which you:
         1. “Paper prototype” the planning (use a wall, yellow notes and tape)
         2. Define the number of weeks or days required for each cycle, based on the number of poeple you have
   3. Do not be afraid to re-shuffle based on new insights
4. Assign Time Boxes to people, per round
   
   1. Let your team choose their specific Requirement Cluster Time Boxes – based on their experience and preferences
   2. Only choose when your team does not – there are always the less popular functionalities, comparable with garbage cleaning.
   3. Reward the team member who did garbage cleaning the last time in the next round
5. Start working
   
   1. Isolate your team. Everything that is not happening within the group and anything not related to the project does not exist
   2. Assign a team leader. The team leader keeps tabs on all individual time boxes and communicaties and reports to the outside world
   3. Define who will be Requirement Owners and Code Owners for what parts of the applications
   4. Be in direct contact with each other all the time. Either by being in the same room or by virtual meeting rooms where audio and video contact is possible all day
   5. Build the requirements you have chosen
   6. Use short development cycles. Build what you need to build, test if it breaks the application and check in your code. See also “Use short check in cycles”
   7. Respect the contract you committed to when you took a Time Box: “finish the requirements listed in the time-box stated”
6. Act
   1. Time-boxing is real time: Broadcast your status to the team leader. When you are done with one specific functionality, are to cross the deadline or have problems in any other way, notify the team leader.
   2. Ask for help. When you have trouble getting a requirement done, notify your team leader. Ask for help.
   3. Solve problems / become part of the solution. It is sometimes easier to imagine (non existent) problems and imagine (non existent) roadblocks than thinking in terms of solutions. If you tend to think in problems: get over it and start finding solutions.
7. Test
   1. Testing is an integral part of the development process. Make sure your parts work according to specifications before you start with the next.
   2. Double check before you check in your code. Nothing is more annoying for others when their code breaks due to a mistake on your side.
8. Use Version Control
   1. Don’t be a stranger. Update and check in your code more than once a day.
   2. Synchronize your code first. Before you start working on something, make sure you are up to date with everybody else’s commits. Nothing is more annoying for you when your work is based on outdated Project Code.
   3. Use short check-in cycles. Every change and any addition you create should be checked in when you think it is ready
   4. Do not break other peoples code. See “Test”.
9. Feed results back in the planning
   1. Do not change time estimated
      1. Unless you estimated too low (over-estimated items function as buffers and are only re-adjusted when they are absurd)
   2. Shift time-boxes where needed

The Time Box contract

A time box is based on estimated time and within a system a tool to move quickly, respond faster to changes in planning, reduce independencies by grouping responsibilities and get a better insight on what is needed and what is going on.

Four things can happen in your project:

1. You need less time than estimated: good going. Take a short time-out or move to the next time box.
2. You spent the exact hours: good going. Move to the next Time Box
3. You need more time than estimated. No problem. Find out and/or define why. Inform your Team Leader and make a new estimate together.
4. You needed more time than estimated, but did not notify your Team Leader yet. Bad, bad, bad! Correct directly by notifying your Team Leader and make a new estimate

These are the rules:

1. Work to meet deadlines. Meeting deadlines is your highest priority as an individual and as a team.
2. When you need more time than estimated, you have two options:
   1. Work overtime
   2. Work with the Team Leader to see what the cause and impact is and if the deadline can be rescheduled
3. See if there are short cuts to reach the same goal faster, with the same (or higher) quality. (Work smart, not hard)
4. Do what is described in your Time Box, unless it makes no sense. There is a reason for the clustering of functionalities, but people can make mistakes.
5. Feed back possible misplaced requirements in your Time Box to the Team Leader and find out where they should be placed.
6. Communicate what you are doing and where you think there is room for improvement
7. Work Smart, not Hard. Getting from A to B in the shortest amount of time is in most cases done by proper preparation and finding the shortest or most efficient route, not by running faster.
8. Respect the roles assigned to yourself and others in your team
9. Work together. Time Boxing is team work.

Working days

Extreem Programming (XP) has a very simple and clear rule about working days: “keep them family friendly”. This means 8 hour working days on normal working hours. The reason for this are simple: long working hours are counter-productive on the long run. People get tired, frustrated and lose their sharpness.

It is a wise approach. See “Keep it real” in

Senior and Junior roles within the team

Roles and main communicaton lines

If your team becomes bigger than three, you need to start dividing roles. Each of the following roles are given to senior developers.

1. Team Leader or Team Facilitatior: Takes care of the team as a whole and is the watchdog of progress, requirements, goals and deadlines. The Team Leader makes sure the team can do what is required and finds help where needed. Making sure the team can do what is required includes the reduction of distractions (other projects, questions from other people, meetings). The Team Leader facilitates in decision making processes (do we change specific parts of the code base? Should we refactor now?) and has the last word in this.
2. Requirement Owners: Are guarding the correct implementation of specific requirements within the Team. Usually these requirements are clusters of related functionalities.
3. Code Owners: Are guarding specific – often crucial – parts of the written code.
4. Architects: Design the application and (crucial) application parts. Structure the code.
5. Assistant Programmers: Assist in coding, doing more basic work.

Dividing the roles

In general one Senior Developer covers multiple roles. Here is the bottom line:

1. There is only one Team Leader.
2. The role of Team Leader can move to another person during the project.
3. A Requirement Owner can also be a Code Owner and an Architect.
4. The team as a whole defines and divides the roles, based on best qualifications and mutual consensus.

Direct communication with the Client

Unlike the classic Waterfall method and very much like RAD and Agile / Scrum, the Project Team has multiple sessions with the Client, where the status is communicated and pre-releases are shared. The main reasons are:

1. Increased commitment of the team to Client and the project. By knowing that there are real people at the other side of the table, expecting specific results, the stakes are more clear and usually the personal commitment per team member rises.
2. Reduction of misunderstandings. As the client is the one who “owns” the product as a whole, unclarities and misinterpretations in both requirements, clustering of requirments and prioritizations of requirements are usually reduced.

Important in this communication is:

1. Guarding the Scope of the Development Cycles and Requirement Clusters. Adding new functionalities automatically leads to added time required to finish a Time Box.
2. Documentation and communication of made decisions. Each decision made in the communication with the client is a new contract. Documenting these decisions is also the teams protection from arguments later in the project.

What happens in every project

People make mistakes. People get tired. People blame each other for things they might or might not have done. Things will go wrong. Code will break. Some members in the team will lack experience or the experience others assumed this person had.

When structural negative behavior wrecks the process

Time Boxing as described here is a democratic process, assuming that all involved are working towards solving the problem, building the requirements and meeting the deadline.

In practice things are not always that simple and personal motivations can interfere. Here are some possible causes that might hamper the process.

1. The bully principle: In this principle, the “bully” is constantly trying to prove that he or she: “is better than you / better than him” by “funny” remarks and critiques on others and the work of the “weaker links”. Bullies are a problem, as they bring down others and slow down the project.
2. The heavy burden issue: In this situation, anything that is not available as a Copy & Paste solution is perceived as a heavy burden by the person with this issue.
3. The wrong person on the wrong job: In this case, the wrong person is doing the wrong type of tasks. Either due to: lack of experience, lack of motivation or drive, or is simply not fast enough to pull the job off in the given time.
4. The consequential saboteur: Due to a lack of drive / motivation / commitment the actions this person performs are sabotaging the project. Some of these actions include:
   1. Wasting other peoples time by distracting them from their work.
   2. Wasting your own time by doing other things than what your should be doing.
   3. Using other people in the project to solve your problem where you could have done that yourself.
   4. Repeatedly consciously checking in your code without testing first.

In some cases, you need to release a person like this. In some cases you can correct the behavior.

MVVMCS – Model, View, View Model, Controller, Services - the outcome of combining the aspects of different models of MVC: MVC, MVVM, MVCS

About this article

Below you will find an extract of best practices related to MVC in the Daymo approach drawn from different sources, Design Patterns and frameworks. The main goal is to find and offer you the best and most optimal way of coding both simple and complex projects.

You will find very basic examples and summaries on benefits and possible pitfalls.

Some basic assumptions on coding

But before we start, let’s focus briefly on the basic assumptions we took on Daymo and coding.

We assume that:

1. Every project is different and comes with different demands on structure and approaches to solve problems
2. Change is inherent to building an application. Your code and your application is a growing and changing entity as your project and time progresses.
3. Restructuring and refactoring will recurringly happen along the way. At several stages in your development, you will restructure the way your code is organized. Including the places where you execute specific procedures.

The following five aspects are therefore key to Daymo:

1. Separation of Responsibilities - A way to define what belongs where, based on what it does.
2. Promoting- and Demoting code – A way to refactor you code to get clearer project structures.
3. Model Driven design - Using the data model to tell your views what to do and how to respond.
4. Event Driven design – Using events to tell “something” that “something” has happened “somewhere else”.
5. Parameter Driven design – Using parameters and Composition instead of creating Custom Classes to distinct and create Objects of the same type with different types of behavior.

Apart from that:

1. Use Strong Typing for variables and return types of functions – It will help you greatly when building your application and re-factoring and restructuring your code

The core goal of Daymo

The core goal of all below is to provide you with a structure that will:

1. Simplify your software design.
2. Reduce dependencies in your code and application.
3. Increase the stability of your application (make it unbreakable).
4. Make your code easier to refactor.
5. Reduce Boilerplate code as you will only do what is necessary for the project and also find easier ways to re-use code
6. Reduction of Classes, Code and Files as you create objects with specific behaviors via Parameters and Composition (Parameter Driven Design) and can address (self protected) objects directly instead of via layers of mediators and managers.

It is understandable that Daymo might approach things different from what you have been using and doing before and also might break some approaches which are considered to be “best practices”. Frameworks, for instance, invite you to think, look and work in one specific direction, solving problems in a very specific way to that Framework. So it might also bring you:

1. Stress and frustration from learning a new approach which might be alien to you.
2. Resistance from doing things you have been tought to be “wrong”.
3. New insights into stuff you took for granted before.

.

MVC, MVVM and MVCS

There are many different opinions on how MVC should and could be implemented. Each of them add their own value and neither of them is the ultimate solution. To understand the basics of MVC I went back to the original definition by Steve Burback here and also to this one quoting an unfindable paper by Dean Helman.

MVC

The Model, View, Controller pattern

The MVC pattern is the most common. It stands for “Model”, “View” and “Controller”. Below you will find each more closer defined.

According to the definition of Dean Helman, the MVC pattern originates from this flow:

[User] Input –> Processing –> Output
Controller –> Model –> View

As you will read in the quotes and the next chapter, the Model is more than storing and providing data alone. The Model also contains all your application logic, including classes to process data and execute business logic. Quoting quotes from Dean Helmans Objective Toolkit Pro whitepaper:

a model encapsulates more than just data and functions that operate on it. A model is meant to serve as a computational approximation or abstraction of some real world process or system. It captures not only the state of a process or system, but how the system works.

MVVM – adding the “View Model”

The Model, View, View Model pattern

When using the MVC pattern, you will find you have two types of “Models”:

1. Dealing with View Specific data (the View Model)
2. Dealing with a lot of processes and things that eventually will produce data to be presented or rendered in your View (The Model)

The MVVM pattern makes this Separation of Responsibilities easier. You will see in the “Combining best practices” below how we recommend you to apply the MVVM pattern with MVC in flex. MVVM is credited to John Gossman.

MVCS – adding Services

The Model, View, Controller, Services pattern

As an application is also loading and storing data from and to external data sources, the MVC-pattern has been extended with “Services”.

Services are called to to specifically that: accepting, loading and storing any type of data from any type of external source. MVCS is apparently intorduced to the (Flex) community in 2006 by Joel Berkovitz

Combining the best practices

Huh? 3-Tier!

Looking at the structure that emerges here, by combining MVC, MVVM and MVCS, you will find many parallels with the 3-Tier approach which consists of:

1. The Presentation Layer / Tier – Represented here in the User Interface Domain.
2. The Business Layer / Tier – Represented here in the Application Logic Domain.
3. The Data Layer / Tier – Represented here in the Services Domain.

(MVC – according to WikiPedia – is an older structure than the 3-Tier approach. Where 3-Tier emerged in the 1990′s, MVC originates from the late 1970′s.)

Handling this setup according to Daymo

With Daymo you make a distinction between User Interface specific and Application Logic specific domains.

The Application Logic Domain is Data- and Business Logic Centered and contains all the code required to run the Application. This includes generic View States and Application States but excludes View-specific code.

The User Interface Domain is View Centered and contains all the View-specific code. The Views will therefore instantiate the Controllers and the View Model Objects

A View Object instantiates the View Model Object and the Controller Object.

A View Model Object connects to the Application Model and Application Logic via an Object Request on an Object in the Application Model. This request is a Static Function on the Object itself.

A Controller observes the View and deals with events happening in the View, to update the View Model Object.

Services are invoked from the Application Model Domain.

We will go into the different aspects of this setup later in this document.

.

The Model

The most common description of the Model and it’s role is like this (from Wikipedia):

The model is used to manage information and notify observers when that information changes. The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can be refreshed.

The problem is: how do you translate this to anything? Based on the description above we deal with data, information management and notifying observers when things changes in the model, but nothing clear about where to put “the smart stuff” and how to organize, categorize and name that stuff. Searching further, I came to this definition of the Model on OOtips (accredited to Dean Helman):

[The model is used] to manage information and notify observers when that information changes. [...] It contains only data and functionality that are related by a common purpose [...]. If you need to model two groups of unrelated data and functionality, you create two separate models.

[...] a model encapsulates more than just data and functions that operate on it. A model is meant to serve as a computational approximation or abstraction of some real world process or system. It captures not only the state of a process or system, but how the system works. This makes it very easy to use real-world modeling techniques in defining your models. For example, you could define a model that bridges your computational back-end with your GUI front-end. In this scenario, the model wraps and abstracts the functionality of a computation engine or hardware system and acts as a liaison requesting the real services of the system it models.

The Model in brief:

• Represents a real world process or system
• Captures the state of a process or system and how that system works
• Manages information
• Notifies observers when information changes
• Contains data and functionality
• The data and functionality are related by a common purpose
• You can have multiple models – unrelated functionality and data are placed in a separate model

Now each of these are pointers, giving you an idea where to look for what. The purpose of the next part is to make some practical sens out of this and put it into something you can code. To do that, let’s state some more definitions first.

Model Objects

As the Model is the sum of all parts, we choose to refer to the Model parts in general as Model Objects.

Separation of responsibilities

When you look at classes inside the model, the most common are the Value Object, the Object, the Manager and the Handler. Let’s put them in line.

1. The Value Object (VO) – The Value Object is completely stupid. Its only function is to contain data.
2. The View Model Object (VMO) - The View Model Object is directly related to the View.
3. The Object – The Object is your generic all purpose thing and a bit smarter than the VO. It holds data like the Value Object and is able to perform specific simple actions.
4. The Handler (HND) – The Handler is created to perform or “handle” specific but simple actions, like loading files, sending data to the server, and parsing data from one format to another.
5. The Manager (MGR) – The Manager is created to deal with the more complex issues. It usually deals with multiple issues from multiple sources, managing them using specific rules.  Managers use and (can) contain the Business Logic and uses the Business Rules of your application.

Promoting and Demoting your code

Let us assume that in most cases you start with an Object. This Object has some internal logic and performs specific actions. When that internal logic grows, you might want to start separating it into different logic blocks.

Code Promotion and Code Demotion is just another way to say:

1. “This part of code does more things or smarter things than should happen in this specific Class”
2. “We should extract this specific part / these specific variables and place it in a separate class”.

- Promoting your code

A promotion means that the code moves one or more steps up the ladder. So code inside your Object that is more than – let’s say – 10 lines, does smart stuff or handles specific things and shows ambitions to grow even more, will become a Handler or Manager.

- Demoting your code

When you are only storing values inside an Object and it turns out to have no intelligence at all, you demote the Object to become a Value Object.

Handlers

The Handler can be split up into separate parts, doing very specific things. In practice you will find:

1. The Parser – Parsing data from one data-format or data-structure to another.
2. The IOhandler, which can be split into:
   1. The (Data) Loader - Loading data from a server or device
   2. The (Data) Submitter – Sending data to a server or device
3. The Verifyer – Veryfying data and variables based on Rules or Business Rules
4. The Wrapper or Adapter – Adding extra functionalities and handles to an object, to make it complient to your specific needs
5. The Controller – Doing very specific stuff based on user actions and user interactions
6. The View State Engine – Doing very specific stuff with the View, based on internal and external settings and values.
7. Utilities – Doing very generic but time-saving stuff which you can re-use in any project. Like: validating e-mail addresses, cleaning up objects, copying values from one object to another and so on.

Managers

Managers can be split into different levels of management in your applicaton:

1. Managing Items – Dealing with the low level parts in your application, making sure everything is done right.
2. Managing Views - Dealing with what is visible and hidden, kept persistent or treated as disposable items (thrown away once used)
3. Managing Application Parts – Dealing with a very specific part of the application, like “The 2D drawing area” of an paint-application
4. Managing the Application – Managing the overall flow of interactions

Static functions on Managers

Managers are there for other parts of the application to be used. To avoid Object Instantiation Dependency, Daymo promotes to use Static Functions on Managers so that you can directly ask a Manager to perform a specific task without having to care where or by whom it is instantiated

Application Models and View Models

As stated before, a Model is the sum of all parts. In the case of coding, these parts are Objects. Looking at an application you will find Objects dealing with Application Logic and Objects (in your Model) dealing with Views.

Based on the best practices of MVVM (Model, View, View Model) we recommend to create View Models to deal with the data in your View and communicate to other Objects in whatever Model there is: to store and request data.

Once you start doing that, the Objects in your Model start to form (at least) two camps:

1. View Model Objects – Dealing with your View and requesting data from and sending data to other Objects in your Model
2. Other Objects – Dealing with other stuff like: the logic of your application, handling things, managing objects and application parts, etcetera.

This is where the Application Model and the View Model concept starts.

The Application Model

The Application Model contains all the logic and Objects that run and manage your application. This includes:

1. Managers – Doing smart things and executing Business Rules
2. Handlers – Handling specific processes
3. Generic Objects - Doing and handling very simple things and storing information about the objects they represent
4. Value Objects – Containing only data
5. Business Logic – Dealing with the more complex decisions related to the application
6. Business Rules – Offering a simple way to find out whether something complies to specific rules
7. Services – Getting data from- and submitting data to- some external source.
8. Application States - Telling you what is where and telling your Views to respond

This excludes:

1. Controllers
2. View-specific Models or View-specific Value Objects
3. View-specific View States

The View Model

The View Model contains all the Classes that deal with and store View-specific data.

This includes:

1. View Managers – Managing Views and View states according to business rules
2. View Handlers – Handling specific things for specific views
3. View Value Objects – Containing View specific data
4. View-specific View States – Telling the View what to show and hide

This excludes:

1. View Objects – Being represented in either State Machines or Controllers
2. The Controller - Dealing with user input and user interaction

Object Requests – Connecting from a View Model to the Application Model

And more neutral:

There is no strong binding between objects in the Application Model and the View Model. They are two separate worlds without any direct knowledge to each other, except for the knowledge (by the View Model Object) of the existence of specific Classes with specific handles (comparable to an API) in the Application Model.

Basic rules of thumb:

1. The View Model connects to the Application Model via an Object Request.
2. The Application Model never connects to the View Model.
3. The Object Request is done via a Static Function in the Object in the Application Model.

To connect to any Data Source or Service in the Application Model in most cases a Static Function is used directly on the Class.

// We need an instantion of an object in the Application Model
var myInstance:AppModelObject=AppModelObject.getObject();

getObject can be either a provider of:

1. A Singleton Instance – Being the same object anywhere.
2. A Multiton Instance – Being a specific object based on an input variable.
3. A new Object – Created on request.
4. A Recycled object – coming from the recycle bin of that object.

We never assume anything about the returned Object from the perspective of the View Model. We fully trust that the provider knows what it is doing when providing either a Singleton, Multiton, new Object or Recycled object.

You might choose to be more specific in calling the Object Provider. The call will then look something like this:

// We need an instantion of an object in the Application Model
var myInstance:AppModelObject=AppModelObject.getAppModelObject();

The markup of the Object Provider

The Object Provider is something you create yourself, in your own Classes. Below you find four examples of an Object Provider.

The principle in Daymo is to cal the Object Provider function call “getObject”. getObject is a Static Function and looks like this:

// For a singleton
public static function getObject(): MyObject
{
   if(_instance==null)
   {
      _instance=new MyObject();
   }
   return _instance;
}

// For a multiton
public static function getObject( objectKey:<some type> ):MyObject
{
    var myObject:MyObject=_myDictionary[objectKey];
    if(myObject==null)
    {
       myObject=new MyObject();
       _myDictionary[objectKey]=myObject;
    }
    return myObject;
}

// For an Object
public static function getObject():MyObject
{
    return new MyObject();
}

// For a Recycled Object
pubic static function getObject():MyObject
{
    var myObject:MyObject;

    // Get from recyclebin
    if(_recycleBin.length>0)
    {
       myObject = _recycleBin.pop();
    }
    // Or create new one
    else
    {
       myObject=new MyObject();
    }
}

Benefits:

1. Direct but Protected Access to onbjects in the Application Model – Each Object in the Application Model implementing this approach is directly accessible, in a protected manner, so that you can not break the application by accedentily instantiating an object the wrong way.
2. Internal Object management – The Provider of the Object Instances is also the manager of the rules related to the type of instantiation (singelton, multiton, recycled, new).
3. Simplified Object management / No Object Management Dependencies – There is no need to manage the Object Instantiation on other places in your application (other than in the Object Provider itself).
4. Agnostic code – Your code only needs to know how to get the object. How it is managed is dealt with somewhere else.

Critiques:

1. Diverts from Flex Approach – This approach to get objects from the Application Model diverts from the Flex Approach and is structurally different from other frameworks.

.

The View

The View contains all visible elements, like Buttons, Lists and Text fields.

In Daymo the View is stupid. It contains no code, except for the bare basics you need to instantiate the Controller and the View Model Object.

Building the View

Phase 1: building what you need – In Flex you will normally start building your View code inside the MXML of your View. There is nothing wrong with that. Your code might look like this:

<mc:Canvas>
   <mx:formatter id="myFormatter" />
   <mx:Button click="onClick(event)" label="my Button" formatter="myFormatter"/>
   <mx:DataGrid dataProvider="{myProvider}" filterFunction="{onListItemFilter(data)}"/>
   <script>
   <![CDATA[
        [Bindable]
        var myProvider:ArrayCollection;

        // This can be moved to a Controller
        private function onClick(event:MouseEvent)
        {
 // Do Something
        }

        // This can be move to a State Machine
        private function setState(state:String)
        {
            // Hide, show or move something in the View
        }

        // This can be moved to an Handler class
        private function onListItemFilter(object:SomeValueObject):Boolean
        {
 // Check if this item complies to conditions // Returns false if not
        }

    ]]>
    </script>
</mx:Canvas>

Phase 2: evaluating your MXML code – Basic rule of thumb: When you have more than 30 lines of code and/or your code takes more real estate than your screen provides, it is time to start separating it from the MXML.

Phase 3: Separating Responsibilities – When you look at the code in your View it usually either:

1. Does someting with something else, based on events triggered by the User – This is moved into a Controller.
2. Handles something of something inside your View, like running through data in a list to filter stuff – This is moved into a Handler.
3. Influences the State of your View (hiding, showing or moving stuff), based on something happening somewhere inside or outside your View – This is moved into a State Machine.
4. Formats something in your View, like colors of elements and specific notations of (telephone) numbers – This is moved into a Formatter.

Each of the Objects from these Classes are instantiated by the View. The reference to the View is Injected when the specific object is Instantiated.

<mc:Canvas creationComplete="init()">
   <mx:Button label="my Button"/>
   <mx:DataGrid dataProvider="{viewModel.myProvider}" />
   <script>
   <![CDATA[
        var viewModel:MyViewNameVM;
        var controller:MyViewNameController;
        var handler:MyViewNameHandler;
        var stateMachine:MyVieNameStateMachine;
        var formatter:SomeSpecificFormatter;

        private function init()
        {
            // viewModel uses the Bindable options of Flex to signal changes
            viewModel = new MyViewNameVM( this );

            // The Controller will internally attach Event // Listeners to buttens and what have you
            controller = new MyViewNameController( this );

            // The Handler will deal with filters on lists and other // stuff that needs "handled"
            handler = new MyViewNameHandler( this );

            // The state-machine will deals with making items visible and invisible
            // Based on specific rules
            stateMachine = new MyStateMachine( this );

            // The Formatter attaches formatters to specific objects
            formatter = new SomeSpecificFormatter( this );
        }
    ]]>
    </script>
</mx:Canvas>

Phase 4: generalize your code – It might be that for each form you have in your project, the data is collected and sent in exactly the same way. This might lead to a generic function that looks at the display list of your form, picks out all the objects of a specific type and collects and structures the data in such a way that you can send it directly to the Server. The key questions for generalization are:

1. Did I already do something like this somewhere else? – If so, you are very likely repeating a pattern that can be generalized.
2. Can I make this into something that is re-usable? – This is the tough one. Very likely: yes.
3. Is it worth the effort? – If your generalized code is only useable on two places in your code and you will never need it again, you might consider leaving things as they are.

Instantiating your View Model Objects, Controllers and Handlers

As we already gave an example of a cleaned up View, below you will only find the <script> part, as shown above.

   <script>
   <![CDATA[
        var viewModel:MyViewNameVM;
        var controller:MyViewNameController;
        var handler:MyViewNameHandler;
        var stateMachine:MyVieNameStateMachine;
        var formatter:SomeSpecificFormatter;

        // Called "oncreationComplete"
        private function init()
        {
            // viewModel uses the Bindable options of Flex to signal changes
            viewModel = new MyViewNameVMO( this );

            // The Controller will internally attach Event // Listeners to buttens and what have you
            controller = new MyViewNameController( this );

            // The Handler will deal with filters on lists and other // stuff that needs "handled" 
            handler = new MyViewNameHandler( this );

            // The state-machine will dela with making items visible and invisible
            stateMachine = new MyStateMachine( this );

            // The Formatter attaches formatters to specific objects
            formatter = new SomeSpecificFormatter( this );
        }
    ]]>
    </script>

All the View-specific classes share the same name as the View. This makes referring and code-organizing a lot easier as your editor very likely has code-completion and other ways to help you while typing.

Motivation behind- and benefits of this approach

Even though Flex allows you to write code in your Views, this is not really recommendable. You are basically doing the same thing people used to do in HTML: mixing presentation stuff with coding stuff. While this is OK for small projects, your integrated code becomes less and less maintainable as your project grows.

The biggest pitfalls you can avoid by externalizing your code are:

1. Code repetition – It is easy and also very tempting to make quick builds by Copy & Paste the code you already made throughout your application. However, when you change your approach, this might also lead to
2. Code clutter – As the complexity of your View grows, so does the amount of functions and procedures. By Separation of Responsibilities and externalization you cut your code into clear parts which are stored in a clear place.

The main benefits are:

1. Clear separation of responsiblity – Your code is broken up into clear modules, each with a clear purpose and function
2. Easier to refactor – As your code is externalized, functionalities in your View can be changed or extended by using and adding other Classes.
3. More inviting and stimulating to generalize your code – When you start externalizing your code, you also (very likely) automatically start to seen new ways to do things smarter and more efficient. For instance: when you do the same thing on multiple places, with only slight changes in the code, it might suddenly become rewarding to generalize those parts, so that one function and one method is doing it all for everyone. This also helps you big time when you need to refactor those specific parts.

.

The Controller

The controller deals with all events on the view, induced by the user. It retrieves data from the View and passes this to the View Model Object. It can also retrieve data from the View Model Object.

In Daymo, the Controller is separated from the MXML code.

Registering Events

Although Flex provides a simple and clean way to attach Events to any object in the View, Events are best attached from the Controller, using ActionScript.

// Attaching an Event to an object in the View
myView.myButton.adEventListener(MouseEvent.MOUSE_UP, onMouseUp)

This seems retarded at first when you are used to the simple event dispatchers in MXML, but starts making sense when the same pattern is repeated for any button in your View.

Registering Events with a Handler Object

When you find that code is repeating, you might want to bundle the repetitive code. For instance: on mouse over the object receives a glow, on mouse-out the glow dissappears.

// HANDLER OBJECT public class mouseGlowHandler implements IMouseHandler { // Function to deal with repetative actions
   public function addObjectMouseHandler( object:UIComponent )
   {
       // Add eventlisteners to the object
       object.addEventListener( MouseEvent.MOUSE_OVER, onMouseOver )
       object.addEventListener( MouseEvent.MOUSE_OUT, onMouseOut )
   } 

 // Handle the events
   private function onMouseOver( event:MouseEvent )
   {
    // Do something
   }
   private function onMouseOut( event:MouseEvent )
   {
 // Do something else
   }
}

Applying the Handler Object to the buttons

// Instantiate the Handler Object
private var handler:IMouseHandler=new mouseGlowHandler();
// Apply to objects
handler.addObjectMouseHandler( this.buttonOne );
handler.addObjectMouseHandler( this.buttonTwo );
handler.addObjectMouseHandler( this.buttonThree );

.

The Services

[Text to be written]

[Embed(source='mylocationOnDisk/myImage.png')]
private var myImageClass:Class;

You can then create the image within the same class by using the class myImageClass:

var myImage:Bitmap = new myImageClass();

Centralizing the class references

The best practice according to Daymo is to centralize the class-references to images and assets.

package com.myproject.assets.icons
{
  // Class is in same directory as images are
  public class ButtonIcons
  {
    [Embed(source='icon_add.png')]
    [Bindable]
    public static var icon_add:Class;

    [Embed(source='icon_remove.png')]
    [Bindable]
    public static var icon_remove:Class;

  }
}

Referencing button icons in your project is then done as follows:

// Somewhere in your project:
var myAddIcon:Bitmap = new ButtonIcons.icon_add()

Advantages

The advantages of this approach are as follows:

1. You centralize and abstract your image and asset references
2. When you change the image (to another file) it will automatically “change” all over your project
3. Changing the folder location of your images and assets (refactoring and restructuring of your project) will not break your project when you correctly change the class-path

Calling BlazeDS: HTTP, bytecode and less overhead

Calling BlazeDS – as far as I understand now – happens through a HTTP call from Flex. The main difference between a normal HTTP call (i.e to a Jason or SOAP service) and that of BlazeDS is that all data is sent and received as structured Bytecode representing objects. This reduces a lot of data overhead you do get using XML (in the case of SOAP and Jason).

Why would we like to handle data from multiple sources?

In some cases we might want to collect data from several sources via parallel calls and put the results together in one dataset on the server. The reason to do this is:

1. Because the requested data is spread over different data sources on different machines
2. Because the requested data is from one data source, but better to be split in separate requests
3. Because some requests can be split over multiple machines on the back end to do the same job faster

Who does what?

The ideal case is this:

1. The Flex Front end only visualizes the data
2. The (Java) back end does all the heavy lifting, all the data-processing and all data-merging

Multiple Data Requests: breaking the call into chunks

When we have multiple data sets from one call, it might be more efficient to process and show them bit by bit, instead of waiting for everything to be done.

For instance: we want to get financial data over 5 different companies. Each company is a separate query with separate execution times, disributed over different processes. For instance:

• Company 1: 200 milliseconds execution time
• Company 2: 10 milliseconds execution time
• Company 3: 3.000 milliseconds execution time

The response in a normal HTTP call will take as long as the longest call: 3.000 milliseconds. However: we already had data after 10 milliseconds.

Why do we want to break the calls into

1. To present the parts as soon as they are done: increasing the user experience and responsiveness.

Two way Push or HTTP: what is the issue?

We have no real problem as long as we are talking about 3 to 10 calls. But when it includes 100 data sets, the game changes. For each separate call we will have to open a separate HTTP request. In most cases the browser Flash / Flex is running in allows us only a limited amount of concurrent calls to go out. Like 3 to 5 – let’s call them – slots. So all the other 95 data calls are waiting until a HTTP-call is finished and a slot becomes available again.

The most ideal situation is to limit the amount of HTTP-calls to the server and do as much as possible over one connection. So when we request multiple data sets we can do that immediately without waiting for slots to become available and at the same time the Server returning us complete data-sets when the process is done on the server.

There are two ways with Flash/Flex where this is simple to establish:

1. Using Sockets – keeping one persistent connection open to push data from client to server and from server to client
2. Using Adobes RMTP – keeping one persistent connction open to .. see Sockets

Two way push is a very nice and efficient way of working.

1. You push your request to the server
2. The server does its work
3. When done, it pushes the response back

With HTTP calls I open a new Socket connection which is closed as soon as the call is replied by the server. It creates more overhead and takes more time.

Why not use Sockets or RMTP?

In most companies with firewalls and proxies technologies like Sockets and RMTP are Forbidden. Anything not HTTP is blocked and filtered out as these types of connections can introduce and invite potential harm or run over ports which are blocked.

BlazeDS: assumptions on Blocking processes and data Push

In the most ideal case we can send multiple requests to the BlazeDS server via one connection and receive pushes of data back for each of the requests that is finished.

As BlazeDS uses HTTP it does not allow for a straight forward Asynchronous push-scenarios. Each call to the server opens a new socket connection which is closed as soon as the call is replied by the server. This also means that the BlazeDS server and the Java-components are very likely blocking per request: waiting and running a “while (notDone==true) { // do something }” until they have all the data.

So, assuming that: multiple calls will open multiple socket connections, each in turn dealt by a thread that is “blocking” until that specific call is dealt with.

BlazeDS: Streaming data – a Chat example

In this tutorial on the Adobe Developer Connection, two strategies are followed to create a chat application.

A quote from the site (bold are done by me):

A key element of a destination is the channel used to exchange data between the client and the server. Using BlazeDS, a messaging destination typically uses either a streaming or a polling channel.

• Using a streaming channel, the server response is left open until the channel connection is closed, allowing the server to send incremental chunks of data to the client. Because HTTP connections are not duplex, a single streaming Action Message Format (AMF) or HTTP channel actually requires two browser HTTP connections in order to send data in both directions. One is needed for the streamed response from the server to the client that the channel hangs on to. A second transient connection, drawn from the browser pool, is needed only when data is sent to the server. This second transient connection is immediately released back to the browser’s connection pool after the data is sent.
• A polling channel can be configured with a polling interval, or it can be set up to wait for data at the server-side if data is not immediately available (this approach is generally referred to as long polling). In either case, each poll response completes the request. Browser HTTP 1.1 connections are persistent by default, so the browser will likely recycle existing HTTP connections to send subsequent poll requests, which lowers the overhead for polling.

Blocking, Non-Blocking and Callbacks

A blocking process stops an entire process until something is finished.

A non-blocking process delegates the process to another Thread and continues it’s work, or simply stops until it is called back.

For a non-blocking process to know when a delegated process is done, it receives a Callback: being the Thread telling the object with the non-blocking process – for instance: “I am done”, “I am stil busy” or “I failed”.

Blocking and non-blocking scenarios

Flex is by default non-blocking in the way it deals with data-calls. Every object loading data releases the main process once fired and fires specific events:

• When loading (percentage loaded)
• When loading is done
• When an error occurred somewhere in the process

Each of these events can be captured via event listeners.

The HTTP call itself is a “singular” process. During the call a HTTP socket connection is opened to the server and once data is returned the socket connection is closed. Normally we do not persist that HTTP connection to push multiple data sets through the same HTTP socket and BlazeDS does not seem to provide a protocol for that.

BlazeDS (very likely) creates one thread per HTTP-socket: waiting for the response from the Java Bean we called and very likely blocking during that waiting process. The Java-Bean will do the same: waiting until the process is finished when calling a Service.

The Java Beans themselves can actually be using any process to get the data. Using event listeners to send their status back to another object (that will execute stuff and send data to other objects) and running in separate Threads they can be either blocking or non-blocking. In the drawing we assume they are blocking while waiting for the data form the Service.

The Services called by the beans can also be either blocking or non-blocking. Usually they are non-blocking, releasing themselves via delegates instead of actively looping in a “while (notDoneYet==true) {  // endless loop until done }” and blocking all other processes in the mean time.

Asynchronous processes work with callbacks. The object requesting an action calls out, then continues – instead of halting while waiting. When the delegate process is done, that process will notify the caller. For instance: the Service telling the Java Bean via a variable: “I am done”.

Synchronous processes stop the execution of the code in an object until something is done. Synchronous processes can freeze an entire application.

Date: June 5, 2010

So what do State Machines do again?

Daymo State Machines changes the state of an object. They are mostly used to set View States:

1. Visibility of objects – hide, show, slide out of view, slide into view
2. Width and size of objects – increase, decrease, minimize, maximize
3. Dependencies – “when the screen is maximized, the button shows a label”

State Machines act on events and values given by the objects they control and received via Static Variables.

The the state of a State Machine is set and change in the following ways:

1. Set or change a Static Variable on the Class Reference of the State Machine
2. Dispatch an event that will result in a change of state

Basic rules:

1. State Machines set values and call functions on other State Machines – This is the preferred approach. Expose Static getters, setters and function which deal internally with the right type
2. State Machines fire events to  State Machines – Although OK, try to avoid this. The State Machines approach work best when you keep State Machine Events internal. Rather set the values on static getters, setters and functions of other State Machines.
3. State Machines fire events to the outside world – Although OK, use this only when it is the best option. In principle, State Machines deal with objects directly – so address the State Machine of an object, instead of
4. Objects set values on State Machines – Perfectly OK.

State Machines rather keep Events internal

The best way to use State Machines in Daymo is to treat a State Machine as a closed environment for events. So all events a State Machine could receive, are fired internally.

Here is why:

• Keeping event dispatching inside a State Machine is keeping control over the reason a specific event was fired.
• Moving event dispatching outside a State Machine is losing control over the reason a specific event was fired.

When the (business) rules change in your application due to Change Requests, you keep control over your event-model. The risk that an Event Dispatcher somewhere in your application is overlooked is reduced.

As soon as your application becomes complex, maintaining your event model can become complex. Especially when States are dependent on other States.

An example of a “Global” State Machine

In this case the State Machine deals with a View and fires and receives all events internally.

public class MyStateMachine {

 public static const STATE_BUTTON_MINIMIZED:int=75;
 public static const STATE_BUTTON_MAXIMIZED:int=175;

 // Register a internal event dispatcher for this State Machine
 private static var dispatcher:EventDispatcher=new EventDispatcher()

 // Constructor
 public function MyStateMachine(myViewObject:MyView)
 {
    // Code to register myViewObject in this State Machine Instance
    // - We use it to deal with the object specific states

    // Init the state machine for myViewObject
    init();
 }

 // Init
 private function init():void
 {
    // Some events for this State Machine
    dispatcher.addEventListener(SomeEvent.MINIMIZE,minimizeHandler);
    dispatcher.addEventListener(SomeEvent.MAXIMIZE,maximizeHandler);
    dispatcher.addEventListener(SomeEvent.DEFAULT,defaultHandler);
 }

 // Static Public State setter
 public static function setState_Size( size:int)
 {
    // Makes the State Machine globally accessible

    // Minimize
    if(size==STATE_BUTTON_MINIMIZED)
    {
       // Tell all objects with this State Machine to act on "minimize"
       dispatcher.dispatchEvent(new SomeEvent(LeftBarEvent.MINIMIZE) );
    }
    // Do same for default and maximum width
 }

 // ==========================================
 // HANDLE VIEW STATES
 // ==========================================
 private function minimizeHandler(event:ButtonBarEvent):void
 {
    // Do something like: Hide labels and minimize widht
    setObjectWidth(STATE_BUTTON_MINIMIZED,true);
 } 

 private function maximizeHandler(event:ButtonBarEvent):void
 {
    // Do something like: Show labels, maximize widht
 }
 private function defaultHandler(event:ButtonBarEvent):void
 {
    // Do something like: Show labels, set to start-width
 }  

 // ==========================================
 // HANDLERS - VIEW STATES
 // ==========================================

 // Set button width
 private function setObjectWidth(width:int,showLabels:Boolean=true)
 {
    // Do something to set width of registered view object
 }
}

June 05, 2010

The Daymo Drag and Drop mechanism envelops the standard Flex Drag & Drop. The goal of the Daymo Drag & Drop Handler is:

1. To simplify implementing and using the drag and drop process throughout your application
2. To give you direct access to the wanted Target-object clicked by the user
3. Offer you a clear structure to handle the events dispatched by drag and drop actions
4. Exposing the “dragged” object in a more direct way.

The code examples given here are to help you understand the framework. In the “src.Prototypes” section of the project folder you will find implementations of these examples.

Making a distinction between Visual Objects, Data Objects and Handlers

Using Drag and Drop, Daymo makes a distinction between Visible Objects, Data Objects and Handlers.

Visible Objects – Anything you see on the screen, including

• Buttons
• Lists
• Treeviews
• (Smart) Visual Components you created

Data Objects – Anything that contains data.

• Models
• Specific data objects you created

Handlers – The objects that deal with the Drag and Drop events. The handler can be:

• A (Smart) Visual Component you created
• A separate object you created to deal with the events

Drag and Drop in Flex

Daymo takes a very specific approach to Drag and Drop that is different to Flex.

In Flex you tend to link each object via MXML to their event handlers, like in this code example.

    <mx:Canvas id="v1"
        width="500" height="500"
        borderStyle="solid"
        backgroundColor="#DDDDDD"
        dragEnter="dragEnterHandler(event);"
        dragDrop="dragDropHandler(event);">
    </mx:Canvas>

Then you also define the object that can be dragged:

    <!-- The image is the drag initiator. -->
    <mx:Image id="myimg"
        source="@Embed(source='assets/globe.jpg')"
        mouseMove="mouseMoveHandler(event);"/>

The code to deal with dragging and dropping – in most cases – is then embedded in the MXML of the View.

// Do something when dragobject is moved
private function mouseMoveHandler(event:MouseEvent):void
{
    var dragInitiator:Image=Image(event.currentTarget);
    var ds:DragSource = new DragSource();
    ds.addData(dragInitiator, "img");
        DragManager.doDrag(dragInitiator, ds, event);
}

// Do something when drag enters
private function dragEnterHandler(event:DragEvent):void {
    if (event.dragSource.hasFormat("img"))
    {
        DragManager.acceptDragDrop(Canvas(event.currentTarget));
    }
}

// Do something with the drop
private function dragDropHandler(event:DragEvent):void {
    // Set image on new dropped location
}

There are two disadvantages in this approach:

1. You create “smart” code inside your View. Which makes the view very use case specific
2. Your code to handle drag and drop is fragmented through your project file.

This seems not to be a big case when you start the project, but the more changes come, the more it will work against you.

So let’s compare:

To propagate a value from “Dragger” to “Drophandler” we do this:

    var ds:DragSource = new DragSource();
    ds.addData(myImage, "img");
    // Start drag and propagate variable   
    DragManager.doDrag(dragInitiator, ds, event);

That equals this:

   DragDropHandler.dataObject=myImage; // Of type Image

When we receive a drop in Flex, this is the standard approach:

// Do something when drag enters
private function dragEnterHandler(event:DragEvent):void {
    if (event.dragSource.hasFormat("img"))
    {
        // Do something
    }
}

Which equals this in Daymo:

private function dragEventHandler(event:DragEvent):void {
    // Only do things if object is of type Image
    if(DragDropHandler.dataObject is Image)
    {
       // Do something
    }
}

You will find more examples and comparisons between Flex and Daymo drag and drop further in this document. The Flex examples hopefully help you to see how Daymo allows you to make shortcuts on your code.

Keeping the Visual Objects Stupid

What we will do in Daymo is to keep the MXML-based Visual Objects as stupid as possible. All code that deals with the “smart” work will be externalized in DragHandlers and DropHandlers.

We also avoid using the DragSource. And this is why: Daymo promotes the use of Code Reduction and the use of Object Reflection when you do drag and drop. As you can only drag one object at a time in the base Flex Drag & Drop scheme we might as well use a Static Variable.

Making your own Smart Visual Components

When you make your own Visual Components, you can merge the View Object and the Drag and Drop Handlers and make the Component Smart. One example where you might do that is draggable items in a Tree View.

The Daymo Drag & Drop principle

When dragging starts you place an object in the static variable dataObject in the Daymo DragDropHandler. This creates a reference.

When the object is dropped on a drop-enabled object, you retrieve that object from the Daymo DragDropHandler.

Initializing objects for drag and drop in Flex

In the View we have a button called “dragObject”. We also have an object that operates as the drag handler: “dragHandler”. As we can define the drag- and drop handler separately, the drag and drop objects can be regular objects.

We have shown the full code at the beginning of the article, so let’s cut only the main items out.

Setting the dragEnter and dragDrop handlers:

    <mx:Canvas id="v1"
        <!-- IN DAYMO THIS IS DONE VIA acceptDrop-->
        dragEnter="dragEnterHandler(event);"
        dragDrop="dragDropHandler(event);">
    </mx:Canvas>

Defining the object that can be dragged:

    <!-- The image is the drag initiator. -->
    <mx:Image id="myimg"
        source="@Embed(source='assets/globe.jpg')"
        <!-- IN DAYMO THIS IS ADDED BY setDraggable-->
        mouseDown="mouseClickHandler(event);"
        mouseUp="mouseReleaseHandler(event);" />

The code below to deal with dragging and dropping – in most cases – is then embedded in the MXML of the View. In Daymo, all this work below is done in the Daymo DragDropManager, to save you the work of boilerplate coding.

// FLEX MXML CODE 
private function mouseClickHandler(event:MouseEvent):void
{
    var dragObject:* =event.currentTarget ;

    // Make sure we are going to drag this
    dragObject.addEventListener(MouseEvent.MOUSE_MOVE,mouseMoveHandler) ;
}
// Release drag listener
private function mouseReleaseHandler(event:MouseEvent): void
{
    var dragObject:* = event.currentTarget
    dragObject.removeEventListener(MouseEvent.MOUSE_MOVE, mouseMoveHandler);
}
// Do something when dragobject is clicked and moved
private function mouseMoveHandler(event:MouseEvent):void
{
    // Register drag start on DragManager
    // Start dargging
}

The dragHandler and dropHandler Objects are explained later in this document: how you create them, how you link them and what you within them.

Initializing objects for drag and drop in Daymo

In Daymo you make objects draggable and accepting drops via tow lines of code:

// Set object to be draggable
DragDropManager.setDraggable(dragObject, dragHandler ,true);

// Set object to be droppable
DragDropManager.acceptDrop(dropObject, dropHandler ,true);

The dragHandler and dropHandler objects are explained later in this document: how you create them, how you link them and what you within them.

Handling specific Drag and Drop events in Flex

To give you an idea how you would most likely do this in the MXML code of your view:

// Do something when dragobject is clicked and moved
// (IN DAYMO THIS IS DONE IN THE dragHandler OBJECT)
private function mouseMoveHandler(event:MouseEvent):void
{
    // Do drag and drop custom magic
}

// Do something when drag enters
// (IN DAYMO THIS IS HANDLED IN THE dropHandler OBJECT)
private function dragEnterHandler(event:DragEvent):void {
    if (event.dragSource.hasFormat("img"))
    {
        DragManager.acceptDragDrop(Canvas(event.currentTarget));
    }
}

// Do something with the drop
// (IN DAYMO THIS IS HANDLED IN THE dropHandler OBJECT)
private function dragDropHandler(event:DragEvent):void {
    // Set image on new dropped location
}

Remember that all event listeners to fire those blocks of code in Daymo are automatically created by the DragDropManager.

Creating a Drag handler object

The Drag Handler always implements IDraggable. The Drag Object always implements an interface (named IDragObjectInterface in this example). We will explain in the next part why we do that for the draggable object.

Via DragDropHandler.setDraggable we have attached eventlisteners to the Drag Handler, firing the following functions (included in IDraggable):

1. onStartDragClick – called when the user clicks on the draggable object
2. onDragRelease – called when the user releases the object
3. dragStartHandler – called when dragging starts
4. dragCompleteHandler – called when dragging with the Flex DragManager is finished
5. onRemovedFromStage – called when the dragObject is removed from stage

public class DragHandler implements IDraggable {

 // Is linked to an event by- and called from- the DragDropManager
 public function onStartDragClick(event : MouseEvent) : void
 {
    // Find out who we are dragging exactly
    var obj:* =DragDropManager.resolveTarget(
         event.target, IDragObjectInterface
    ) ;

    trace("dragging :"+obj.name);

    // Create a DradDrop Object
    var dragDropObject:DragDropObject =new DragDropObject();

    // Set the "name" variable
    dragDropObject.name=obj.name;

    // Give Daymo DragDrop manager the data-object to be read by the drop-area
    DragDropManager.dataObject=dragDropObject;
 }

 // Eventlistener set via DragDropManager
 public function onDragRelease(event : MouseEvent) : void {
     // Do something here when the user releases the mouse button
 }

 // Not used here - extra functions you can use for more control
 public function dragStartHandler(event : DragEvent) : void {
     // Do something when dragging starts
 }
 public function dragCompleteHandler(event : DragEvent) : void {
     // Do something when dragging is complete
 }
 public function onRemovedFromStage(event : Event) : void {
     // We want to remove event listeners too
 }

Creating a DropHandler object

The DropHandler deals with alle the events fired when an object is dropped on a dropEnabled object.

The DropHandler has four autmated callbacks you can use:

1. dragStartHandler – when the user starts dragging
2. dragStopHandler – when the user drops the object
3. dragEnterHandler – when the dragged object hits the droppable object
4. dragDropHandler – when the dragged object is dropped on the droppable object

Code example of a DropHandler class:

public class DropHandler implements IDroppable {

  public function DropHandler()
  {
     // We can register eventlisteners here to filter
     // specific drag actions to be ignored
  }

  // Deal with drag-object entering drop object
  // Called via the event listener set in the DragDropManager
  // when added via DragDropManager.acceptDrop

  public function dragEnterHandler(event : DragEvent) : void
  {
    var dataObject:DragDropObject =DragDropManager.dataObject;

    // Get the drop target component from the event object.
    var dropTarget:* = event.currentTarget;

    // Show icon on drag object
    // Using the Flex dragmanager
    DragManager.showFeedback(DragManager.COPY);
    DragManager.acceptDragDrop(dropTarget);    

 }

  // Deal with object drop
  public function dragDropHandler(event : DragEvent) : void {

    // We can check if the dropped object is of specific type
    if(DragDropManager.dataObject is DragDropObject)
    {
        var dataObject:DragDropObject =DragDropManager.dataObject;

        // Trace the value
        trace("Dropped : "+dataObject.name);
    }
  }

  // Explained later
  public function dragStartHandler(e:DragDropEvent): void
  {
  }

  public function dragStopHandler(e:DragDropEvent):void
  {
  }
}

Interfacing the DragObject

Remember this part in the DropHandler code above?

    // Find out who we are dragging
    var obj:* =DragDropManager.resolveTarget(
         event.target, IDragObjectInterface
    ) ;

When you start dragging an object, your “click” has been registered on something. This “something” is very likely a child-object of your DragObject. What we want to do is resolve the DragObject itself. And that is what we do here.

So let’s define the DragObject.

Public class DragObject implements IDragObjectInterface
{
   // Constructor
   Public function DragObject()
   {

   }
   // Do something here with code
}

The “implements an Interface” is crucial here.

Lets show you why via two images.

The setup:

The user clicks on some child object in MyDragObject.

Using ResolveTarget with event.target and an Interface (or Class) as the input variable, this is what happens behind the screens:

Finding the Interface (or Class):

There is no limit to the levels of nesting. DragDropManager.resolveTarget keeps iterating up until it either reaches the root level or an object of “Interface A”.

So when we look at this code in the DragHandler:

public class DragHandler implements IDraggable {

 public function onStartDragClick(event : MouseEvent) : void
 {
    // Find out who we are dragging
    var dragObj:IDragObjectInterface =
         DragDropManager.resolveTarget(
             event.target, IDragObjectInterface
         ) ;

    trace("dragging :"+dragObj.name);
    // Removed code
 }
}

we know exactly what object or value (null when not found) we can expect from resolveTarget.

Defining which drag-objects you support

The easiest way to define which drag objects you support is by checking if the object put into DragDropManager.dataObject:

1. Is of a specific class.
2. Contains a specific value

// Example of checking what is in the
// DragDropManager.dataObject
if(DragDropManager.dataObject is MyClass)
{
   // Do something
}

// Alternative: checking content of dataObject
var myObject:MyObject=MyObject(DragDropManager.dataObject);
if(myObject.name=="Peter")
{
   // Do something
}

Manipulating the drop-Objects

When you start and stop dragging, the DragDropManager notifies each DropHandler via an event.

The functions called are:

1. dragStartHandler – called when a drag object is picked up
2. dragStopHandler – called when a drag object is dropped

You can use the dragStartHandler and dragStopHandler to:

1. Grey out or hide all droppable objects which should not accept that specific drag object
2. Show all hidden or greyed out objects when the drag object is dropped.

In this example we will hide our drop-object when the data-object is not of type DragDropObject

// DROPHANDLER

// Is set by the code that created the drop object
// and the DropHandler
var dropObject:myDropObject;

public function dragStartHandler(e:DragDropEvent)
{
   if(DragDropManager.dataObject is DragDropObject)
   {
      // Do nothing
   }
   else
   {
      // Hide our droppable object
      dropObject.visible=false;
   }
}
public function dragStopHandler(e:DragDropEvent)
{
   // Show our droppable object
   dropObject.visible=true;
}

I like the coding principles and design patterns Swiz (and Robotlegs) uses. I do not like the way Swiz adds another layer of complexity and non-tracable abstraction on top of Flex, without explaining in a clear and simple way what is going on or giving you proper instructions on how to use it.

Another reason not to like Swiz is that object references – used for instance in autowiring – are String based instead of being real references. Which can become a real pain when you refactor your project.

Why I created Daymo

To do Inversion of Control, you do not need Swiz or Robotlegs. In most cases, you have very likely already been doing it in AS3 without knowing it – for instance – by using object references you “inject” into another object using code, by building singletons to share data over your project, by doing some Kung Fu with Static  functions and doing some Black Scroll Ninja Style Event Dispatching to tell other objects something has happened.

Based on those  I created Daymo.

1. It is 100% ActionScript – which means that (via the editor):
   1. Object Dependencies in binding patterns can easily be tracked (which is not the case with Swiz and Robotlegs as object references are passed as String values)
   2. Broken dependencies - due to i.e. refactoring – can easily be found
2. It shows you what you are doing and offers clear backgrounds on what Daymo is doing.
3. It helps you binding Objects and Object variables with a few simple lines of code
4. It offers you an array of nifty tips and tricks to:
   1. Reduce code on all kind of issues
   2. Simplify coding of complex Interaction Structures
   3. Refactor and restructure your project without breaking it that much (it will always break a bit)

Will following the Next New Black help you?

I have done a lot of projects in the past 10 years, including cleaning up the mess of others. I also built several Frameworks to auto-generate code form databases and generate Flash-sites from XHTML definitions.

Looking at the Design Patterns available, I have seen ways to do it and ways to completely fuck it up. (My own work included.)

With Daymo I have tried to pin this down by also offering a clear structure and a set of rules and tools on:

1. Where to put what (organization of code and Separation of Responsibilities)
2. How objects communicate (read about Global Events, Drag and Drop and the article about “Daymo State Machines and Events”)
3. How you can extend functionalities of an object and do that in a flexible way (read i.e. about State Machines and about Autowiring in the “About” page)

The main approach I use is that any code and any application is like an organization of people: with responsibilities, working together in departments or multidisciplinary teams trying to get the work done.

The main rules I use and used are: keep it clear and simple, get it right when it feels wrong, dig deeper if things seem unclear, cut the overhead where possible, use whatever methods that get you there faster with better results and you will already get very far.

Sometimes this comes with a price. Autowiring for instance opens a totally new way to distribute variables and objects through your project, reduces your coding dramatically when you bind objects, but also takes way more CPU cycles to execute. In other words: when you use it EVERYWHERE (especially binding MVC structures for list items) it will kill your application.