Including the CCK in core is an important goal and something I support strongly. So I played some more with the CCK today, and before it can be considered for inclusion, we need to: 1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary. 2. Creating a new content type is a multi-step process. Improving and extending the Forms API to make it easier to build wizards would be of tremendous help to get the CCK in core (but not strictly necessary). Improving the user experience when creating node types, however, is necessary to get CCK in core. 3. Figure out a way to migrate existing node types to the CCK. Summary: it is too early to consider including the CCK in core. To help get the CCK into core, we should focus on Forms API improvements, a dependency system, an install system, wizards, etc. -- Dries Buytaert :: http://www.buytaert.net/
On 03 May 2006, at 8:41 AM, Dries Buytaert wrote:
1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary. I'm working on it, with the new dependencies module.
One of the things i really want to do is create 'library' packages. Which are modules which don;t have to be enabled or disabled, they are just enabled as needed. Removing all that clutter from the interface. Meaning you only have to enable the content module. Another example of this would be all required core modules, and the views module (as opposed to views_ui).
2. Creating a new content type is a multi-step process. Improving and extending the Forms API to make it easier to build wizards would be of tremendous help to get the CCK in core (but not strictly necessary). Improving the user experience when creating node types, however, is necessary to get CCK in core.
I've been thinking about this too, and I think continuations are likely the best way to do this. CCK however forms part of what I would like to see FAPI 2.0 become. Including merging the rendering of nodes and forms. Part of FAPI 2.0 is to solve the wizard problem, and due to the nature of the current FAPI (the merged model and view array), it becomes harder than it needs to be to break forms onto multiple pages, and could lead to very crufty code. I will be writing a proper in depth description on FAPI after I finish with dependencies. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 5/3/06, Adrian Rossouw <adrian@bryght.com> wrote:
On 03 May 2006, at 8:41 AM, Dries Buytaert wrote:
1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary. I'm working on it, with the new dependencies module.
So, will there be anything that the dependencies module depends upon? :-p Seriously, though - is it a good idea to put the dependency system into a module? I would have thought that it belongs in a .inc file (e.g. module.inc), since it will need to be available before any of the module-loading-and-checking stuff happens in a Drupal bootstrap. Jeremy Epstein GreenAsh Services www.greenash.net.au
On 03 May 2006, at 2:47 PM, Jeremy Epstein wrote:
So, will there be anything that the dependencies module depends upon? :-p
Seriously, though - is it a good idea to put the dependency system into a module? I would have thought that it belongs in a .inc file (e.g. module.inc), since it will need to be available before any of the module-loading-and-checking stuff happens in a Drupal bootstrap.
This is just for contrib at the moment =) I am developing it as a .inc , and a replacement for the admin/ modules page that uses the new api. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Dries Buytaert wrote:
Including the CCK in core is an important goal and something I support strongly. So I played some more with the CCK today, and before it can be considered for inclusion, we need to:
1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary.
I don't think adding more required modules should happen. Would it be workable to start with patching node.module to allow multiple content types and remove page/story (with upgrade path, etc)? -- Neil Drumm http://delocalizedham.com/
On 03 May 2006, at 12:15, Neil Drumm wrote:
Including the CCK in core is an important goal and something I support strongly. So I played some more with the CCK today, and before it can be considered for inclusion, we need to: 1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary.
I don't think adding more required modules should happen.
Would it be workable to start with patching node.module to allow multiple content types and remove page/story (with upgrade path, etc)?
I'm not sure it would be workable, but it certainly sounds desirable. (Then again, didn't chx came up with a patch to do exactly this?) -- Dries Buytaert :: http://www.buytaert.net/
I'm not sure it would be workable, but it certainly sounds desirable. (Then again, didn't chx came up with a patch to do exactly this?)
Dries Buytaert :: http://www.buytaert.net/
chx did came up with such a patch. But: #44 submitted by Dries on September 18, 2005 - 19:21 Just like Jose, I'm not convinced automatically enabling modules is a good thing. http://drupal.org/node/18447#comment-45058 Regards NK
On 03 May 2006, at 13:53, Karoly Negyesi wrote:
I'm not sure it would be workable, but it certainly sounds desirable. (Then again, didn't chx came up with a patch to do exactly this?)
chx did came up with such a patch. But:
#44 submitted by Dries on September 18, 2005 - 19:21
Just like Jose, I'm not convinced automatically enabling modules is a good thing.
That's a different issue. The patch I was referring to was the one to eliminate some of the core node types. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 03 May 2006, at 12:15, Neil Drumm wrote:
Including the CCK in core is an important goal and something I support strongly. So I played some more with the CCK today, and before it can be considered for inclusion, we need to: 1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary.
I don't think adding more required modules should happen.
Would it be workable to start with patching node.module to allow multiple content types and remove page/story (with upgrade path, etc)?
I'm not sure it would be workable, but it certainly sounds desirable. (Then again, didn't chx came up with a patch to do exactly this?)
I posted some code for this (just a proof of concept, not some usable functionality with an UI). Chx might have made a patch out of it. There was a direction to add this "basic node type cloning" feature into core, and get rid of page/story and the node type code of blog/forum (all these four are in fact the same basic node type) Then support CCK as much as possible, but not in core. I am unsure whether this direction was voted down, I myself would still prefer this way. Additionaly CCK would probably have more space to breathe in contrib. Gabor
On Wed, 2006-05-03 at 21:16 +0200, Gabor Hojtsy wrote:
Dries Buytaert wrote:
On 03 May 2006, at 12:15, Neil Drumm wrote:
Including the CCK in core is an important goal and something I support strongly. So I played some more with the CCK today, and before it can be considered for inclusion, we need to: 1. Figure out a way to make it easy to install the CCK. Having to enable 5-10 modules is annoying. Having a better install system, with a build in dependency tracker, seems necessary.
I don't think adding more required modules should happen.
Would it be workable to start with patching node.module to allow multiple content types and remove page/story (with upgrade path, etc)?
I'm not sure it would be workable, but it certainly sounds desirable. (Then again, didn't chx came up with a patch to do exactly this?)
I posted some code for this (just a proof of concept, not some usable functionality with an UI). Chx might have made a patch out of it. There was a direction to add this "basic node type cloning" feature into core, and get rid of page/story and the node type code of blog/forum (all these four are in fact the same basic node type) Then support CCK as much as possible, but not in core. I am unsure whether this direction was voted down, I myself would still prefer this way. Additionaly CCK would probably have more space to breathe in contrib.
Gabor
Still would need some sort of render with 'template' selector. I find I theme pages and story's very differently.
On 04 May 2006, at 6:37 AM, Darrel O'Pry wrote:
Still would need some sort of render with 'template' selector. I find I theme pages and story's very differently.
you mean node-<type>.tpl.php ? -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Okies I get it now... my pain killers are clouding my comprehension. On Thu, 2006-05-04 at 13:59 +0200, Adrian Rossouw wrote:
On 04 May 2006, at 6:37 AM, Darrel O'Pry wrote:
Still would need some sort of render with 'template' selector. I find I theme pages and story's very differently.
you mean node-<type>.tpl.php ?
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
participants (7)
-
Adrian Rossouw -
Darrel O'Pry -
Dries Buytaert -
Gabor Hojtsy -
Jeremy Epstein -
Karoly Negyesi -
Neil Drumm