Basic "Boron" Architecture

→ Please note that this is work in progress…

→ Please see Demo App for a working demo application of a similar structure and some commenting on the application (how could it be improved, how can it evolve etc).

• Layered: Each layer is only responsible for one task and only communicates with layers directly under/above the layer.
• Separated clients of the core.
• Service enabled: The core should provide “services” to be used by the clients. By doing so, creating a new client (whether it be a new GUI, an XML-RPC-server, a webservice or an RSS-feed) will be very easy. (see Layers)
• URLMapper
• Exception Handling: PHP5 finally supports real exceptions; so, we should use them, since they greatly improve O-O code.

The “Boron” core should consist of layers. Here is a proposal (also, see Nucleus 5: The New Design:

• ADOdb: the database communicatoin layer. Since ADOdb is an existing library, we won't have to do anything but use this layer.
• Persistency-layer: the glue between entities (the data) via ADOdb (the database). Instead of making entities (and entity-managers), doing the SQL-stuff via ADOdb they will let the Persistency-layer do the SQL-stuff. Entities will only have to provide an interface description about their mapping to the database table(s) and the Persistency-layer will generate the SQL-queries, using that meta-data.
• Entities: the instantiated “objects” that represent actual “things”, like “blog”, “item”, “user” etc. Entities (i.e. objects) contain all the data (with the appropriate GETer and SETer methods) as well as methods that influence only one instantiated object of its own TYPE.
• EntityManagers: For every TYPE (class) of entity object, there is an EntityManager. Entity Managers will be responsable for loading (constructing), persisting (creating/updating) and deleting the entities for which they are responsible (e.g. CommentManager deletes, loads and persists Comments, but not Items; Item handling is the task of the ItemManager). The entity manager will also be used when working with a collection of entities (e.g. A batch deletion of Items is done by the ItemManager; it is impossible to let one Item handle this).
• Service-layer: accepts all client requests. That's right; clients are only allowed to talk to the service layer, while using the entity (instantiated object) data (and ONLY the data!). The services responsabilities are to delegate each request to the proper entity Manager and to ensure that every request is “one unit of work”, which either succeeds or fails as a whole … a la transactions. For example, take item creation with some new tags. If persisting the item fails, new tags creation should, also, be rolled back (a la transactions). This could probably use ADOdb transactions.

As described in Layers, the core will offer “services” for clients to use (i.e. SOA, Service-Oriented Architecture). This allows us to create an unlimited number of clients.

Example client services:

• the website itself
• the admin area
• a possible alternative admin area. For example, sites, using Nucleus as a CMS, could just use another admin area having the look and feel of a real CMS; this goes far beyond template “skinning”!
• xml-rpc
• atom (and rss)
• webservice (soap etc)

These clients will always have to talk to the services and use the data of the entities (instantiated objects). Although they might have a completely different look and/or usage, the internal system works exactly the same.

→ URLMapper is just a function name. Maybe something like RequestInterceptor (or ClientMapper) better describes its function. However, we can easily change the name later via refactoring.

It is important that new clients can be added without much effort. We should not focus on one client being “the client” (e.g. the admin area and the website (html)), while the others are just “extra clients”). I think we will need some form of “URLMapper”.

This URLMapper will intercept all site requests, study the URL and delegate the request to the right client. This enables transparent client integration. Of course, the URLMapper should be pluggable - so that new clients can plug-in their own URL-intercept code.

This would easily enable URL's like:

• example.com/article/my-foo-article → website-client
• example.com/feeds/rss → rss-client
• example.com/admin/index.php?do=viewitems → default admin area-client
• example.com/article/my-foo-article/atom → atom-client
• example.com/ws/i/874 → webservice-client

Finally, PHP5 supports Exception Handling; we should utilize this. Exception Handling greatly improves the code and is also needed for layered architecture. When a layer can't do anything useful with an exception, it should pass that exception up to the next higher layer … until it arrives in a layer which can do something useful with the exception or, if there is no such layer, the exception arrives up to the client. Then, the client will have to decide how to warn the user about the problem (e.g. show an error page or return an error-code).

A modern CMS can involve tens of thousands of lines of code, spread across thousands of files after man-years of development. To approach a new CMS, hoping for an object-oriented architecture (made possible by PHP 5), without employing the most current best practices and patterns might create a real handful …

Perhaps an overview document, specifying objectives and intended approach and supported by (including) UML diagrams of intent would help the necessary (PHP developers) help get onboard … and communicate more effectively?

Modular unit testing could accelerate task assignments, development, reliable deployment and reputation for dependability upon delivery.

Modern and thorough documentation (as a coding standard), utilizing tools like PHPdocumentor and PHPXref might allow various players to more quickly contribute and interact with other modules over time.

These tools might also help retain participation and facilitate maintenance over the life of the offering. I suspect that omitting these tools and practices might result in at least some degree of functional disappointment … and a lesser offering than could, otherwise, have been produced. Attempting an object-oriented PHP 5 CMS transition without these requisite tools might be doing half the job … and receiving only part of the potential benefits from modular, object-oriented architecture. {Mike Coughlin}

These are some plans for Nucleus 5. Read more about the project.