[drupal-devel] Standard set of objects and methods?
How can we improve parallelism between the various object types in Drupal? Should we be providing a standard way to determine available object types? Should we create common methods for all? As object types, we have (at a minimum) nodes, vocabularies, terms, and users. We might also consider, e.g., modules, themes, and file uploads as core object types. In many cases we might wish to do parallel things with each object type (track it, display it, interact with it), but at present we need to do this somewhat differently for each. Example 1: extended information. We sometimes want to display additional information about an object being viewed (who created it, when, how often it has been viewed, etc.). But we would need to do this differently for each object type (user, node, term, etc.), and some entirely lack methods. Example 2: statistics. We track statistics by node. But what if we also want statistics on users, terms, etc.? We'd need separate tables (term_statistics, user_statistics, etc.) and separate methods. Example 3: associated images. We want to associate images with objects. For users we put a file reference in the user table field, for terms (via a contrib module) in a term_images table, for themes somewhere else. Potential solution/approach: object abstraction. Methods prepared to meet any kind of object. And a way for object types to register themselves, so a list of available types can be accessed. Would this make sense?
Yay! Op maandag 02 mei 2005 20:34, schreef Nedjo Rogers:
How can we improve parallelism between the various object types in Drupal? Should we be providing a standard way to determine available object types? Should we create common methods for all?
As object types, we have (at a minimum) nodes, vocabularies, terms, and users. We might also consider, e.g., modules, themes, and file uploads as core object types. In many cases we might wish to do parallel things with each object type (track it, display it, interact with it), but at present we need to do this somewhat differently for each.
I suggest, for the sake of the discussion we limit to: nodes, comments, users, vocabularies, terms and menu items. Those are the core objects.
Example 1: extended information. We sometimes want to display additional information about an object being viewed (who created it, when, how often it has been viewed, etc.). But we would need to do this differently for each object type (user, node, term, etc.), and some entirely lack methods.
Example 2: statistics. We track statistics by node. But what if we also want statistics on users, terms, etc.? We'd need separate tables (term_statistics, user_statistics, etc.) and separate methods.
Example 3: associated images. We want to associate images with objects. For users we put a file reference in the user table field, for terms (via a contrib module) in a term_images table, for themes somewhere else.
Potential solution/approach: object abstraction. Methods prepared to meet any kind of object. And a way for object types to register themselves, so a list of available types can be accessed.
Would this make sense?
Yes, a lot. But IMO we should (a) not discuss his too much, for it will be hard to find a compromise; And (b) limit us to the practical side of this, not get too academic. IMO we could simply start by renaming everything with a single unified naming convention. Not name (user), title (node) or subject (comment), but rather a single word, used to define that part. Same for body (node), description (term). just don't ask me what names to use, though ;). IMO these changes should be reflected in the database column names too. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 02 May 2005, at 22:37, Bèr Kessels wrote:
IMO we could simply start by renaming everything with a single unified naming convention. Not name (user), title (node) or subject (comment), but rather a single word, used to define that part. Same for body (node), description (term). just don't ask me what names to use, though ;). IMO these changes should be reflected in the database column names too.
Agreed. In some ways, we already have what you describe. Take format_name(), for example. You can pass it any object with a uid and a name, and it will display a username. I'm OK with adding more such patterns where appropriate. -- Dries Buytaert :: http://www.buytaert.net/
On Tue, 3 May 2005, Dries Buytaert wrote:
On 02 May 2005, at 22:37, Bèr Kessels wrote:
IMO we could simply start by renaming everything with a single unified naming convention. Not name (user), title (node) or subject (comment), but rather a single word, used to define that part. Same for body (node), description (term). just don't ask me what names to use, though ;). IMO these changes should be reflected in the database column names too.
Agreed.
In some ways, we already have what you describe. Take format_name(), for example. You can pass it any object with a uid and a name, and it will display a username.
I'm OK with adding more such patterns where appropriate.
How about making such format functions themable? I find myself hacking them more often than not on custom installs (and every more serious instlal is a custom install). Cheers, Gerhard
Objects? Yess, I love objects ;-) Bèr Kessels wrote:
Yay!
Op maandag 02 mei 2005 20:34, schreef Nedjo Rogers:
How can we improve parallelism between the various object types in Drupal? Should we be providing a standard way to determine available object types? Should we create common methods for all?
As object types, we have (at a minimum) nodes, vocabularies, terms, and users. We might also consider, e.g., modules, themes, and file uploads as core object types. In many cases we might wish to do parallel things with each object type (track it, display it, interact with it), but at present we need to do this somewhat differently for each.
I suggest, for the sake of the discussion we limit to: nodes, comments, users, vocabularies, terms and menu items. Those are the core objects.
I agree, and maybe would add 'block' here, as a visual container for objects or lists of objects, which would be an object itself Also would like to see some block permissions in place
Example 1: extended information. We sometimes want to display additional information about an object being viewed (who created it, when, how often it has been viewed, etc.). But we would need to do this differently for each object type (user, node, term, etc.), and some entirely lack methods.
Example 2: statistics. We track statistics by node. But what if we also want statistics on users, terms, etc.? We'd need separate tables (term_statistics, user_statistics, etc.) and separate methods.
Example 3: associated images. We want to associate images with objects. For users we put a file reference in the user table field, for terms (via a contrib module) in a term_images table, for themes somewhere else.
Potential solution/approach: object abstraction. Methods prepared to meet any kind of object. And a way for object types to register themselves, so a list of available types can be accessed.
Would this make sense?
Yes, definitely. There's also object permissions, which could be handled in an uniform way And caching, so we could define a different level / refresh rates for each type of object and it all would be managed throgh a common caching mechanism. Like having cached node listings or blocks at the server level which could be refreshed hourly for a highly loaded site, or having menus cached at the session level which would be refreshed only when editing permissions/module configuration.... And let it all be configurable by the site admin... I'm always a fan of 'power for site admins' ;-)
Yes, a lot. But IMO we should (a) not discuss his too much, for it will be hard to find a compromise; And (b) limit us to the practical side of this, not get too academic.
I would start implementing some object repository and some object api, which other modules could use or not, just to see whether the idea takes off But I'd better use PHP OOP capabilities, instead of re-inventing objects, which seems to be the preferred way here :( Am I the only one? About discussion, while I usually like rapid prototyping and proofs of concept to have some grounds for discussion, I think this objects thing could be really amazing if we invest some time in thinking and discussing about it first... Better in a forum maybe?
IMO we could simply start by renaming everything with a single unified naming convention. Not name (user), title (node) or subject (comment), but rather a single word, used to define that part. Same for body (node), description (term). just don't ask me what names to use, though ;). IMO these changes should be reflected in the database column names too.
Yes, and what about ID's? Is there any reason why we should have 'uid', 'nid', 'cid',,,,,? All objects should have also some common timestamps, like 'created' and 'last edit'
Regards, Bèr
participants (5)
-
Bèr Kessels -
Dries Buytaert -
Gerhard Killesreiter -
Jose A. Reyero -
Nedjo Rogers