[development] Data API

[Darrel O'Pry]

And what exactly does this have to do with drupal development? We just
had a code freeze go review some patches. ;)


On Mon, 2006-09-04 at 10:43 +0200, Frando (Franz Heinzmann) wrote:
> 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>
> > 
> 
>