[development] Data API

[Frando (Franz Heinzmann)]

Hmm,
I've maybe used the wrong words to say what I intended to say ...

All you points seem to be quite logical, and they probably apply in some 
way for web development in general.
However, even if the web frameworks that claim to be MVC (RoR, CakePHP 
and many others) actually implement the MVC pattern only partially or 
even wrong, it is IMO still valid that, wether it is "true" MVC or not, 
these frameworks offer a great way of developing web applications.

I'm not an IT theorist, I was just amazed by the ease, speed and 
cleanliness of web developing with CakePHP. I never developed a 
high-quality (concerning code and security) web application any faster 
than with CakePHP (all this might apply for RoR as well, I haven't tried 
other "MVC" web frameworks yet). The model-view-controller scheme that 
is the basis of a CakePHP site seemed very logical and coherent to me, 
and I don't mind that it is not (or cannot be) a "correct" implentation 
of the MVC scheme. It's just amazing to see the "magic" of the framework 
helping you, and I *never* got the feeling of loosing control over my 
application (which is the reason for some people to not use a framework 
like this).

My main point of my previous post was and still is that it would be 
awesome to have some more of this simple, fast, secure and easy way of 
developing in drupal. I think it could improve module development in 
general a lot. Contrib code quality (and maybe even security) would also 
profit.

regards,
frando


Larry Garfield schrieb:
> On Sunday 03 September 2006 08:40, Frando (Franz Heinzmann) wrote:
> 
>> I've to say Mark's ideas are quite similar to something I thaught about
>> sometimes. Recently, I realized a project based on CakePHP [1], a
>> RoR-style MVC framework written in PHP. And I was just amazed how quick,
>> clean and easy it is to realize what you want to have by using it. It
>> would be great to have some more of the easy and simple way of
>> development that comes with a good and well-done implentation of the MVC
>> concepts. I'm not at all one of these guys who praise the MVC pattern as
>> The One Way Of Web Development or The New Holy Grail, but my experiences
>>   with CakePHP showed, that, if it's done in a good way, the MVC pattern
>> is a robust, solid and rapid way of web development that can simplify
>> web development in a good way.
> 
> Excuse me a moment while I get somewhat academically pedantic, but believe me 
> there is a point to the following. :-)
> 
> MVC is a terrible pattern for web apps.  MVC really isn't possible for web 
> apps.  I've seen only one architecture that tried to do actual MVC for a web 
> app, and it's a complete and total disaster.
> 
> Why then do people always talk about MVC as the bees knees?  Because what 
> they're calling MVC isn't; it's a bastardized MVC/PAC hybrid.  
> 
> MVC involves three distinct components: A data Model, a View component, and a 
> Controller component.  The Model abstracts the data model of the system, the 
> View component is the UI, and the Controller is an intermediary.  
> 
> OK, no big deal, we all know that; but there's an important detail that many 
> forget: The View is the entirety of the connection to the outside world.  The 
> View is both input and output into the system, and therefore must be an 
> active component.  The user changes something in the state of the View.  The 
> Controller, which is observing (Observer pattern) the View, notices the 
> change.  It responds by (possibly) taking some action against the Model, 
> which only the Controller can change.  The Model is then updated, and the 
> View, which is in turn observing the Model, notices the change and makes 
> read-only calls against it to update its own display.  
> 
> Why does this not work for web apps?  Because the browser (view) is stateless.  
> You can't run an active observer over an HTTP connection.  If you're doing 
> heavy Ajax then you can do the read-only calls against the model, but you 
> still need to notify the Controller of changes actively, in a second HTTP 
> call.  That's wasteful.
> 
> Drupal doesn't do MVC currently.  If it did, theme functions would be full of 
> database calls, when that is actively discouraged. :-)
> 
> What Drupal does currently, and what makes much more sense in a web app, is 
> PAC, Presentation-Abstraction-Control.  In PAC, input comes in via the 
> Control component.  Control then reads and writes data to the Abstraction 
> (data model), decides what to do, and sends raw data to the Presentation 
> component, which in turn renders and outputs it.  A given PAC combination, or 
> agent, can be paired with another or even daisy chained in parallel or 
> sequence to do all kinds of funky things.  But the input always comes in the 
> Control and output goes out through the Presentation.  
> 
> Drupal's menu system is its Control component.  The theme system is the 
> Presentation component.  The node system is the Abstraction component.  
> Separate PAC agents aren't really separated out, but they do map rather 
> nicely to the block concept; each block built by a separate agent.  We kinda 
> sorta do that now, but not formalized.
> 
> So I'm all for clean separation of system components in Drupal, really.  But 
> let's keep in mind how we're doing it, and what the limitations are of a 
> web-based system.  MVC is the buzzword for web apps only because Sun Java 
> engineers thought it was cool, not because it actually fits well. :-)
> 
> Yes, it's a pedantic point, but it always bothers me when people talk about 
> web apps as MVC, when in fact they simply cannot be by nature. :-)
> 
> </rant>
>