$(function(){
			
	var lastjavascripthash='';
			
	//if the current url has a hash on dom ready - than the user loads this url directly in browser
	if (location.hash) {
		alert('you navigated to this link using the browser address!');
		lastjavascripthash=location.hash;
	}
	//just add a dummy hash:
	lastjavascripthash=location.hash='#loaded';	
	
	//optional - when clicking the links append the hash to the url:
	$('#tostep1').click(function() {
			lastjavascripthash=location.hash='#step1';					
		});		
	
	//do regular check if the hash in the location still fits the last hash that was set via a valid javascript call
	// if not it means someone else modified the hash - typically the browser back
	setInterval(function() {
			if (location.hash != lastjavascripthash) {
				alert('you navigated to this link using the browser back!');
				lastjavascripthash=location.hash;
			}
		}, 300);
}

var browserback = {
        lastjavascripthash: '',

        setLastHash: function(hash) {            
            browserback.lastjavascripthash=hash;
        },    
        historyChangeHandler: function(hash) {
        	if (browserback.lastjavascripthash != hash) {
        		alert('you propably used browser back!');
        		browserback.setLastHash(hash);
        	}		
        },

        disableBrowserBack: function() {
        	$.history.init(this.historyChangeHandler);
        	var hash=new Date().getTime()+ Math.floor(Math.random()*1000)
        	browserback.setLastHash(hash);
        	$.history.load(hash);		
        }
}


$(function(){			
	browserback.disableBrowserBack();
}
 

Introduction

Every web application needs proper testing to ensure that it works like expected. Therefore you should have a set of test-cases, that verify the functionality of the application. For large applications you often need a separate test planning phase, where many test cases are designed – there can be  many hundreds of them.

A proper design of stable and useful test-cases is required – but that’s not part of this article. But at least we can say that:

• Most of the test-cases should focus on a single feature or requirement
• In order to keep the overview test cases should have speaking names
• test-cases should be grouped in test suites

Before a new release of a website or web-application is released, the test cases should be executed to ensure the quality of the application. For business critical websites, this phase is even more important! It’s obvious that this process can take a lot of time and effort. If you want to keep up with your competitors you do not only need a robust and high quality application - but you also need a short release cycles that adds new innovations and features to your website.

The key to solve both requirements, short release cycles and proper quality assurance, is automated frontend testing. Automated tests for web applications are furthermore also very useful in agile development processes: In an optimal way they can be used together with continuous integration, to provide early feedback for changes in the source.

Getting started with Selenium

Selenium is a suite of tools to automate web application testing across many platforms. The easiest way to start with it, is to install the Firefox add-on Selenium IDE. With this IDE you have an easy way to record and edit your test cases.

Let’s start with a simple test:

1)      Open your IDE and select "new" > "testsuite". A new test suite is created, with a first empty test-case.

2)      Now just click the red record button and switch to your browser window.

3)      Open www.google.de

4)      Do a search for "typo3".

5)      On the result page highlight the website "typo3.org" and click the left mouse button. Select "assertTextPresent" from the context menu. (screenshot)

6)      Now save your test and give it the name "can search for typo3.org".

7)      Save your test suite and give it the name "google search".

Every time you want to check if google still can search for typo3 and returns the expected result "typo3.org" you can run this test case. Do this by clicking the play button in the IDE.

Speaking Selenese

If you have a closer look at your test case, you see that it consist of a list of commands. The Selenium IDE records your actions in the browser and adds the correct commands to the test-case. All commands support one or two parameters.

In fact the commands create a testing language - and they are often referred to as "selenese". For having robust test cases, it’s often necessary to tune your test case commands after recording them with the Selenium IDE. Robust means that the test cases are stable against small changes in the markup. Also while running a test case, selenium executes the commands faster than a human  - that might cause unexpected behavior, of course a test case or the application should be insensible against this too.

Therefore let’s have a closer look at the commands. In general commands are divided into actions, accessors and assertions. As mentioned commands can have 1 or 2 parameters. In most cases the first parameter is a locator to a specific UI element and the second parameter is a text pattern.

