One thing that bothered me for a while is that we almost moved from hook_foo() to foo_nodeapi(), but never completely did so. In some cases we use foo_view(), in others we have a foo_nodeapi() with a switch/case for $op 'view'. I find this to be often inconsistent and confusing. Are there any plans to totally eliminate foo_hook() in favor of nodeapi as we have discussed at one point?
On May 6, 2006, at 3:38 PM, Khalid B wrote:
One thing that bothered me for a while is that we almost moved from hook_foo() to foo_nodeapi(), but never completely did so.
In some cases we use foo_view(), in others we have a foo_nodeapi() with a switch/case for $op 'view'.
They mean different things. Use foo_view() if foo.module defines a node type, and wants to define its presentation. Use foo_nodeapi('view') if foo.module doesn't define a node type, but wants to alter the presentation of all nodes. I don't have a big problem with making the API consistent for these, but we need to realize that they are not interchangeable as it stands.
If the module defines a node type, we can still use nodeapi('view'), and check $node->type = 'mytype' and do whatever we would do in the mytype_view() hook. Or am I missing something? On 5/6/06, Jonathan Chaffer <jchaffer@structureinteractive.com> wrote:
On May 6, 2006, at 3:38 PM, Khalid B wrote:
One thing that bothered me for a while is that we almost moved from hook_foo() to foo_nodeapi(), but never completely did so.
In some cases we use foo_view(), in others we have a foo_nodeapi() with a switch/case for $op 'view'.
They mean different things.
Use foo_view() if foo.module defines a node type, and wants to define its presentation.
Use foo_nodeapi('view') if foo.module doesn't define a node type, but wants to alter the presentation of all nodes.
I don't have a big problem with making the API consistent for these, but we need to realize that they are not interchangeable as it stands.
Khalid B wrote:
If the module defines a node type, we can still use nodeapi('view'), and check $node->type = 'mytype' and do whatever we would do in the mytype_view() hook.
Or am I missing something?
Order of operations. If you just use nodeapi, it's hard to tell where exactly yours will come, even though you own the module. If you use foo_hook() you know yours is the only one using that, so you know exactly what order they'll happen in -- nodeapi will either come before or after you, completely.
On 5/7/06, Khalid B <kb@2bits.com> wrote:
Are there any plans to totally eliminate foo_hook() in favor of nodeapi as we have discussed at one point?
When CCK is developed to its full potential, and gets into core, we may find that it's no longer practical for modules to define their own node types. Instead, the majority of modules may move to a model of extending other node types by using nodeapi (think event module). In this case, we may end up getting rid of module-defined node types (as we know them) altogether, and thus getting rid of all the node hooks except for nodeapi. All of this 'may' happen - then again, it 'may not'. :-p Cheers, Jaza.
On 07 May 2006, at 4:14 AM, Jeremy Epstein wrote:
All of this 'may' happen - then again, it 'may not'. :-p
node type modules are dead! long live node types.! -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Sunday 07 May 2006 01:33, Adrian Rossouw wrote:
On 07 May 2006, at 4:14 AM, Jeremy Epstein wrote:
All of this 'may' happen - then again, it 'may not'. :-p
node type modules are dead! long live node types.!
This seems to echo the "why make nodes when you've got flexinode" idea that was floated a while back. The answer then and now being "because sometimes I don't want my data's definition and structure in the database, I want it in code where I don't have to do everything twice between a beta site and live site." Unless there's going to be some way to resync node field changes from a beta site to live site as easily as uploading a new version of a module, let's not get rid of "classic" nodes completely. -- 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
Larry Garfield wrote:
This seems to echo the "why make nodes when you've got flexinode" idea that was floated a while back. The answer then and now being "because sometimes I don't want my data's definition and structure in the database, I want it in code where I don't have to do everything twice between a beta site and live site."
Unless there's going to be some way to resync node field changes from a beta site to live site as easily as uploading a new version of a module, let's not get rid of "classic" nodes completely.
As I've been doing more of my work for actual, professional sites, I've realized that database dependency on data can be damaging for a site of that kind. It made me extremely glad that I did Views the way I did; as I understand it, CCK will follow the same model, where modules can specify their fields and default node types to support those fields, so that ideally none of that will NEED to be in the database. Not entirely sure how far JonBob's been planning to go with that model, of course.
On Sunday 07 May 2006 16:23, Earl Miles wrote:
Unless there's going to be some way to resync node field changes from a beta site to live site as easily as uploading a new version of a module, let's not get rid of "classic" nodes completely.
As I've been doing more of my work for actual, professional sites, I've realized that database dependency on data can be damaging for a site of that kind. It made me extremely glad that I did Views the way I did; as I understand it, CCK will follow the same model, where modules can specify their fields and default node types to support those fields, so that ideally none of that will NEED to be in the database. Not entirely sure how far JonBob's been planning to go with that model, of course.
I don't know either, but it would be a really good idea. I rather like the way Views does that. It takes a while to wrap your head around, but once you do, it makes a lot of sense. -- 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
On 5/7/06, Larry Garfield <larry@garfieldtech.com> wrote:
This seems to echo the "why make nodes when you've got flexinode" idea that was floated a while back. The answer then and now being "because sometimes I don't want my data's definition and structure in the database, I want it in code where I don't have to do everything twice between a beta site and live site."
Here is an idea: I would call "portable node definitions". This can be some sort of predefined node data that would make a fresh site have the new node types. These can be some sort of metadata file, and can be as simple as some PHP code that does that, or can be Yet Another Metadata Proposed Format. This way, instead of having a classified or job search module, we would have a metafile for each, and that is it.
I was VERY skeptical about the CCK-driven future. I had a chat with JonBob about his 'vision' for the new system, and if I understand it correctly, he's working towards something like this: CCK 'field types' are specific kinds of data, like URLs or images or large blocks of text or numbers or dates. CCK 'widgets' are UI elements that edit those pieces of data (like a dropdown list of user accounts) CCK 'content types' are defined collections of fields, with the settings regarding which widgets should be used to edit them. (One field type may support numerous different editing widgets for different UI needs) Aggressive use of caching would reduce the performance hit for loading content types defined in this way, just as caching today speeds up the loading of node types that have many corollary tables added via nodeapi. A module that defines a new content-type would just expose a blurb of metadata that describes the content type in terms of fields, widgets, etc. If it needed special kinds of fields or widgets, it would implement those as needed. This would be a lot like views.module, and how it handles custom data, custom field definitions, etc. Modules would still be able to expose custom handling code to impose additional validation rules, post-processing, etc. But a world of additional possibilities would open up; users who need a custom field or two would be able to simple *add* those fields to 'blog' or 'page' using the CCK infrastructure. No custom code needed. I'm probably not explaining it very well, but after my conversation with him, I was convinced. I think it has a LOT of potential. --Jeff -----Original Message----- From: Khalid B [mailto:kb@2bits.com] Sent: Sunday, May 07, 2006 5:43 PM To: development@drupal.org Subject: Re: [development] hook_foo() vs. nodeapi On 5/7/06, Larry Garfield <larry@garfieldtech.com> wrote:
This seems to echo the "why make nodes when you've got flexinode" idea
that was floated a while back. The answer then and now being "because
sometimes I don't want my data's definition and structure in the database, I want it in code where I don't have to do everything twice between a beta site and live site."
Here is an idea: I would call "portable node definitions". This can be some sort of predefined node data that would make a fresh site have the new node types. These can be some sort of metadata file, and can be as simple as some PHP code that does that, or can be Yet Another Metadata Proposed Format. This way, instead of having a classified or job search module, we would have a metafile for each, and that is it.
I've been working on the code to export/import and define module types for CCK. http://drupal.org/node/58153 My solution has been to simply serialize the content type object and then unserialize and import just as if the user were creating a new node type. Modules could invoke content_import_type() during hook_install to add their content types (by simply storing the serialized string in code). It's not entirely working yet, but it is on the way. -Mark On May 7, 2006, at 6:17 PM, Jeff Eaton wrote:
A module that defines a new content-type would just expose a blurb of metadata that describes the content type in terms of fields, widgets, etc. If it needed special kinds of fields or widgets, it would implement those as needed. This would be a lot like views.module, and how it handles custom data, custom field definitions, etc. Modules would still be able to expose custom handling code to impose additional validation rules, post-processing, etc. But a world of additional possibilities would open up; users who need a custom field or two would be able to simple *add* those fields to 'blog' or 'page' using the CCK infrastructure. No custom code needed.
On 08 May 2006, at 1:17 AM, Jeff Eaton wrote:
CCK 'field types' are specific kinds of data, like URLs or images or large blocks of text or numbers or dates. CCK 'widgets' are UI elements that edit those pieces of data (like a dropdown list of user accounts) CCK 'content types' are defined collections of fields, with the settings regarding which widgets should be used to edit them. (One field type may support numerous different editing widgets for different UI needs)
And I want to build on that for FAPI 2.0 You define the fields that are in your form, then you place the widgets where you want them in the form structure (ie: add fieldsets, tables, etc). Apart from the database backend that cck provides, all the validation and rounding and all that would be re-usable by fapi. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 08 May 2006, at 1:17 AM, Jeff Eaton wrote:
I'm probably not explaining it very well, but after my conversation with him, I was convinced. I think it has a LOT of potential.
And then there's the nodereference type in cck. Which if you look closely _is_ the generalised relationship API we've been saying we needed forever. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian wrote:
The install system will be capable of installing cck node types. and workflows. and cck field types.
And
Apart from the database backend that cck provides, all the validation and rounding and all that would be re-usable by fapi.
And
And then there's the nodereference type in cck. Which if you look closely _is_ the generalised relationship API we've been saying we needed forever.
Oh my ... Thank you Adrian ... this is really cool.
On 08 May 2006, at 12:42 AM, Khalid B wrote:
This way, instead of having a classified or job search module, we would have a metafile for each, and that is it.
The install system will be capable of installing cck node types. and workflows. and cck field types. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Yes, something like that. I the end the nodetypes and cck differ mainly in where do you make a cut in the drupal "type system". What are your "atomic" types?
On 10 May 2006, at 7:29 PM, James Walker wrote:
All of this 'may' happen - then again, it 'may not'. :-p
my vision is that I have no vision!
It's like the blind leading the clueless. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
All of this 'may' happen - then again, it 'may not'. :-p
my vision is that I have no vision!
It's like the blind leading the clueless.
I am quoting Gerhard from another thread, quoting Helmut Schmidt "Those who have visions should seek a doctor ..."
participants (10)
-
Adrian Rossouw -
drupal -
Earl Miles -
James Walker -
Jeff Eaton -
Jeremy Epstein -
Jonathan Chaffer -
Khalid B -
Larry Garfield -
Mark Fredrickson