RE: [development] Data API
I would humbly disagree that themes would be considered the view level, or that forms represent the model level in MVC. I think originally you could argue that the node api represented the model level, and that moving crud into the forms api represents a blurring of MVC and not a step towards that. That is the primary debate that's being waged here, whether we need separation of data manipulation from the controller. I personally would like to avoid creating a ddl in drupal. One of the things that make's drupal work is how agile the loosely coupled, loosely typed system is. The $forms arrays are collection of controls. I'd love to see them stay that way. right now forms posting and validation are accessed via simple array constructs. I'd like to see them stay that way. I agree that form_validate, form_submit, node_save, and node_delete functions (when used in crud) are really model work, especially the way they are used in 4.7. I think a lot of whats bothering some is that they're getting dependent on the forms api, and that dependency may cause inflexibility down the road. I agree that defining fieldsets, checkboxes, etc. have no place in the model portion of mvc. And having to set up those contructs provide extra cruft for programatic manipulation of data. (that's the forms dependency part creaping it's head). -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Mark Fredrickson Sent: Friday, September 01, 2006 7:33 AM To: development@drupal.org Subject: [development] Data API After the previous round of talks on the form api, I have a proposal for future Drupal development: let us rename the form API to the data API and start to look at it as the central method of implementing a full MVC in Drupal. First, some observations: HTML forms are simply a method of getting data from users, nodes are collections of defined data, nodes are increasingly represented as "forms" - however, coupling our data to an XHTML representation blurs the line between model and view. The general benefits and costs of an MVC design pattern are outside the scope of this email, but feel free to criticize my position if you don't like MVCs. I will say, MVC isn't the only design pattern, but it's a good one if you don't have a reason to choose something else. Let me map the model, view, and controller to current and future Drupal constructs: 1. Model: I think most people would say that the current model is just the db schema. I say that the model should be the schema AND the data definition (currently in the shape of a form definition). In fact, I might argue that schemas should be phased out for a database abstracted system. Imagine if you could just define a simple data structure in the form: $mydata = array( '#type' => number, '#name' => 'My Number', '#default_value' => 1234, ); etc... While I agree that we having a drupal specific DDL is bad, the reality is that we already do have one: the current formAPI. Accepting that fact and writing tools to turn $mydata into a db schema will only help development, not raise the barrier. 2. Controller: These are the _submit and _validate functions right now. I know there is work going on to more flexibly work with these items (eg. I owe a patch to allow binding of buttons to functions). I think the controller layer probably needs the most work. The recent nodeapi vs. formAPI (call it Data API now!) illustrates this fact. 3. Views: Arguably, these are the theme_* functions; however, this is where the coupling of data to XHMTL forms I mentioned earlier comes in. Take for example '#type' => 'checkbox'. This definition makes me cry every time. Multiselects and checkboxes should be collapsed into one type: multi. Radios and drop downs should be collapsed into one type: single. Text boxes and text fields should just be one type, varied on size (and perhaps something else to allow filtering). If we move these functions into the theme layer, forms API will stop being just about forms and wills start being about data. Good. So, what are the benefits of this system? First, I think changing the semantics of the name will allieviate some confusion regarding the role of the Data API. The recent nodeapi discussions have shown that there is confusion over where and when data should be manipulated. I think it gives us CCK like features right out of the box. Since most of the data api will be used for defining nodes, it seems natural to me that users could define forms online and Drupal would turn them into types on the fly. This email is getting long as it is, so I'll end it here. Of course, discussion is welcome. Cheers, -M
On Fri, 2006-09-01 at 08:25 -0700, Metzler, David wrote:
I agree that defining fieldsets, checkboxes, etc. have no place in the model portion of mvc. And having to set up those contructs provide extra cruft for programatic manipulation of data. (that's the forms dependency part creaping it's head).
(forms aren't creeping this viral dna like array structure is) there is nothing saying the same data constructs can't feed a processing pipeline and rendering pipeline. Each can just ignore what they don't implement and the processing pipeline can decorate the construct before it hits the rendering pipeline.... it simplifies our internal representation. we already have that with form_builder / drupal_render as far as I can tell.
One conclusion from all this is that Form API needs to be renamed. Any suggestions? DAPI (Drupal API. Incomplete, since there is a lot of other things that are the Drupal API).
Khalid B schrieb:
One conclusion from all this is that Form API needs to be renamed.
Any suggestions?
DAPI (Drupal API. Incomplete, since there is a lot of other things that are the Drupal API).
What about dDAPI (drupal Data API)? However, I'd say the *name* is by all means the least important point to discuss ;). 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. I think by extending the FormAPI concept to a Data API we can ease and simplify drupal module development quite a lot. By adding some more "magic", as some scaffolding here and there or considering the fAPI arrays not as description of forms but as data models, lots of things (as different methods of interacting with a website, e.g. XML-RPC or import/export modules) would be far easier to realize. regards, frando [1] http://cakephp.org
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> -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
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>
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 can only speak for RoR as I have not tried CakePHP. RoR confesses to the close tie between controller and view, they are both implemented in the same subsystem (Action Pack). RoR does manage to separate the controller and view code but the close link shows through in that variables created by the controller also exist in the view. The model is totally separate. It is worth taking a look at Ruby on Rails as it does deliver on its promises to make web development faster and put the fun back into web programming. I am sure that Drupal could learn from RoR, but that doesn't mean that it would be sensible to copy everything. RoR is a a framework for creating web applications and is a layer below Drupal which is a framework for creating content managed websites with some web application stuff as well. That web application code generally works with content so the API is to the CMS content rather than directly to a database. RoR is also heavily reliant on the Ruby language so it cannot be replicated in all its glory on PHP anyway. -- Martin Tomes echo 'martin at tomes x org x uk'\ | sed -e 's/ x /\./g' -e 's/ at /@/' Visit http://www.subversionary.org/
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>
Larry Garfield wrote:
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>
Actually, thank you very much, Larry. I was getting to the point where if I heard MVC one more time in a discussion about Drupal and/or web applications, I was about the throw up. :-) Even in the Java world, MVC may be the hot buzzword of the moment, but it's not the only model in the world, and it will be replaced in the near future with some other hot model that everyone will try to use for everything. History repeats itself. Been there, seen that over and over. ..chris
Frando (Franz Heinzmann) wrote:
I think by extending the FormAPI concept to a Data API we can ease and simplify drupal module development quite a lot. By adding some more "magic", as some scaffolding here and there or considering the fAPI arrays not as description of forms but as data models, lots of things (as different methods of interacting with a website, e.g. XML-RPC or import/export modules) would be far easier to realize.
regards, frando Frando,
In a couple of adrian's messages, he's noted that the Forms API's big problem is that it is blurred with a data management API. chx and I have spent a lot of time up to our necks in form.inc during the 5.0 development cycle, and I can offer the following observations. 1) We're using structured arrays to store LOTS of information these days. I think that's a good thing, not because arrays are better than anything else but because we are settling on a standard representation for complex information (including parent/child information). Array trees, with a #key_suffix to distinguish flags and properties, works. 2) Rendering HTML with that structure works, and works pretty well. drupal_render() can be used for an awful lot of things now, and I hope we take advantage of it, completely apart from forms. 3) Forms are not data. Forms are presentation of data, and input of user data before it's massaged. In many cases, that differs from our model considerably. Making Forms API into Data API means that we bolt ourselves to a 1-1 field/column sort of relationship, or commit to ugly hacks and workarounds. In the old days, the node edit form used $_POST['edit'] to create the node object directly -- cast to an object and go! :-) It's a good thing that we've moved away from it. 4) As per adrian's suggestions, defining our data model is a task that our structured arrays could be great at. A data model can be used to auto-generate an edit form definition, which can be customized by a developer at will. It's worth noting that the programmatic form submission function that's in 5.0 is 'drupal_execute()', not 'drupal_submit_form()'... I'm hoping that as we move towards a data model that can be used in more generic fashion. To recap, I think the future lies in: Render API splatting stuff into HTML, Forms API managing roundtrip/workflow issues with HTML forms, and Data API managing data definitions and CRUD. The more time I spend working with forms, the more I drink the adrian kool-aid. ;) --Jeff
3) Forms are not data. Forms are presentation of data, and input of user data before it's massaged. In many cases, that differs from our model considerably. Making Forms API into Data API means that we bolt ourselves to a 1-1 field/column sort of relationship, or commit to ugly hacks and workarounds. In the old days, the node edit form used $_POST['edit'] to create the node object directly -- cast to an object and go! :-) It's a good thing that we've moved away from it.
I'd like to pick at this point specifically. While I agree that forcing developers into a 1:1 relationship between form elements and db columns is bad, why not start with that as a default? Given a data definition that is 1:1, Drupal could do the hard work of storing that data, leaving the programmer to work on other things. If the programmer needs something more complicated, he/she could certainly register a "#callback' on the data element which did the appropriate validation and storage. Taking this one step farther, modules could register new data definition elements, like the various field modules do right now for CCK. If the '#type' is 'foo-bar-baz', we could look up the foo-bar-baz symbol in some sort of vtable and call the appropriate function. (Forget the days of "drupal is a framework", and welcome the "drupal is a compiler" era). Again, we already have a DDL, let's use it. -M
On Wednesday 06 September 2006 11:24, Mark Fredrickson wrote:
I'd like to pick at this point specifically. While I agree that forcing developers into a 1:1 relationship between form elements and db columns is bad, why not start with that as a default? Given a data definition that is 1:1, Drupal could do the hard work of storing that data, leaving the programmer to work on other things.
[putting on Java hat] In other words, you'd like to have Hibernate in PHP. [taking off Java hat] Sorry...but if I didn't say it, someone else would. {GRIN} Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
[putting on Java hat] In other words, you'd like to have Hibernate in PHP. [taking off Java hat]
Sorry...but if I didn't say it, someone else would. {GRIN}
AKA the ActiveRecord class in RoR. This model has been done before (and done well). I would like to see Drupal selectively choose some parts of these systems to copy. -M
On 06 Sep 2006, at 5:24 PM, Mark Fredrickson wrote:
I'd like to pick at this point specifically. While I agree that forcing developers into a 1:1 relationship between form elements and db columns is bad, why not start with that as a default? Given a data definition that is 1:1, Drupal could do the hard work of storing that data, leaving the programmer to work on other things. If the programmer needs something more complicated, he/she could certainly register a "#callback' on the data element which did the appropriate validation and storage.
I agree with mark on this, the default case , which in 99.999% of the time is more than adequate, for both input AND output (forms and displays), can very very very easily be codified and not even be a concern for the developer. Using the 'fapi' structure of sensible defaults that can be overridden, you could really make it be anything. Also, 99% of the time you only need the aggregate fields on output, not input. so it would be much much cleaner to create a widget (theme function) that displays multiple fields. Like for instance a graph that can display multiple points associated associated with a node. It's one view of multiple data fields. Also, we use data models for a hell of a lot of things, We have data models re-implemented with subtle differences for a) node definitions through fapi b) cck c) importexportapi d) views e) node_import module f) probably pubsub module. and several other places. This is also about having consistent, well defined, validation rules for all inputs, which are separate from the forms. So they can be re-used more cleanly. This is also about providing context for many other systems, such as the filters, to provide a modicum of safety when doing output (ie: knowing that a 'title' field will need to be check_plain'ed, and a content field could be html and might have to have a filter selector). It's also about creating far far cleaner abstraction for things like file handling, so you can just add a file field to any 'model', and the CRUD of the file 'model' knows how to save and handle it properly. It's also about providing the place for the much needed relationship API. it's also about getting rid of the distinction between userapi and nodeapi, and instead provide a sensible place for all objects to be extended (ie: anythingapi). it's also about improving granular caching of objects, and even markup. With realistic methods for rebuilding cached objects when needed (this will lead to big performance benefits) There are at least a dozen MAJOR concerns this will allow us to cleanly and consistently resolve, and many dozens more new features we will be able to implement because of a system like this. Being against an API like this because other systems have implemented something similar before (really, what kind of a reason is that?), is incredibly incredibly short sighted. The simple fact that other people have implemented it before should be a benefit , because we have the ability to learn from their mistakes. I'll be discussing this all at DrupalCamp in Brussels in 2 weeks time, and I will be making my presentation available online too. In the mean time, if anyone would like to discuss this with me, I will be available on skype username: vertice123 If you've had experience implementing a similar system, or working with systems like RoR / CakePHP or anything similar , or have some major concerns with the idea, I would like to speak to you. I am especially interested in any forms you feel will be impossible with a system like this.
On 06 Sep 2006, at 21:22, adrian rossouw wrote:
it's also about getting rid of the distinction between userapi and nodeapi, and instead provide a sensible place for all objects to be extended (ie: anythingapi).
The API API or API^2? This is starting to look like a gang bang with a collective climax. :) But yes, you raise valid arguments.
I'll be discussing this all at DrupalCamp in Brussels in 2 weeks time, and I will be making my presentation available online too.
And we'll be video taping you from two or three different angles (http://buytaert.net/bootlegging-drupalcon-brussels) to make sure we don't miss any of the finer points. Rock on, Adrian. :) -- Dries Buytaert :: http://www.buytaert.net/
adrian rossouw wrote:
If you've had experience implementing a similar system, or working with systems like RoR / CakePHP or anything similar , or have some major concerns with the idea, I would like to speak to you. I am especially interested in any forms you feel will be impossible with a system like this.
I've implemented a PHP5 library of Active Record, Mapper and Integrated Mapper patterns, using lazy initialization. Can I play? :-) *sip*
Op woensdag 6 september 2006 21:22, schreef adrian rossouw:
There are at least a dozen MAJOR concerns this will allow us to cleanly and consistently resolve, and many dozens more new features we will be able to implement because of a system like this.
API^2 or the CGB (collective gangbang) sounds wonderfull... but... Why use Drupal as the base? Why use PHP? Why start off with a system that has a long history which stands in the way of such huge changes? Why use a programming language that is known for its horrible support of true abstraction? Yes, what I am saying is: a proper[1] from-scratch-development instead of hacking stuff into something (Drupal) that was never meant to carry all such high-level technical systems. Drupal is designed to be *simple* (not using OO, convention over configuration, simple apis) adding complex stuff to it, "just doesn't fit". To me all this FAPI/API2 feels like bolting a Jet-engine, Fly-by-wire-controls and all that, to that bycicle which has been perfect to do the shopping with! If we need more then getting our grocery, then we should not add a jet-engine to the bike, nor add complex controls, instead we'd best get ourself that plane we really need. A bike never makes a good plane, and a plane is not very suitable for your daily groceries. Bèr [1] meaning: start off with a good DB-architecture design, design all the object-relation mappings, add a pinch of modularity, boil it in the collective-cooker, and serve it with a fresh sauce. -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc Nieuwsartikelen, of weblog.: http://help.sympal.nl/nieuwsartikelen_of_weblog Written while listening to Mad_wax-vocode.com by Mad wax on electro_showcase_oct2004_DJ
Mark Fredrickson wrote:
3) Forms are not data. Forms are presentation of data, and input of user data before it's massaged. In many cases, that differs from our model considerably. Making Forms API into Data API means that we bolt ourselves to a 1-1 field/column sort of relationship, or commit to ugly hacks and workarounds. In the old days, the node edit form used $_POST['edit'] to create the node object directly -- cast to an object and go! :-) It's a good thing that we've moved away from it.
I'd like to pick at this point specifically. While I agree that forcing developers into a 1:1 relationship between form elements and db columns is bad, why not start with that as a default? Given a data definition that is 1:1, Drupal could do the hard work of storing that data, leaving the programmer to work on other things. If the programmer needs something more complicated, he/she could certainly register a "#callback' on the data element which did the appropriate validation and storage.
I would argue, instead, that we really should do a good object model of what objects Drupal is handling, and then at a base level map form elements to object attributes. Below that, the database layer translates the objects into tables. (No, users are not nodes. :-) ) We optimize object and SQL handling significantly and keep those darn hack module developers from mucking up the database and beautiful APIs. :-) (tongue very in cheek!) /me drinks some more Adrian Kool-Aid... ..chrisxj
On 03 Sep 2006, at 3:40 PM, 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
I've been going through the phpcake source and docs recently, preparing for my brussels presentation. I haven't actually gotten around to installing rails yet, but I am definitely keeping my eyes open as to how best to implement this.
On 9/3/06, Frando (Franz Heinzmann) <frando@xcite-online.de> wrote:
I think by extending the FormAPI concept to a Data API we can ease and simplify drupal module development quite a lot. By adding some more "magic", as some scaffolding here and there or considering the fAPI arrays not as description of forms but as data models, lots of things (as different methods of interacting with a website, e.g. XML-RPC or import/export modules) would be far easier to realize.
The Import / Export API module (my Summer of Code project - <http://drupal.org/project/importexportapi>) goes some way towards achieving this. A big part of the module is its "data definition" system, which allows any entity within Drupal to be represented as a structured array. This is basically a "data API", and it is certainly a candidate for how we could implement a "model" layer in core. My implementation of a data model is a bit different to the examples that Adrian has given, but I think that the general direction is the same. My work probably contains a lot of stuff that is specific to data models for import/export, which won't be necessary in core. Hopefully we'll be able to take the best of everyone's ideas, when it comes time to actually coding the data model layer that will (most likely) form the new foundation of FAPI 3.0. Oh, wait... I mean, DAPI... whatever :P Cheers, Jaza.
participants (14)
-
adrian rossouw -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Dries Buytaert -
Frando (Franz Heinzmann) -
Jeff Eaton -
Jeremy Epstein -
Khalid B -
Larry Garfield -
Mark Fredrickson -
Martin Tomes -
Metzler, David -
Syscrusher