Actions do something in the browser, like clicking (command click) a link or selecting some Selectbox entry (command select). Mostly it is necessary that your test-case will wait after an action, until the web application is ready doing something. Most of the action commands can be used with the suffix "AndWait". That means that Selenium waits till the server has send back the response for the action. (See below for an example how to deal with ajax)

Assertions are mainly the verification* or assert* commands (Like verifyTextPresent). The difference between assert and verify is, that a failed assert ends the test case and a verification only marks the test case as failed - but the following commands are still executed.

Simple Selenium test case example

Let’s have a look at a simple test-case example

A more advanced selenese example

Let’s have a look at a more advanced example:

Again we start with opening some URL. Than a click action is performed on a link that has a text ending with "ajax" (3). In AJAX applications you cannot use the "*AndWait" actions, since the website is not reloaded. Here it is better to place a seperate WaitFor* command after the action command. That’s what we did on line (4), we expect that after the Ajax Response is finished when a "span" element with a class "activated" is present. The "pause" command right after a waitFor* command tends to be useful to have a better robustness of the test case.

The next commands show what else is possible. In line (6) a random value is stored in the variable $userName. This variable is used in the echo command on line (7) and then an inputfield with the id "login" is filled with this value (8).

Interesting are the possibilities of the different locators. Here some examples:

• Using the identifier locator like: “identifier=loginForm”  (identifier prefix is optional)
• Using CSS Selectors: “css=.content div.grid”
• Selecting a link with a special text: “link=my link”
• DOM Selektors: “dom=document.forms[0].username”
• Using XPath Selektors: “xpath=//form[@id='loginForm']” (xpath prefix is optional, a “//” is sufficient)

Whats next

If you want to run your tests in other browser you can use Selenium Core. Selenium Core comes with a HTML based Test-Suite Runner that can simply be called from other browsers too:

There are more useful Selenium Tools. First to be mentioned is the Selenium RC Server. This is a Java based Server, that can run tests on multiple platforms and browsers. The cool thing is that you can connect to this server from other applications. So it is possible to run Unit Tests that use Selenese to test your web application.

The TYPO3 extension “selenium”

The TYPO3 extension “selenium” can help to build Selenium Tests for TYPO3 extensions. It has:

• A backendmodul that scans for *TestSuite*.html files inside “tests/selenium” folders and links them with the Selenium Core Runner. So you can easily start Selenium tests from the backend of TYPO3.
• In the extension configuration you can configure a Selenium RC Server (default port 4444) and you can use this in your phpunit tests.
• Therefore two abstract testsuite classes are provided.
  • tx_selenium_phpunittestcase: Uses the Selenium Testcase class that is part of phpunit.
  •  tx_selenium_testcase: Uses the PHP selenium Driver, that is part of the Selenium RC package.
  • Each of this classes has a method initializeSelenium($browser,$url) that instanciates the $this->selenium based on the configured RC Server.

Links

http://seleniumhq.org/

http://seleniumhq.org/docs/

// register for clicks on the "change color Link"
this.registerEvents=function() { 				
	$('#'+this.id+' .click').data('object',this).click(function(event) { $(this).data('object').clickColorAction(); });
};

Introducing the example:

Model

Controller

/**
* detail action shows the single view of an object, if a detail view of an object is
* requested.
*
* @return string
*/
public function showdetailAction() {
   if (empty ( $this->arguments ['id'] )) {
    throw new InvalidArgumentsExcepton('no valid id given');
   }
   $this->view->setArticle ( $this->articleRepository->findById ( $this->arguments ['id'] ) );
   return $this->view->render ();
}

The detail view

<div id="objects">
 <h2><?php echo $this->article->getTitle();  ?></h2>
 <p><small><?php echo
$this->labels->get('field_category'); ?>:<?php echo
$this->article->getCategory()->getTitle();
?></small></p>
       
 <p><small><?php echo
$this->labels->get('field_date'); ?>:<?php echo
$this->article->getDate(); ?></small></p>
  <div class="image">
    <?php     echo $this->article->getImage();   ?>
  </div>
  <?php     echo $this->article->getDescription();   ?>
</div>

1. we could use viewhelpers (like $this->fieldRenderer->asImage(...)) to transform the imagepath to a imagetag for example.
2. we can use a presentationmodel and do the transformation of fields for the view there.

