[drupal-devel] Standard set of objects and methods?

[Jose A. Reyero]

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
>  
>