Paving the way for CCK, intentionaly without CCK
Hi, Reading through all the development focus discussion and Dries' blog, what I see would be doable to target is an incremental process to pave the way for CCK, preparing for a possible 4.8 without CCK, but with the basic offering it would bring us. Dries outlines some needs for CCK like install profiles, dependency system. My simplified route proposal would not require these for 4.8, but still would offer great flexibility in how we can use the built in views of Drupal. 1. NCI (node cloning interface), for cloning node into book, forum, page, story, blog types (and any other the user desires). I imagine a simple interface at administer / settings / content types, where one can add another simple node type, provide a name and description, and that is it. This should be enough for the built in simple types, and should be forwards compatible for CCK. If CCK will not make it, this simple NCI feature could still be in place. 2. Abstract the view part of forums, book, blog, so that any node type can be added to a forum, a book or a blog equaly easily. This should be done regardless of taking the intermediary NCI setup, or going right to CCK. The point of this mail mainly is that we should go the NCI step first, and see if CCK can make it for the release. If not, the real end user advantage is still going to be there, being the possible addition of new content types (and losing the hassle of choosing between page and story for newcomers). Being able to push other types of content to blog or forum is a long awaited feature, at least one special forum module was developed for this very reason. Book allows us to add any type, but it is quite hard to add non-book node types to forums, not as easy as assigning a path alias (it should be that easy). So what do I see is that people can work on the blog/forum/book view abstraction in preparation for NCI or CCK, and we can add NCI as an intermediary feature (or a final one CCK being a contrib module extending it for the time being). This would greatly reduce bloat, and I am sure NCI would take a lot less code (and support :) then what is required now to support story, page, book, forum and blog. It would also be the most painless route to take to abstract the built in views, but still would pave the way for CCK a great amount, providing a much lower footprint solution for those not needing CCK goodness. IMHO core node types need no CCK to function. Attachments and path aliases are great node addons, polls can be retargeted as such, book outlining, forum and blog association can be retargeted as such, so what is left are only simple basic node types, which can be created with NCI. I strongly beleive that instead of taking another revenge on core with the introduction of CCK, a quick and smooth 4.8 transition would be possible with NCI, which takes one of the most important steps to pave the way for CCK, but still does not need a major overhaul of how nodes are done (it is not a heart transplant as opposed to how Dries explained CCK in his blog). Goba
On Thu, 2006-05-04 at 08:25 +0200, Gabor Hojtsy wrote:
1. NCI (node cloning interface), for cloning node into book, forum, page, story, blog types (and any other the user desires). I imagine a simple interface at administer / settings / content types, where one can add another simple node type, provide a name and description, and that is it. This should be enough for the built in simple types, and should be forwards compatible for CCK. If CCK will not make it, this simple NCI feature could still be in place.
I have actually developed something like this. It allows you to take any of the core node types and clone them. I have added it to my sandbox. sandbox/gordon/cloneanode See what you thing. Gordon.
Gordon Heydon wrote:
On Thu, 2006-05-04 at 08:25 +0200, Gabor Hojtsy wrote:
1. NCI (node cloning interface), for cloning node into book, forum, page, story, blog types (and any other the user desires). I imagine a simple interface at administer / settings / content types, where one can add another simple node type, provide a name and description, and that is it. This should be enough for the built in simple types, and should be forwards compatible for CCK. If CCK will not make it, this simple NCI feature could still be in place.
I have actually developed something like this. It allows you to take any of the core node types and clone them.
I have added it to my sandbox.
sandbox/gordon/cloneanode
See what you thing.
Ah, this seems to be more then what we need (so it is going to be a nice contrib module :). Your cloneanode module actually wraps nodeapi calls, so that it bridges every type of call to the original function. NCI would not do this, since it would only deal with built in node functionality, which is already handled, so no need to tap into nodeapi. I will see when I can look into this. Goba
another simple node type, provide a name and description, and that is it.
We already have the code.http://drupal.org/node/29794 I will work on it. Regards NK
On 5/4/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
1. NCI (node cloning interface), for cloning node into book, forum, page, story, blog types (and any other the user desires). I imagine a simple interface at administer / settings / content types, where one can add another simple node type, provide a name and description, and that is it. This should be enough for the built in simple types, and should be forwards compatible for CCK. If CCK will not make it, this simple NCI feature could still be in place.
Makes sense to me, as long the changes are not too intrusive. Well, they can be intruisive as long they align with the CCK's needs. Karoly's old patch might be a good starting point. -- Dries Buytaert :: http://buytaert.net/
On 04 May 2006, at 08:25, Gabor Hojtsy wrote:
1. NCI (node cloning interface), for cloning node into book, forum, page, story, blog types (and any other the user desires). I imagine a simple interface at administer / settings / content types, where one can add another simple node type, provide a name and description, and that is it. This should be enough for the built in simple types, and should be forwards compatible for CCK. If CCK will not make it, this simple NCI feature could still be in place.
Karoly did some work on this: http://drupal.org/node/29794. Please, take "usability notes" as you play with the functionality introduced by Karoly's patch. -- Dries Buytaert :: http://www.buytaert.net/
Karoly did some work on this: http://drupal.org/node/29794.
Some. Let's never forget that the code is JonBob's. I only did a delete :)
I like Gabor's proposal very much. This simplifies core by eliminating page, blog, and story modules, and allowing the user to call their node anything (article, post, ...etc.) One thing about CCK scares me, and it is the same the reason that I stayed away from flexinode: scalability. The number of joins in flexinode can become expensive performance-wise. In Vancouver in February we had a discussion on this, and there were two options on how to store the data for CCK. Haven't checked the code lately though, so this may have been addressed. This core feature can stay, even if CCK makes it to core in the future. +1 for this.
Khalid B wrote:
In Vancouver in February we had a discussion on this, and there were two options on how to store the data for CCK. Haven't checked the code lately though, so this may have been addressed.
CCK stores node data in the cache, so it only needs to do the joins very occasionally.
one of the most useful things about PHPTemplate is the template.php file. One of the most useful things about template.php is the _phptemplate_variables. Why don't we extend this to be a module hook that lets module access the variable stack prior to being sent to any template? This would solve the problem that I ran into in page_title.module where the module is dependent on an alteration to the _phptemplate_variables function.
On 06 May 2006, at 10:43 AM, Robert Douglass wrote:
one of the most useful things about PHPTemplate is the template.php file. One of the most useful things about template.php is the _phptemplate_variables. Why don't we extend this to be a module hook that lets module access the variable stack prior to being sent to any template? This would solve the problem that I ran into in page_title.module where the module is dependent on an alteration to the _phptemplate_variables function. This would be accomplished by moving the phptemplate template loading code into core. In fact, this was part of my original design for the template system. The _variables function is also the prototype of the _infinitely_ useful _form_alter hook.
It could be really useful to have any module expose extra things that can be placed in template. Like the privatemsg module could expose the 'message this user' link to any template that has a $user object =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
participants (8)
-
Adrian Rossouw -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Gordon Heydon -
Karoly Negyesi -
Khalid B -
Robert Douglass