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