new tx_mvcnews_presentation_articlePresentationModel ( $this->articleRepository->findById ( $this->arguments ['id'] ), $this->configuration->get ( 'presentationModel.article.' ), 'tx_mvcnews_article' );

The showlistAction and the listview:

1. get the correct collection of articles, that matches the search
2. render the output with: searchform, pagination and actual results.
   

• the paginationSubView has setter methods to provide the required informations for the pagination
• the searchformSubView - well it needs a formmodel. The formmodel tells the searchForm which formelements it can render. The seperate formmodel is also greate to validate the users input before doing anything.
• and finaly the listSubView needs the collection of articles that it should render.
  

Whats next?

• add AJAX loading for searching and paginating
• add more features like commenting and rating, that propably results in a richer domain model and more action methods in the controller.
  

Model:

View:

Controller:

The historic basic "smalltalks-80" classical MVC:

Downsides of the smalltalks 80 MVC concept:

MVP vs MVC

MVC for Webapplications

• The request that is send from the browser to the webserver is send to a front controller. This front controller builds a request object and starts the processing of this request.
• That means Controller Objects are called (normally action methods in the controller that belongs the current request. This process is called "dispatching") and this controllers are responsible to return the correct response. Like normal controllers they do:
  • The controller loads/modify model objects
  • Pass the model to a view
  • calls the view "render()" method to get the response.
• Normally the view that is returned to the browser consist of a hierarchie of subviews and/or widgets.

• http://flow3.typo3.org - the upcoming framework for TYPO3 5.0
• http://typo3.org/extensions/repository/view/mvc/current/ - extension enables MVC based plugin on top of the CMS TYPO3 4.x
• http://framework.zend.com/ - powerful collection of PHP5 classes and modules, includes also a full featured MVC framework

cd /opt/local/bin
sudo ./port selfupdate -f
sudo ./port search php5
sudo ./port variants php5-devel
sudo ./port install php5-devel +apache2 +macosx +mysql5 +sqlite

Installing FLOW3

Update (18.10.2009)

( sudo ./port installed )
sudo ./port uninstall php5-devel
sudo ./port install php5 +apache2 +macosx +mysql5 +sqlite

$object= new class_i_need();

class foo {  
 public function __construct(class_i_need $object) {
   $this->object=$object;  
 }
}

$myFooInstance=tx_picocontainer_IoC_manager:create('foo');

The extension "picocontainer"

1. you need to register your classes to the "IoC manager"
2. then you can ask the manager for instances, and it will resolve the dependencies (if it can).

//registering a singleton class
 tx_picocontainer_IoC_manager::registerSingleton(CLASSNAME)
//getting a singleton instance
$object=tx_picocontainer_IoC_manager::getSingleton(CLASSNAME);
//registering a prototype class:
tx_picocontainer_IoC_manager::registerPrototype(CLASSNAME); 
//get a new instance:
$object=tx_picocontainer_IoC_manager::create(CLASSNAME)

Domain Driven Design (DDD) is an approach of how to model the core logic of an application. The term itself was coined by Eric Evans in his book "Domain Driven Design". The basic idea is that the design of your software should directly reflect the Domain and the Domain-Logic of the (business-) problem you want to solve with your application. That helps understanding the problem as well as the implementation and increases maintainability of the software.

The Domain Driven Design approach introduces common principles and patterns that should be used when modeling your Domain. There are the "building blocks" that should be used to build your domain model and principles that helps to have a nice "supple design" in your implementation.

Basics

Ubiquitous Language

• The DM is the backbone and it uses terms of the "ubiquitous language"
• Therefore no translation between developers and domain experts - as well  between developers itself are required.
• During the analysis the ubiquitous language should be used to describe and discuss problems and requirements. If there are new requirements it means new words enter the common language...

• Try to explain scenarios loud with the use of the model and the ubiquitous language
• Try to explain scenarios more simple/better (find easier ways to say what you need to say). That helps refining the model.

UML and DDD

• Use of UML class diagrams to sketch the main classes. 
• Do not go to draw every class you going to code => keep overview of the main stuff!
• Use structure (packages and subpackages). Use freetext to explain constrains and relations.
• Simplify the class diagram when you use it to talk with domain experts (better a diagramm is useful than standard compliant)

Layered Architecture

