[ Pobierz całość w formacie PDF ]
.As happens in such situations, each group is also liableto feel misunderstood by the other! A variant on this is that website managers oftenwant to make changes in the display provided by standard software.Although theymay not have the advanced skills of a web designer, people unfamiliar with softwaredevelopment often find it less daunting to modify XHTML than to modify PHP code.From this angle, MVC has an appeal specifically because it seems to provide agood justification for a sharp separation of responsibilities in just the way thedifferent groups might like.It is then a short step to arguing that the creation ofXHTML should be done in a different environment from the creation of the model.Specifically, this is often thought to support the view that PHP-based websitesshould have the model built in PHP code, but the XHTML created using some kindof templating language.But at this point, the waters become muddy.The trouble is that the soundness of the MVC pattern relates to the separation ofthe code that separates the model from the code that implements the view.It isnot about separating PHP from XHTML.Note that in chapter 7, when extensionswere discussed, the architecture advocated there required output to be generated inextensions known as modules, capable of creating the XHTML for a screen box.Therole of screen boxes conforms quite closely to the role of a view in an MVC scheme.While construction of screen boxes needs PHP as well as XHTML, the PHP canusually be kept quite simple, placing a requirement on the model to offer interfacesthat are easy to use in the creation of screen boxes.Clearly the argument for splitting work between different groups is not wrong.What is important is to be clear that there are different considerations involved, andthat there is no ideal solution that will ensure that every goal is met.On the otherhand, we certainly must not lose sight of the general principle that the generationof XHTML needs to be kept on the periphery of a CMS framework so that designpossibilities are not constrained by code deep inside the framework.[ 223 ]Presentation ServicesThe way actual systems are built needs to take account of the practicalities ofworking with the needs of the people involved, and with the problem posed bythe requirement for the system.It is a mistake to impose one particular solution foranything but pragmatic reasons.Model View ControllerThe pattern known as Model View Controller, or more succinctly, MVC goesback nearly as far as object oriented development itself.As with so many aspects ofsoftware development, there are conflicting views about its implementation.Somewould argue that a system is only employing MVC if it has a specific mechanismthat enforces an MVC model across all applications.With this assumption, a CMSframework is required to implement code that makes MVC work.An alternative view stresses the character of MVC as a pattern, and urges thatpatterns cannot have once and for all implementations, since that would make themindistinguishable from algorithms.On this view, there are many ways to implementthe ideas of MVC, and a particular implementation results from bringing togetherthe principles that make up the pattern, and the particular circumstances ofthe problem.Even after we have accepted the virtues of MVC, another practical conflict ariseswith the creation of websites, between the CMS framework and specific applications.In a totally controlled environment (however that comes about) the frameworkis able to provide some standard mechanisms that support MVC.They may notexhaust the possibilities, but they can speed up the creation of applications byproviding a common base.Problems arise when applications have already beenwritten, either to work in a different framework or to work independently of anyframework.The lack of agreed standards across different frameworks makes itextremely difficult to port applications from one to another.This may work againstthe natural interests of developers of general applications, who want to see thewidest possible deployment of their work.The application developer therefore hasa difficult choice to make between whether to utilize whatever MVC features areoffered within a particular framework or to build the application with its own MVCarchitecture regardless of the framework.The extent to which a framework will need to support MVC therefore depends onthe precise circumstances in which it will be deployed [ Pobierz całość w formacie PDF ]