// 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 install php5-devel +apache2 +macosx +mysql5 +sqlite

Installing FLOW3

$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

Did you know?

• JavaScript has no classes - but objects - which can be manipulated during "runtime"
• objects can inherit from other objects
• functions - and in fact nearly everything in JavaScript as well - are objects
• all function objects have special properties like prototype or caller

Literal Notation for creating new objects

//create new object:
var myobj = {};

//create new simple property with dot notation
myobj.name = "Mustermann";
//create a function "getName"
myobj.getName = function() {return this.name};
//use the braket notation
myobj['firstname']="Max"

var myobj = {
            name: 'Daniel',
            firstname: 'Max',
            getName: function() {            
                return this.name;
            }    
}

var myobj2=myobj;
myobj2.name='foo2';
alert(myobj.getName());

More about objects

Functions are more advanced objects

var myadvobj= function() { return 'hello world'};

Using function objects and the prototype property

var myadvobj= function() { 
  this.name='my default name';
  return 'hello world'
};

console.log(myadvobj.prototype);

var obj1=new myadvobj();

var obj2= new obj1(); //gives an error

myadvobj.subFunction=function() {return 'hello 1'};

myadvobj.prototype.subFunction2=function() {return 'hello 2'};

var obj=new myadvobj(); //create instance of function object with new operator
alert(obj.subFunction()); // returns error - the function does not exist for the instance
alert(obj.subFunction2()); // returns "hello2"

Inheritance

function begetObject(o) {
  function F() {}
  F.prototype = o;
  return new F();
}
var childObject = begetObject(parentObject);

Conclusion: Singletons and Prototypes 

Related Posts:

1. Usability concepts for "Backend" interfaces (Jens Hoffmann)
2. Going global with TYPO3 (Andreas Otto, Daniel Pötzinger and Daniel Zielinski)
3. Karsten Dambekalns

TYPO3 Certification