Op donderdag 31 mei 2007, schreef Boris Mann:

Yes, there is currently no way to do CRUD with CCK stuff. And it hurts install profiles. So, making the CRUD bits with CCK happen will enable this for modules AND let you also create on-the-fly node stuff in install profiles.

Part of this is already implemented in my probably-never-to-be-released-because-too-litle-quality-time flexinode2, the superceder of CCK. Baked right into the core of it, in fact. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

Op donderdag 31 mei 2007, schreef Wim Leers:

flexinode 2? ***the superceder of CCK***?

Is there some place I can read up on this? I wasn't aware of this at   all!

Its nothing official. And nothing big either. In short: Don't get nervous. CCK will prolly keep existing. This is just a personal itch. My idea: * Flexinode has a crappy database model. * CCK has a crappy code/hook model, lacks many features, has many dirty-hacked-on additions etc. Both have bad sides. I consider both to be in such a bad state righ now, that I no longer use any of them. And advice my clients not to use them either. I want to move flexinode along, so that this time both the DBA /and/ the code /and/ the usability /and/ the interface is done right. If my ideas are right, and If I get this off the ground, and if if if if, then either an upgrade path for CCK to this thing will come, or else CCK will simply keep existing. And I have been on this for a long while. Doing the coding and architecturing in my few free hours. some notes and ideas on my blog: http://webschuur.com/projects/flexinode Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

On 6/4/07, David Metzler <metzlerd@metzlerd.com> wrote:

And speaking of itches, I've always been a little bothered by the fact that flexinode and CKK store there data in generic tables. .

In this approach, adding fields would execute DDL not DML for the storage mechanism.

So my question is, has this been considered?

My feeling and recollection (which may be completely wrong) was that DDL was avoided long ago because often the webserver's database username did not have table create/alter privileges. At some hosting companies, this is still the case, and for good reason: it provides better security and accountability. But since we now have a self-installing database schema and lots of other DDL statements, perhaps the aversion to such as use of DDL is not so strong. I'm in general agreement with you. Except in specific instances, I really don't like serialized data (another technique used for avoiding DDL) and generic tables in an application where the database is one of the primary bottlenecks.

You're creating a new flexinode to replace CCK? That really makes me nervous - going from flexinode to CCK the first time was a pain in the ass because there was no easy upgrade path. Why not just fix CCK instead of pushing people back and forth? Or am I misinterpreting you? Right now I'm pretty happy with CCK and the modules that work with it and I don't relish the idea of ditching that. Bèr Kessels wrote:

Op donderdag 31 mei 2007, schreef Bèr Kessels:

...

Part of this is already implemented in my probably-never-to-be-released-because-too-litle-quality-time flexinode2, the superceder of CCK. Baked right into the core of it, in fact.

wrong quote. This was not reply to CRUD, but to the idea of letting modules define content types (and fields).

The crud is somthing that is already in flexinode1, so it will be in 2 too.

Bèr

-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com

On 31 May 2007, at 8:31 PM, Mark Fredrickson wrote:

Unfortunantely, a lot of the CCK field adding, updating, removing, etc is tied up in form submission right now. In fact, the content_copy.module import is basically just mocking up drupal forms and submitting them programmatically. This is not to say a CRUD API couldn't be written, just that I've been down that road before, and I it wasn't fruitful. :-(

So? export the default_values of the form array structure to the $module_content_fields($type) function. I bet fquery could really useful for this. And instead of doing that code in the install profile, by hand, you just enable the module. Which has it's own .install which just recurs through the exported data in the $module_content_fields($type) hook, for each $type that the module defines. Ideally we'd need to hook into the forms for the validation and especially the code that creates the tables any way.

For the SonyBMG project that Lullabot put together, we had to build a profile that created close to a dozen CCK types at install time, added fields, etc. It works, but there are a lot of application- specific hacks that had to be done to make it work well with the current system. content_copy.module is useful but extremely, EXTREMELY brittle. There are lots of ways to make it break. There are even more ways to make it break when you're trying to automate it. Modules that add fields to the content type admin screen can break it too. I would go so far as to say that it is a solution for those who need to *record their current configuration options*, NOT a tool for actual site provisioning. That is in no way a knock on those who developed it -- the CCK internals it's working with are thorny and not meant to be used in this way. I just want to warn anyone who thinks it'd be a quick tweak that things are not what they seem. For the idea to be a reality, CCK needs actual honest-to-goodness granular CRUD functions underneath the surface, and any forms it uses for configuration purposes need to call those CRUD functions instead of overloading the validate and submit handlers. We also need to hash out what happens when Field plugins change their settings definitions, etc, what happens when the in-module definition for a content type changes, etc. Right now it only works for the creation of new node types from scratch. --Jeff On May 31, 2007, at 1:48 PM, Sean Robertson wrote:

Can you do this now with drupal_execute? How about actions?

adrian rossouw wrote:

...

I was thinking it would be cool if we could have a way for CCK node types to be defined by modules. The same way that modules can provide default views. A quick way to do this would be to just have a module that generates a module for node types, generating the .info, and the .install .. and probably a dummy .module. this could really help with install profiles.

On 31 May 2007, at 8:48 PM, Sean Robertson wrote:

Can you do this now with drupal_execute? How about actions?

yeah. i can't see a reason why it can't be done now. Actions should be possible too, but you'd have to introduce a couple more hooks. Also. i wonder how updating would work. Removing fields could be weird.