Main Domain Model elements (building blocks)

Associations between elements

• impose a traversal direction instead of a bidirectional (bidirectional means both objects can only exist together -> ask if this is really the case)
• adding qualifier, effectively reduces multiplicity: If you have much associations and/or multiplicity for both ends of the association, it can be a sign that a class is missing in your model.
• eliminate nonessential associations

Entitys

• has continuity through live cycle
• object defined by its own not by attributes
• keep the class definition simple => focus on live cycle
• be alert to requirements that require a matching through attributes (because of possible problems with the need for identity)
• use of some Identifier (IDs) is often useful

Values

• value objects are allowed to reference an entity
• often passed as parameter in messages between other objects
• they are immutable! Ideally the only have getter methods and their attributes are set during construction (constructor method).
• make them a “whole value”  - means a conceptual whole (e.g. address)
• identity gives freedom in design – we don’t need to care of identity: we can simple delete and create new ones if required.

Service

• be stateless
• be defined in the common language
• use entity/value objects as parameters

• be mixed with responsibility of infrastructure or system layer
• be mixed with the application layer. For example export or import is not part of the domain layer (an export or import fileformat has no meaning in the domainlayer – they belong to application)

Modules

• helps understanding of large systems
• low coupling between modules
• independent development possible
• if you group objects in a modul you want others to think of this objects together => group by meaning in the domain layer

Aggregates

• Invariants and rules have to be maintained. The aggregate root normaly takes care of invariants.
• cluster entities/values into aggregates and define boundaries around each.
• One entity is the aggregate root and controls all changes and access to the objects inside
• Delete have to delete complete boundary

Factory

Factory Method:

Constructors

A good factory:

• is atomic (you need to pass all parameters that are need to build a valid "thing")
• are predictable
• not allowed to give wrong results (instead throw exception)
• the factory will be coupled to its arguments, therefore carefully choose the parameters:
  • there is the danger of too much dependencies - better use parameters that are allready in the conceptual group or in dependencies allready
  • use abstract types as parameter
• the factory is responsible for invariants… (maybe delegate it)
• there are also factories for reconstitution

Entity factory

Value factory

Get references of entities and objects:

1. build a new object - e.g. with the help of a factory
2. reconstitution of an object (relevant when the id is known - done by the factory)
3. traversal between objects, means to ask other objects for objects. For example that have to be used for inner aggregates of course.

Repositories

• Decouple client from technical storage
• Performance tuning possible
• Communicate design decisions related to data access
• keep model focus
• dummy implementation for unit testing is possible.
• Repositories can hide the OR mapping.

Bigger picture

• classes should have an "intention revalving interface": names of classes and methods should explain clearly what they do.
• methods shouldn't have side-effects: As much as possible should be query (no change to the state of the model). Commands should be clear and simple.
• If there are unavoidable sideeffects they should be made explicit through assertions. (e.g. state post-conditions and invariants)
• conceptual contours: "Decompose design elements (operations, interfaces, classes, and aggregates) into cohesive units, taking into consideration your intuition of the important divisions in the domain. Observe the axes of change and stability through successive refactorings and look for the underlying conceptual contours that explain these shearing patterns. Align the model with the consistent aspects of the domain that make it a viable area of knowledge in the first place."
• where logic use simple "standalone classes" with a certain functionality, that is easier to understand and better to maintain (e.g. because you have less dependencies)
• closure of operations, simple means a method should answer with the same object/datatype which it takes as parameters. You should use this where possible because no new dependencies are introduced when using this method.

More to read

Domain Driven Design in practice

• There is a sample application to show how the implementation with domain driven design can work. It is the example application for cargo (used also in the book from Eric Evans): http://dddsample.sourceforge.net/
• There is also a good article abould DD in practice with a demo application for download: http://www.infoq.com/articles/ddd-in-practice  

Links

• The homepage of Domain Driven Design is www.domaindrivendesign.org - it is maintained by the leaders in this area like Eric Evans and Jimmy Nilsson.
• Recently a interesting interview was published there: http://domaindrivendesign.org/events/qcon2008SF/eric_evans/index.html
• New book from Martin Fowler: http://martinfowler.com/dslwip/
• http://www.domainlanguage.com/ddd/index.html