|
|
Posted by Henk Verhoeven on 10/14/25 11:30
Nikolas Hagelstein wrote:
> Peter,
>
> [MOJAVI]
> i tried at least 5 different MVC frameworks and most of them suffer
> from the
> attempt to port "JSPs struts" to PHP.
Interesting, i never even looked into struts, so i guess this does not
hold for phpPeanuts. Anyhow, its first generation is older then struts,
so who is imititating who?
But OK, phpPeanuts is somewhat messy with respect to MVC. The trouble
is, MVC is a pattern for GUI's and was already there (Smalltalk 80,
VisualWorks) before OS's went graphical. Visual Smalltalk was built
later to fit better with Windows and OS/2 and did not explicitly include
the Controller any more, obviously becuase the OS did already take care
of most of its functions.
Furthermore, the MVC pattern is strongly connected with using event
handlers on the Model to handle events coming from the View. This adds
lots of flexibily in a situation where the abilities of the View
components are relatively fixed. This is generally the case with
traditional GUI libraries. But with HTML, there is much more freedom of
expression with respect to the Views.
At the same time the need for a design pattern to separate the graphical
side of View logic from application specific view population & refresh
has been eliminated: Nowadays the View components are the DOM objects
that live inside the browser. All events are channeled through a single
channel of HTTP requests, and in many cases large parts, if not all, of
the DOM is simply destroyed and replaced by new objects built from the
HTML that is produced by the serverside application.
Thenb why do we for Web Pages we still try to follow that same pattern?
I think some freedom of interpretation is necessary here. The main
purpose of MVC nowadays is to separate Lay Out from application logic.
And a small role is back for the Controller: to dispatch the single
stream of http requests to the right objects that should handle them.
Other problems have to be solved:
- the close coupling of url's to the web pages / types of the handling
objects makes specialization troublesome in an application that has
already been built (you have to changhe all the urls and forms that
inlcude the handler type). This is also the main reason not to use many
php scripts: you have to refer to them direcly in urls, if you refactor
part of a script to a different one, you find youself changing all those
urls. Customers do not ask for architecture, only for its reward:
flexibility.
- the web page is a too large unit for reuse of layout and user
interface logic. Smaller units are necessary, but do not come as
naturally as with GUI components, with HTML there is too much freedom
and too little ready-made funcionality. In other words, someone has to
develop the components, and they should to be smart in order to make
developers more productive. Becuase Customers DO ask for functionality,
not for nice software architecture.
PhpPeanuts solves these problems to a great extent. The examples prove
the separation between layout and user interface logic is very strong:
even if your app relies entirely on the default user interface, you can
entirly replace its layout. You can specialize many parts without
changing the urls. The heavy usage of meta data is like steroids for the
user interface components. Its flexibility helps to keep productivity
high with full-grown applications. It has been used by MetaClass for 6
real life applications. We have counted 1589 downloads since 15-3-2004
(not counting downloads of the examples and documentation). History of
earlier generations dates back to 1992 (Smalltalk, Java). And yeah, it
includes a unit testing tool too ;-)
Greetings,
Henk Verhoeven,
www.phpPeanuts.org.
(Some images of one real life app are shown on
http://www.metaclass.nl/site/mc/Pagina/87/Collectieregistratie.html)
Navigation:
[Reply to this message]
|