The last few projects I've worked on have called for a few enhancements to profile.module, and I was wondering if it would be worth submitting patches for consideration in Drupal 6, or whether profile.module will even survive that long :) The updates to profile module will be useful for supporting OpenID attribute exchange, as well as general data integrity of profile data. And it doesn't break any of the previous functionality. New features: - multiple-select lists (took the easy way out and stored as serialized data could be improved to store the data in normalized tables) - key=>value mapping for select lists - data validation for each field (eg. email, numbers, strings, postal code) - complex data types (eg. address: street, city, state, etc) (this is not as important as the previous ones but may be useful for some people) -Rowan
Rowan Kerr wrote:
The last few projects I've worked on have called for a few enhancements to profile.module, and I was wondering if it would be worth submitting patches for consideration in Drupal 6, or whether profile.module will even survive that long :)
We need something that lets people extend Drupal's user profiles inside core. It doesn't have do be the current module but I don't see any competitor.
The updates to profile module will be useful for supporting OpenID attribute exchange, as well as general data integrity of profile data.
That sounds nice.
And it doesn't break any of the previous functionality.
That's nice too, but not strictly required as long as people's data is preserved.
New features: - multiple-select lists (took the easy way out and stored as serialized data could be improved to store the data in normalized tables)
I really hate serialized data, so an improvent would be welcome, if possible.
- key=>value mapping for select lists
- data validation for each field (eg. email, numbers, strings, postal code)
- complex data types (eg. address: street, city, state, etc) (this is not as important as the previous ones but may be useful for some people)
Maybe the more complicated stuff could live in a contrib module? Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication. Cheers, Gerhard
Gerhard Killesreiter wrote:
Rowan Kerr wrote:
New features: - multiple-select lists (took the easy way out and stored as serialized data could be improved to store the data in normalized tables)
I really hate serialized data, so an improvent would be welcome, if possible.
- key=>value mapping for select lists
- data validation for each field (eg. email, numbers, strings, postal code)
- complex data types (eg. address: street, city, state, etc) (this is not as important as the previous ones but may be useful for some people)
Maybe the more complicated stuff could live in a contrib module?
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
Yes, this is exactly what comes to mind when we talk about data validation, complex widgets, etc. Gabor
Not only that, but it also gives an entirely new look to the tired "users as nodes" discussion. If users are not, at least their profiles can be. ----- Original Message ----- From: "Gabor Hojtsy" <gabor@hojtsy.hu> To: <development@drupal.org> Sent: Thursday, February 01, 2007 7:49 PM Subject: Re: [development] Profile module for D6 [...]
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
Yes, this is exactly what comes to mind when we talk about data validation, complex widgets, etc.
Gabor
On 1-Feb-07, at 1:43 PM, Gerhard Killesreiter wrote:
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
On Feb 1, 2007, at 1:29 PM, Rowan Kerr wrote:
On 1-Feb-07, at 1:43 PM, Gerhard Killesreiter wrote:
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
I recently upgraded jjeff's excellent bio module and added this capability. What it does is allow the use of any content type as something that represents a profile, supplying its own content type by default. The default node type is just a node.module-supplied title+body nodetype. It takes very little code to do this, and could handily obviate profiles. Now, the one thing you give up is the per-field permission settings (which were a little crufty anyway IMO). I'd be an advocate of trying to re-introduce this type of access on a node level instead. The challenge, of course, is that there's no consistent mechanism for seeing which fields are on a node and where they came from (cck? nodeapi? its own module?). If this issue can be addressed then it would be trivially easy to use nodes as profiles (well, easy except for the endless debating) I think Jeff's original intent was to keep user/profile presentation separate from bio presentations, but profiles-as-nodes is just too handy to give up! Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
Now, the one thing you give up is the per-field permission settings (which were a little crufty anyway IMO). I'd be an advocate of trying to re-introduce this type of access on a node level instead.
There is a cck field permission module, but I have not tried it. Wouldn't that be the right direction for this? -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Per field permissions are an absolute requirement for several of our sites. When you deal with groups from multiple national governments, people sometimes get paranoid about which information they share with whom. ;-)
Chris Johnson wrote:
Per field permissions are an absolute requirement for several of our sites. When you deal with groups from multiple national governments, people sometimes get paranoid about which information they share with whom. ;-)
both steven and i have written profile privacy modules. i don't see this as part of core, just like node access modules are not in core.
Agreed -- I don't see the actual feature as part of core. But core development which would make those profile privacy modules non-functional would be a Bad Thing. ;-)
Op donderdag 1 februari 2007 20:29, schreef Rowan Kerr:
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
There is an excellent aand working (yet rough on the egdes) project for this. It works in 4.7. Works well, but needs love to get the ruogh edges polished. http://more.zites.net/ http://groups.drupal.org/profiles-as-nodes http://drupal.org/project/nodeprofile http://drupal.org/project/nodefamily http://drupal.org/project/usernode As said: its fine for developers, but too rough for Joe Schmoe still. It is a very good start though, especially because it allows complex stuff (like the one I am working on now, LDAP profile integration) in rather easy ways: we have all the node hooks and apis... for free. ber -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
No. There is not enough time. Examples: the installer took years to finish and form API was eight months of damned hard work. The new menu system will be about four-five months -- do not forget that I had a skeleton in Brussels (and it was more than proof-of-concept shortly after) and I started on the real thing well before the freeze and still I will be happy if everything will be together before the end of March. Based on the change data API would require, if you starting coding Adrian's data API _right now_ with a speed that would put the split-finger operators of GiTS to shame then you might make Drupal 7. Otherwise even Drupal 7 is out of question. Regards, NK
On 2/1/07, Karoly Negyesi <karoly@negyesi.net> wrote:
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
No. There is not enough time. Examples: the installer took years to finish and form API was eight months of damned hard work. The new menu system will be about four-five months -- do not forget that I had a skeleton in Brussels (and it was more than proof-of-concept shortly after) and I started on the real thing well before the freeze and still I will be happy if everything will be together before the end of March.
Based on the change data API would require, if you starting coding Adrian's data API _right now_ with a speed that would put the split-finger operators of GiTS to shame then you might make Drupal 7. Otherwise even Drupal 7 is out of question.
Regards,
NK
What Karoly is saying is something I observed: every long thread recently has alluded to the "CCK in core" wish that many of us would like to see. An example is the user profile thread by Rowan, and the replies in it just today, and many others before it. Karoly is quoting past precedence on how long it takes things to mature and make it into core, and is of the opinion that cck in core will not be ready for D6. Anyone willing to take up the challenge and prove him wrong? -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 02 Feb 2007, at 04:46, Khalid Baheyeldin wrote:
What Karoly is saying is something I observed: every long thread recently has alluded to the "CCK in core" wish that many of us would like to see. An example is the user profile thread by Rowan, and the replies in it just today, and many others before it.
Karoly is quoting past precedence on how long it takes things to mature and make it into core, and is of the opinion that cck in core will not be ready for D6.
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-) -- Dries Buytaert :: http://www.buytaert.net/
On Feb 2, 2007, at 6:21 AM, Dries Buytaert wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-)
Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start. -- Ray Zimmerman Senior Research Associate 428-B Phillips Hall, Cornell University, Ithaca, NY 14853 phone: (607) 255-9645
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-)
Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start.
Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ... -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-)
Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start.
Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ...
The big thing that is left is field management. I'd like to see: - No modules added. I don't think this is a feature that would want to be disabled at the system-level. There are other ways to organize code without adding more modules. - A generic solution that profiles fields work with. -- Neil Drumm http://delocalizedham.com/
On 2/5/07, Neil Drumm <drumm@delocalizedham.com> wrote:
Dries Buytaert wrote:
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-)
Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start.
Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ...
The big thing that is left is field management.
I'd like to see: - No modules added. I don't think this is a feature that would want to be disabled at the system-level. There are other ways to organize code without adding more modules. - A generic solution that profiles fields work with.
+1. To which I would add, that other modules (e.g. signup, survey modules) can also generically use those fields. Not-a-node can be a good thing, and re-using the same "fields" base is also good. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On Tuesday 06 February 2007 12:08 am, Neil Drumm wrote:
Dries Buytaert wrote:
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-)
Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start.
Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ...
The big thing that is left is field management.
I'd like to see: - No modules added. I don't think this is a feature that would want to be disabled at the system-level. There are other ways to organize code without adding more modules. - A generic solution that profiles fields work with.
Which then begs the question, if one were to simply rip the field management parts out of content.module, tuck them into node.module, and polish a bit, what would be left to do? (For me it's value-add fields rather than value-add form primitives, which I imagine would involve hook_elements and hook_widget merging or becoming more closely linked or something, but that's just my speculation based on banging my head against a CCK field module for the past few days. <g>) -- 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
Op dinsdag 6 februari 2007 07:42, schreef Larry Garfield:
(For me it's value-add fields rather than value-add form primitives, which I imagine would involve hook_elements and hook_widget merging or becoming more closely linked or something, but that's just my speculation based on banging my head against a CCK field module for the past few days. <g>)
This raises another issue, simplicity. I think we all somehow agree that the current field code is far too complex (and overengineerd?) to be copy-pasted into core. Personally I think flexinode field handling is a better model for core. read: model. Model. IMO the choices, when going for an existing solution, is either: CCK-stripped, flexinode-a-lot-cleaner, or profile-fields-made-modular. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Larry Garfield wrote:
On Tuesday 06 February 2007 12:08 am, Neil Drumm wrote:
Dries Buytaert wrote:
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-) Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start. Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ... The big thing that is left is field management.
I'd like to see: - No modules added. I don't think this is a feature that would want to be disabled at the system-level. There are other ways to organize code without adding more modules. - A generic solution that profiles fields work with.
Which then begs the question, if one were to simply rip the field management parts out of content.module, tuck them into node.module, and polish a bit, what would be left to do?
Thats one option. Merging APIs with profile and making it generic can certainly happen after node fields are working. I'm not sure that would be so simple, the "polish a bit" step might take a bit of work.
(For me it's value-add fields rather than value-add form primitives, which I imagine would involve hook_elements and hook_widget merging or becoming more closely linked or something, but that's just my speculation based on banging my head against a CCK field module for the past few days. <g>)
That might be a good concept too. -- Neil Drumm http://delocalizedham.com/
On Tue, 2007-02-06 at 00:11 -0800, Neil Drumm wrote:
Larry Garfield wrote:
On Tuesday 06 February 2007 12:08 am, Neil Drumm wrote:
Dries Buytaert wrote:
On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
Getting more of CCK in core would be great. Once more of CCK is in core, we can talk again about profiles. Now, where are the CCK patches? I haven't seen any yet. :-) Since getting more of CCK into core is, presumably, not a matter of simply copying the contrib CCK, I was wondering if anyone has laid out what exactly needs to be done? I'm not in a position to propose one, but it seems a prioritized task list would be the place to start. Good question. In fact, after months of bugfixing, I could use an update myself. Hopefully CCK-wranglers like Eaton, Jaza, KarenS and friends might be able to lay out a bit of a plan ... The big thing that is left is field management.
I'd like to see: - No modules added. I don't think this is a feature that would want to be disabled at the system-level. There are other ways to organize code without adding more modules. - A generic solution that profiles fields work with.
Which then begs the question, if one were to simply rip the field management parts out of content.module, tuck them into node.module, and polish a bit, what would be left to do?
Thats one option. Merging APIs with profile and making it generic can certainly happen after node fields are working. I'm not sure that would be so simple, the "polish a bit" step might take a bit of work.
The polish bit is quite a bit of work. Things that need shining... - Simplify CCK API's. - _info hooks could easily be rolled into the _settings hook. - hook_widget could lose most of its ops to FormAPI - formatters need some type of settings form, maybe not now but sometime. I've been running into many cases with imagefield where people want more and more options for formatters. - leverage FormAPI better for all forms. - Field Grouping code needs TLC. It looked pretty hairy last time I looked at it. It's a really cool feature, but I'm not certain it belongs in CCK. It's usefulness has a much wider scope. - Getting per field access control right. - Multivalue support needs love. Values are often left in the database after all values of multivalues fields are deleted. It causes some chaos and sanity checks in places they shouldn't be necessary. Things we should just do for posterity's sake: - Security Review - Usability and Copy Review. - Review Inline Documentation.
(For me it's value-add fields rather than value-add form primitives, which I imagine would involve hook_elements and hook_widget merging or becoming more closely linked or something, but that's just my speculation based on banging my head against a CCK field module for the past few days. <g>)
That might be a good concept too.
The idea that Eaton and I had along these lines was to make hook_widget_settings and interface for relating form_elements to fields and providing set of settings for that element. This could eliminate the callback in CCK, but would require learning how to construct form elements in order to create CCK fields for developers. The same could probably be done for output via formatters as output rendering via FormAPI matures. I'm sure there are better ideas, but I have been out of the loop for a bit. I'm sure Karen, Yched, Eaton, and Jaza have some ideas as well. Ber probably has some ideas from his work and experience with Flexinode we should listen to. I think it would be cool if plenty of generally intelligent bi-peds that operate computers actually look over the code and ask a lot of whys and why nots.
On 06 Feb 2007, at 10:08, Darrel O'Pry wrote:
The polish bit is quite a bit of work. Things that need shining...
- Simplify CCK API's. - _info hooks could easily be rolled into the _settings hook.
- hook_widget could lose most of its ops to FormAPI
- formatters need some type of settings form, maybe not now but sometime. I've been running into many cases with imagefield where people want more and more options for formatters.
- leverage FormAPI better for all forms.
- Field Grouping code needs TLC. It looked pretty hairy last time I looked at it. It's a really cool feature, but I'm not certain it belongs in CCK. It's usefulness has a much wider scope.
- Getting per field access control right.
- Multivalue support needs love. Values are often left in the database after all values of multivalues fields are deleted. It causes some chaos and sanity checks in places they shouldn't be necessary.
Things we should just do for posterity's sake: - Security Review - Usability and Copy Review. - Review Inline Documentation.
Thanks Darrel -- good overview. I just wanted to remark that it doesn't have to be an "all or nothing" approach. We can start by migrating a couple of things to core, and worry about the other bits once that has been taken care of. Step 1 could be adding support for adding an additional textfield without special access control or field grouping. -- Dries Buytaert :: http://www.buytaert.net/
I'd like to make a brief plug for dealing with http://drupal.org/node/87806 This would basically suggest that we make different model types for html fields vs. other text area fields. Both would have a default widget of textarea, but providing the data types would open the door for future validation and wysywig functionality based on the CKK hooks. The work that this adds, is that we'd go through core, setting appropriate filed types as appropriate. For example: the site mission would be of type 'markup' while the pages field on block configuration would be of type 'text'. If the default data types in the forms api or model api, I'd certainly be willing to submit core patches for the tedious work of setting the right field type. This simple work would open the door for TinyMCE and other WYSIWG editors ad widgets.
CCK exists of the following things for me : 1. Field Types 2. widgets and formatters 3. Data model - consisting of the field types. 4. Query builder - crud functions. - generates query from data model. 5. Configuration interface - builds data model I believe that we should integrate 1-3 into the forms api (and indeed create the data api that way). All the field types that cck has, (ie: integers, floats, etc) have validations already. Which is already much much stronger than what we have currently (using textfields for everything. pfft). Form elements as we have them now, are essentially widgets as CCK has them. Every field type has a default widget it uses. This is an extra (optional) property of the form array. So everywhere we have $form['title'] = array('#type' => 'textfield'); we will then have : $form['title'] = array('#type' => 'text'); I don't believe we should make a differentiation for widgets / formatters. They are just input/display widgets. All field types, have a default widget for editing, and for display. These can be overridden in the fapi array. I see that as a first phase, which would bring all the field type / widget code into core.. and all forms will re-use the same code. Including profiles. Second phase : data model. --- As I specified in my data model presentation at the last DrupalCon, we have a data model currently, it's just hidden in the form array structure. We use an incredible amount of complex logic to try and determine the data model from the form array. Just about all the complexity in form_builder comes from this process. CCK does this the right way around, it creates a data model (by defining the fields) and then converts the data model into a form / display. For consistency, we should then look at making all forms use the same mechanism. This will _greatly_ simplify the amount of twiddling we need to do in form_builder. The form / view is actually a superstructure built on top of the data model, with added display / form specific properties added. In my example, they took the form of a data model function, which defines only the fields: function model_objecttype() { // these constructor functions return arrays with all the default values for that type already populated. // this improves cacheability, in that all the array merging is done in the first step, not recursively called on everything. // it also lessens the amount of code needed, and imo improves readability. $model['id'] = drupal_field('id'); // defaults to edit_widget => hidden $model['title'] = drupal_field('title'); // Additional default field lengths , and defaults to a textfield. $model['body'] = drupal_field('body'); return $model; } This can then be turned into a view / form : function form_objecttype($model) { $form['id'] = drupal_widget($model['id']); $form['fieldset'] = drupal_widget('fieldset', array('title' => 'something') ); $form['fieldset']['title'] = drupal_widget($model['title'], array ('widget' => 'textarea') ); $form['fieldset']['body'] = drupal_widget($model['body'], array ('widget' => 'textfield')); return $form; } By just automatically recurring through the model data structure, we can change it into a form without even needing to have a separate function (the same way we can do drupal_render without needing to specify a theme function). Other things that will get added into the display, is stuff like tables. At this point, we have got the Data API as i mentioned created. After this we can look at making the CRUD functions (which imo shouild be standardised into save_objecttype, create_objecttype, delete_objecttype, load_objecttype) work with a query builder, as it does for cck.
Best e-mail of the week, Adrian. I recommend people to bookmark it, and to add this to KarenS's issue in the patch queue. Some below for comments. :-) On 06 Feb 2007, at 13:47, adrian rossouw wrote:
CCK exists of the following things for me :
1. Field Types 2. widgets and formatters 3. Data model - consisting of the field types. 4. Query builder - crud functions. - generates query from data model. 5. Configuration interface - builds data model
I believe that we should integrate 1-3 into the forms api (and indeed create the data api that way).
All the field types that cck has, (ie: integers, floats, etc) have validations already. Which is already much much stronger than what we have currently (using textfields for everything. pfft).
Form elements as we have them now, are essentially widgets as CCK has them. Every field type has a default widget it uses. This is an extra (optional) property of the form array.
So everywhere we have $form['title'] = array('#type' => 'textfield'); we will then have : $form['title'] = array('#type' => 'text');
I don't believe we should make a differentiation for widgets / formatters. They are just input/display widgets. All field types, have a default widget for editing, and for display. These can be overridden in the fapi array.
I see that as a first phase, which would bring all the field type / widget code into core.. and all forms will re-use the same code. Including profiles.
So, if I understand correctly, you suggest that introducing more types (i.e. float, integer) and corresponding validation routines in core would be the first step. This makes sense to me, and shouldn't be too hard. Is anyone working on this -- or willing to work on this?
Second phase : data model. --- As I specified in my data model presentation at the last DrupalCon, we have a data model currently, it's just hidden in the form array structure.
We use an incredible amount of complex logic to try and determine the data model from the form array.
Just about all the complexity in form_builder comes from this process.
CCK does this the right way around, it creates a data model (by defining the fields) and then converts the data model into a form / display. For consistency, we should then look at making all forms use the same mechanism.
Yes! I strongly believe this is the way forward. It's not only key for the CCK, but for a bunch of other things as well, i.e. import- export, generating database schemas. Once we have a proper data model, we can talk again about reworking the field handling of the profile module or creating a super-object that nodes are derived from. I'd really love to make this one of the new killer features in Drupal 6 -- it's ripple effect has huge potential and are much needed to advance Drupal. Who intends to submit patches for that? Are you going to work on this, Adrian? I'm asking because I'd really like to see these kind of changes to go in early in the development process (say the next 4-6 weeks). Why? Because I want to avoid a Drupal 4.7 scenario. ;) It would be great if we could focus on this NOW. :-) -- Dries Buytaert :: http://www.buytaert.net/
On 07 Feb 2007, at 9:39 AM, Dries Buytaert wrote:
So, if I understand correctly, you suggest that introducing more types (i.e. float, integer) and corresponding validation routines in core would be the first step. This makes sense to me, and shouldn't be too hard. Is anyone working on this -- or willing to work on this?
I think perhaps we should look at more semantic data types than just float and integer. A good example of this would be a title type. Which defaults to textfield, and automatically does the plaintext validation and formatting on output. The same with 'markup' or similar, which automatically expands to a widget that has format selectors. 'id' field type could also be useful. Especially when integrated into a query builder, and even if only for constructing crud functions such as drupal_load('objecttype', 'id1', 'id2'); Personally I'm more interested in working on the data model side of things, and how it ties into the CRUD functions. I've already made a good start at that in the stuff i did for drupalcon.
Nice post. And not very different from my future plans with flexinode, in fact[1]. :) Op dinsdag 6 februari 2007 13:47, schreef adrian rossouw:
CCK exists of the following things for me :
1. Field Types 2. widgets and formatters 3. Data model - consisting of the field types. 4. Query builder - crud functions. - generates query from data model. 5. Configuration interface - builds data model
However, one thing I /really/ miss in the architecture of CCK, and in FAPI, and in your post too, is he view (as in theme/display) layer. We agree that data != presentation, right? We render "Submitted by Bèr Kessels on Sat, 02/03/2007 - 13:34." and not "Submitted by 12 on 1172793600" Data is 12, the uid. But what we display is the user name (or whatever we craft from it) with a link. I think having this is crucial, and in the ERD for flexinode I have called it the 'display profiles'. In both the FAPI and CCK this is spagettied trough the code. Some parts in the output are coupled to the widget (!?) in the form of config settings. Others are left to the type of widget. Again others are left entirely to the theme. The lack of vision and therefore consistency bothers me, as a themer. We should IMO at least *think* about how and where to handle this. In any case: Flexinode will, at some point, use display profiles. How exactly they are going to be coded: I have no idea. But what they *are* is clear to me: A simple configurable, database stored 'thingy' that tells what theme function (callback handler id) should be called to render the data. $node->date is the data. The display profile tells "because of Foo and Bar, use 'theme_date_ago()' with arguments array('uid'=>$node->date)". Maybe this concept itself is enough to keep in mind for a next version of CCK-in-core? Bèr [1] http://webschuur.com/node/643 BTW: this is only a small part of a larger plan, for example: In case of flexinode, the admin can choose, in the field-configuration , what theme function to call for a certain field. That is the "Foo and Bar". However, this should be overridable by modules. So that I can say: I am a stubborn module that cares about privacy. For IP range xyz, don't use "theme_linked_username()", instead, use theme_garbled_username". This will be a hook. In the ERD that is the 'display handler', wich wraps around the theme functions itself. -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On Wed, 2007-02-07 at 10:36 +0100, Bèr Kessels wrote:
Nice post. And not very different from my future plans with flexinode, in fact[1]. :)
Op dinsdag 6 februari 2007 13:47, schreef adrian rossouw:
CCK exists of the following things for me :
1. Field Types 2. widgets and formatters 3. Data model - consisting of the field types. 4. Query builder - crud functions. - generates query from data model. 5. Configuration interface - builds data model
However, one thing I /really/ miss in the architecture of CCK, and in FAPI, and in your post too, is he view (as in theme/display) layer.
We agree that data != presentation, right?
We render "Submitted by Bèr Kessels on Sat, 02/03/2007 - 13:34." and not "Submitted by 12 on 1172793600"
Data is 12, the uid. But what we display is the user name (or whatever we craft from it) with a link.
I think having this is crucial, and in the ERD for flexinode I have called it the 'display profiles'. In both the FAPI and CCK this is spagettied trough the code. Some parts in the output are coupled to the widget (!?) in the form of config settings. Others are left to the type of widget. Again others are left entirely to the theme. The lack of vision and therefore consistency bothers me, as a themer. We should IMO at least *think* about how and where to handle this.
What are you talking about Ber? Have you even used CCK lately? The Formatter system has been in place for quite a while now, and is working really well. It even allows you to specify the formatter you want to use for a particular field in views, and you can use the content_format() function in your themes as well. You can easily write additional formatters for any field type in your own custom module.
In any case: Flexinode will, at some point, use display profiles. How exactly they are going to be coded: I have no idea. But what they *are* is clear to me: A simple configurable, database stored 'thingy' that tells what theme function (callback handler id) should be called to render the data. $node->date is the data. The display profile tells "because of Foo and Bar, use 'theme_date_ago()' with arguments array('uid'=>$node->date)".
Already done. See the display settings patch that eaton wrote that is now a part of cck. It allows you to select the formatter used in different display contexts and will expand to support RSS, print, etc.
On Tue, 2007-02-06 at 14:47 +0200, adrian rossouw wrote:
CCK exists of the following things for me :
1. Field Types 2. widgets and formatters 3. Data model - consisting of the field types. 4. Query builder - crud functions. - generates query from data model. 5. Configuration interface - builds data model
I believe that we should integrate 1-3 into the forms api (and indeed create the data api that way).
Yeah FAPI 3 !!
All the field types that cck has, (ie: integers, floats, etc) have validations already. Which is already much much stronger than what we have currently (using textfields for everything. pfft).
This can be overcome with a few simple #validate functions on form elements correct? In the current CCK model there are two layers of validation. The widgets provide their own input validation that is naive to the requirements of the data layer. The Data layer then validates what the widget produced as final output. Are you envisioning a common validation or add #validate callbacks to the data model as well?
Form elements as we have them now, are essentially widgets as CCK has them. Every field type has a default widget it uses. This is an extra (optional) property of the form array.
Yes they are. CCK also provides a relation between widgets and the fields they'll work with and settings per widgets. I would expect the settings to the optional properties of the form array, and the default widget to be meta data about widgets that the field module keeps track of.
So everywhere we have $form['title'] = array('#type' => 'textfield'); we will then have : $form['title'] = array('#type' => 'text');
I don't believe we should make a differentiation for widgets / formatters. They are just input/display widgets. All field types, have a default widget for editing, and for display. These can be overridden in the fapi array.
That approach may solve the problem I'm having with formatters not having settings, the way input widgets do currently. It may cause some confusion for the people who have already been developing them, but adding a flag and eliminating hook_formatter is good in my book... Hook widget can go as well if the _value patch goes in. It should effectively deprecate prepare. However people will need to be careful about overriding widgets in for CCK as different fields have different inputs and outputs. Theme functions can just be tossed around merrily.
I see that as a first phase, which would bring all the field type / widget code into core.. and all forms will re-use the same code. Including profiles.
Second phase : data model. --- As I specified in my data model presentation at the last DrupalCon, we have a data model currently, it's just hidden in the form array structure.
I need to go re-examine your presentation
On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote:
This can be overcome with a few simple #validate functions on form elements correct?
There are definitely 2 steps involved here. widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets. I don't believe we should include the #validate functions for the field types / widgets into the form structure thought, because if we do it right,. every single field will have validation rules, and all that information will not often be modified (fields can still have additional validation rules of course). We don't want to bloat the data structure unnecessarily.
On Wed, 2007-02-07 at 22:11 +0200, adrian rossouw wrote:
On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote
This can be overcome with a few simple #validate functions on form elements correct? There are definitely 2 steps involved here.
widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets.
I think chx is already working on this based on my notes for the _value callback. If he doesn't have time he can ping me and I'll do it, its blocking two things I'm working on now.
I don't believe we should include the #validate functions for the field types / widgets into the form structure thought, because if we do it right,. every single field will have validation rules, and all that information will not often be modified (fields can still have additional validation rules of course).
How do you envision the hardcoded validation working? A fixed callback per widget/field type? How do users extend it? Do we still process #validate, but the default is _validate and shouldn't be specified?
We don't want to bloat the data structure unnecessarily.
I'll agree. I'm not sure I really get it though without a real sample structure to mull over.
On 07 Feb 2007, at 21:45, Darrel O'Pry wrote:
widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets.
I think chx is already working on this based on my notes for the _value callback. If he doesn't have time he can ping me and I'll do it, its blocking two things I'm working on now.
I can't speak for chx, but we've been pretty busy -- and chx in particular -- with the menu system work. Help with the CCK-related stuff in core would be appreciated. I'd be happy to provide frequent reviews of any CCK related advances. So, wadduya say Darrel? :) -- Dries Buytaert :: http://www.buytaert.net/
On Thu, 2007-02-08 at 18:19 +0100, Dries Buytaert wrote:
On 07 Feb 2007, at 21:45, Darrel O'Pry wrote:
widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets.
I think chx is already working on this based on my notes for the _value callback. If he doesn't have time he can ping me and I'll do it, its blocking two things I'm working on now.
I can't speak for chx, but we've been pretty busy -- and chx in particular -- with the menu system work. Help with the CCK-related stuff in core would be appreciated. I'd be happy to provide frequent reviews of any CCK related advances. So, wadduya say Darrel? :)
I'm game. It'll probably be next week before I can get any patches going in that direction.
Darrel O'Pry wrote:
I can't speak for chx, but we've been pretty busy -- and chx in particular -- with the menu system work. Help with the CCK-related stuff in core would be appreciated. I'd be happy to provide frequent reviews of any CCK related advances. So, wadduya say Darrel? :)
I'm game. It'll probably be next week before I can get any patches going in that direction.
Will this impact your efforts toward filesystem.module? Getting that functionality in core is also a big deal. Drupal's use of the filesystem, right now, is a big limitation for sites.
Earl Miles a ecrit le 08/02/2007 19:49:
Darrel O'Pry wrote:
I can't speak for chx, but we've been pretty busy -- and chx in particular -- with the menu system work. Help with the CCK-related stuff in core would be appreciated. I'd be happy to provide frequent reviews of any CCK related advances. So, wadduya say Darrel? :)
I'm game. It'll probably be next week before I can get any patches going in that direction.
Will this impact your efforts toward filesystem.module? Getting that functionality in core is also a big deal. Drupal's use of the filesystem, right now, is a big limitation for sites.
FWIW, I'm also willing to lend a hand on this. It's just that, while I'm rather fluent with CCK's current architecture and mechanism (and limitations), the FAPI3 direction, albeit really exciting and with all the appearance of 'the right direction to take', is still sort of blurry for me. As in 'i don't know where to start'. Yet I, too, feel that darrel's work on filesystem is precious...
Yves CHEDEMOIS schrieb:
FWIW, I'm also willing to lend a hand on this. It's just that, while I'm rather fluent with CCK's current architecture and mechanism (and limitations), the FAPI3 direction, albeit really exciting and with all the appearance of 'the right direction to take', is still sort of blurry for me. As in 'i don't know where to start'.
http://drupal.org/node/86535 (Adrian's presentation about 'FAPI3' (actually not a perfect term to describe what this is about)is a great starting point. Especially the example .php file contains nearly all of the concepts.
Yet I, too, feel that darrel's work on filesystem is precious...
So do I. -- Frando? Gaunab? -Unbiskant: http://unbiskant.org
In order to have a clearer view and begin fiddling with this, I took the code in adrian's sandbox (currently raw php), and wrapped it in a fapi3_test module, which provides some test pages and a bridge with the current implementations of drupal_render and form_* processing functions - so that generated forms get in the form submitting / validating workflow. I think this could be helpful to anyone willing to work on the area (Darrel, I don't know if you started something, but this should not really interfere) I'm not really sure of the best way to make this available, though. I don't think this list accepts attached files, and committing this to my own sandbow would be sort of weird, since it's 95% adrian's code. For now I posted it in the "CCK in core" thread Karen opened in the CCK issue queue : http://drupal.org/node/115822 (even though the FAPI3 road for 'fields in core' largely exceeds CCK-as-we-currently-know-it, so it might be better placed in core issue queue ?) yched
Rowan Kerr wrote:
On 1-Feb-07, at 1:43 PM, Gerhard Killesreiter wrote:
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
That's why I was asking. :) I think CCK makes a lot of sense for profile fields in the long run. Will CCK be in D6 core though?
Dries has said several times that he wants to see (more of) CCK in code so I guess that patches towards that aim will be warmly received. I don't know if there is any ongoing work though. I don't know what Dries things about profiles as nodes. Cheers, Gerhard
Gerhard Killesreiter wrote:
I don't know what Dries things about profiles as nodes.
The main and usual complaint against users as nodes is two-fold: 1) users arent content and 2) performance. The first is definitely not applicable to profiles because they are almost entirely "content" (personals sites, foaf, company directories, etc) and the second should seem to apply no more than any other content. Is this a correct assumption dries? -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On Thu, 01 Feb 2007 19:43:57 +0100, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
New features: - multiple-select lists (took the easy way out and stored as serialized data could be improved to store the data in normalized tables)
I really hate serialized data, so an improvent would be welcome, if possible.
Sadly, date types are already serialized, but I switched that to be a separate profile_values_date table instead. Multi-select values could be stored in another table as well. Having the _profile_field_serialize helper function is actually quite useful for "fixing" storage of complex data types, as it can wrap around loading and saving data to different tables.
Maybe it would make sense to let user profiles be cck nodes instead. That would avoid a lot of code duplication.
Honestly, I haven't really ever looked at CCK, but maybe some of its techniques (at least the data types and validation) could be applied to the profiles so that at least the behaviour is similar if CCK ever gets into core and profiles become nodes ;). -Rowan
participants (23)
-
adrian rossouw -
Allie Micka -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Dries Buytaert -
Earl Miles -
FGM -
Frando (Franz Heinzmann) -
Gabor Hojtsy -
Gerhard Killesreiter -
Karoly Negyesi -
Khalid Baheyeldin -
Larry Garfield -
Metzler, David -
Michael Favia -
Moshe Weitzman -
Neil Drumm -
Ray Zimmerman -
Rowan Kerr -
Yves Chedemois -
Yves CHEDEMOIS