[development] No module-defined node types?

[Larry Garfield]

On Thursday 04 January 2007 2:31 pm, Morbus Iff wrote:

> With a few mouseclicks, I have taken a default core type (Page, though
> it could also have been any other node type, or one created by CCK,
> etc.) and increased its capacity two fold: it is now a Case and gets all
> the logic (and fields) of Case Tracker, but is also an Event and gets
> Start/End times, and shows up in the calendar and is filterable with
> Event's dropdown filter. Adding Event Repeat, a plugin to Event, isn't a
> problem either - now Page is a Event Repeat(ing) Event that is also a
> Page that is also a Case. Later on, I install your module, choose that I
> want "Emotion" to apply to Page, and now have a Page that is an Event
> Repeating Event, a Case, and Emotional.
>
> You can't do this under the "old" way, because the user is stuck using
> only your Emotional Story node type. Sure, "new" way modules could be
> used to expand upon Emotional Story (making them also an Event and also
> a Case Tracker Case), but when the flexibility exists to add fields +
> logic to /any/ node type, as opposed to shipping one, you should use it.
> It's quite rude to think that I have to use just YOUR node type when all
> 900 of my other nodes are "Story", and now I have to abandon them and
> use "Emotional Story" instead.
>
> This is the heart of what Jaza was getting to, and why it showed up in a
> discussion upon hook_nodeapi(), which is the central Drupal hook that
> allows us to pull all this off.

I fully agree that value-add nodes offer a great deal of flexibility and are, 
in general, more powerful.  I'm launching a site on Monday where we don't 
have any nodes that aren't CCK-defined.  Even page.module and story.module 
are disabled, and then we value-add with event.module.  That's been a huge 
boon for us, especially because CCK auto-supports Views and Views runs half 
the site. :-)  

My question boils down to edge cases and HOW that value-add works.  For 
example, event.module.  In the current system, AFAIK, event value-adds via 
form_alter some select boxes and radio buttons to a node-edit form and then 
via FAPI magic (or _nodeapi magic, I honestly don't know) validates those 
select boxes to a valid date, ensures that the start date/time is before the 
end date/time, etc., and then saves them to its own event table as unix 
timestamps.  Then on _nodeapi#load, it adds those fields back onto the node 
object and all is well.

But, now there's this great date.module that offers a self-validating date 
field for CCK nodes.  A time.module or even datetime.module that offers 
time/date-and-time validation is certainly feasible, and would allow even 
greater flexibility in terms of how its rendered (select boxes, textfield, JS 
popup, etc.)  If event.module could value-add a rich field like that, that 
simplifies its code considerably, simplifies the database, and opens up all 
sorts of other fun options I can't even think of.  

But how does one value-add a CCK field?  Or would you have to tell the user to 
add it and then select which field is the "start" and which is the "end"?  I 
don't know of a way right now.  That could be because there isn't one, or 
could be that I just don't know what it is. :-)  

Or take my one contrib module of actual significance <g>, nodereview.  Right 
now it's a fully module-defined node that leverages votingapi.module.  Each 
node consists of a reference to a node being reviewed plus an admin-defined 
number of "sets" of fields, where each set consists of a textual review plus 
a votingapi rating.  Yes, that makes a variable number of fields on a node, 
depending on what the type of the node being referenced is.  Kinda funky. :-)

For upgrading it to Drupal 5, I've been debating how if at all I can leverage 
the semi-CCK in core now, or even full CCK.  I could easily replace the 
reviewed_nid field with a nodereference that gets form_altered.  What about 
the others, though?  Define a custom field type that is an aggregate "axis" 
with 2 internal widgets?  And then how to do I piece those together without 
requiring the user to then custom build each review node on their own 
according to specific rules before it becomes useful?  

(No, this isn't a plea for help on the module; it's just an example I'm very 
familiar with.)

That's one reason I said earlier that CCK import/export a la views was 
important, and I plan to look into the content_copy.module Moshe mentioned 
earlier sometime this weekend.  But hopefully you see my point.  I *want* to 
be able to leverage rich field types from CCK and just plug-and-play content 
types.  I just don't see how that works for complex and 
conditionally-configured nodes.  

If there's some vision (no, I won't say roadmap <g>) for how that can happen 
now or will happen in the future, please let me know.  I like the direction 
nodes are moving and want to stay with the curve; I just don't see how the 
edge cases are going to work.

-- 
Larry Garfield			AIM: LOLG42
larry at 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