Some thoughts on extension development
Today’s development process of a TYPO3 extension comprises (usually) the following steps:
- collect clients’ or personal needs
- design the relational model (database design)
- scaffold the extension using the kickstarter
- add a lot of database queries template handling to the file _pi1, _pi2, _pi3 etc.
- design the templates
This ends up in an extension design which is hard to maintain – especially for larger projects. A more modern approach uses the Model View Controller Pattern[1]. One of the advantages of this pattern is to enable the developer to focus on the domain of the client (and thus the domain model of the extension). So, the MVC pattern is a prerequisite for Domain Driven Design[2]. This leads to a slightly different development process:
- collect clients or personal needs
- design the domain model (classes) translating the domain knowledge of the client into UML
- scaffolding the extension using a kickstarter
- adding the business logic to the domain model classes
- design the templates
What are the pros of this approach
- The developer and the client use a common language[3].
- The domain model is more decoupled from the implementation architecture.
- It’s clearly defined where the business logic resides (in the domain model classes).
… and the cons
- It adds complexity to the extension[4].
- It forces the developer to learn new programing paradigms, which might be difficult to schedule in the daily work.
To be consequent we have to go one step further. The domain knowledge is captured in natural language. But natural language is much more expressive than object oriented software design in UML. As a consequence, there is a mismatch between the domain model expressed by the domain experts (the client) and the object oriented model expressed in UML[5].
If we want to keep all the information of the domain experts we have to define an ontology[6]. To express the domain knowledge in an ontology, OWL[7] seems to be a good solution to me, as it is a W3C standard and targets web applications. To edit ontologies I played around with Protégé[8].
In the end, we will have a process which can be named “Ontology Driven Extension Development Process”:
- collect clients or personal needs
- design the ontology using the same language as the client does
- scaffolding the extension using a new ontology driven kickstarter
- adding the business logic to the domain model classes
- design the templates
What are the pros of this approach
- The developer and the client use a common language.
- The ontology based domain model is independent from the implementation and can be shared across different extensions with different purposes.
… and the cons
- It adds complexity to the development processes.
- It’s forces the developer to learn completely new paradigms an terms.
I’m looking forward to your comments an appreciate any questions.
Footnotes
- http://en.wikipedia.org/wiki/Model–view–controller ↑
- See http://en.wikipedia.org/wiki/Domain-driven_design or t3n_nr11_domain_driven_design.pdf ↑
- This is also called “ubiquitous language” in the context of domain driven design ↑
- Complexity increases by having a lot of classes, and methods to enable interaction between these classes ↑
- There is also a mismatch between the model expressed in UML and the relational model. ↑
- The term ontology has a philosophical background. I prefer the practical use in the context of semantic web applications http://en.wikipedia.org/wiki/Ontology_(information_science). ↑
- http://www.w3.org/2001/sw/BestPractices/SE/ODSD/ ↑
- http://protege.stanford.edu/overview/protege-owl.html ↑
Great write up on a best practice process for TYPO3 extension development. Coming from the side of trying customize or maintain hundreds of extensions over the years, a consistent creation process will go a long ways to increasing code quality and maintainability.
Thanks Jochen!
The evolution you have sketched here sounds convincing – but it misses some serious points:
- Customers often don’t know or can’t express exactly what they want – or they are not willing to spend time and effort to express themselves. One could apply this attitude to any person involved in a project. Ontology sounds like an approach to bring communication (and meaning) to one level, but I doubt it can handle oddness and couriosities of people adequately. See also: http://2.bp.blogspot.com/_TsCq7ie4mYo/RhHy1lDsFsI/AAAAAAAAWZo/XWXGNYBUaOU/s1600/project.jpg
- The language of design patterns is complex and academic. Although patterns aim to make things less complex, easier to understand and better to control, reuse etc., a lot of people are not able to follow the new paradigms or just cannot afford the costs to do so. This might not a problem in enterprise projects, but in an open source community, you risk to loose the mainstream developers. Such losses hit OSS projects hard, because without the masses, spreading the word, testing and fixing small bugs is hard and expensive.
P.S. Welcome to the TYPO3 blogosphere :)
Hi Steffen.
- To close the gap between the client’s language and the developer’s language is exactly what I addressed in this post. Let’s assume you have a client paying for the software you develop is really interested in using it to solve his problems (that’s not always the case; esp. for large companies). He will be able, and willing to describe the problem to be solved in his own business related words (the domain language). The client’s domain must then be translated by the developer into (domain) objects with applicable attributes and behavior. The client has to be guided to understand the constraints of todays software. And the developer has to get a deep insight into the client’s domain.
- TYPO3 should inspire a broad bandwidth of developers to share their ideas, code and knowledge. I fear loosing progressive and modern thinking developers to other open source projects. Every developer should know that his resources depend on lifelong learning. Therefore, it’s essential for the TYPO3 community to provide good tutorials, lessons, examples, and documentation.
P.P.S why use footnotes instead of direct links?
The learning curve was steep for TYPO3 (v.3/4), although there was a lot of documentation. I hope it will be much easier to learn v.5/FLOW3, otherwise a lot of people could refuse to switch to v.5. We discussed this topic in the UG Freiburg this week and there were great concerns about loosing the connection to future development of TYPO3. I thought a while about that discussion and about motivating people to contribute. There are a lot of success factors and motivation killers, which sometimes are very close together. Example: Good documentation helps people to learn, but answering mailinglist requests with “RTFM” or “use google and find the docs” will not motivate them to use TYPO3 or even become an active member in the lists.
There were some other negative factors coming to my mind, like academic language without explanation, (seemingly) closed circles of developers, arrogant behavior, intransparency (e.g. of decision making), … Don’t get me wrong: I do not claim that this is the case for TYPO3 development, but things could be perceived to be like that. Normally, one does not have the time to follow the huge amount of communication channels (beat.typo3.org, multiple mailing lists, blogs, news, announcements, irc). Therefore it’s hard to follow what is going on. Maybe some more regular reports would be good here, channeling the communication, addressing the community. That could inspire people and make them believe in v.5.
Hi Steffen. My post is not directly related to the development of TYPO3 v5. But, you’re right: The learning curve of TYPO3 v4 is steep. And, it will be steep in v5. But, there is a difference in how and what you have to learn. TYPO3 v4 has grown vastly over the last couple of years. Today, you have to spend hours and hours searching for the applicable API functions and work-arounds. So, it takes years to really feel comfortable with the system. In the end, you become a geek in programming for TYPO3 v4. In TYPO3 v5 you have to learn new (but common) paradigms and patterns. This may take also quite a long time. But, in the end you are a geek in software development and not only in developing for a certain framework.
>In TYPO3 v5 you have to learn new (but common) paradigms and patterns.
>This may take also quite a long time. But, in the end you are a geek in
>software development and not only in developing for a certain framework.
What if you know this stuff for nearly 10 years? :) It is not new, all those patterns existed in the beginning of this century. They are only taken to PHP programming lately. In Java and C++ they existed many years ago. Good that PHP developer also started using them :)