As stated in http://drupal.org/node/196234, I'd like to see the program node be a straight CCK type implementation, to take advantage of all the development there (yes, I know fields can be added, but it's not the same thing).

Genre and URL could be supported as CCK fields that way (perhaps with an upgrade conversion?) but fields would be optional that way, unless they were expected or needed by other parts of the Station module.

Don't know if it would be better to create a stub type, or merely allow user to designate a specific node type as the "program".

This could potentially be a jumping off point to further abstract the schedule, so that it could apply to more than the station stuff. Think of the way the calendar module can work with a variety of node types, as long as they have a date.

Comments

drewish’s picture

drewish commented

well the archive uses the program's genre field for the audio node's genre. that's really the only dependency i can think of at this point.

the other thing to think about is the teasers. right now the module does a bit of work to make a single sentence out of the djs, genre and scheduled times. that'd be much harder to do with a CCK node.

I'd like to see the program node be a straight CCK type implementation, to take advantage of all the development there (yes, I know fields can be added, but it's not the same thing).

what do you mean? could you detail the differences and why a pure cck node would be best?

rjleigh’s picture

rjleigh commented

what do you mean? could you detail the differences and why a pure cck node would be best?

well, I guess since we fixed the problem referred to above, and you've already supplied the genre and url fields to views, I can't thing of anything offhand.

But let say there's a new module that manipulates fields, like views (something in workflow/actions, for instance) - it would automatically provide support for typical CCK methods, while you'd have to provide that support, like you did with views.

And I guess conceptually I like things conforming to some sort of standard, at least when it's as established as CCK, rather than each module for itself (though I realize that approach can create it's own problems of dependency).

And, as I said, I don't even want the genre field!

But it's a low priority overall, especially if it's terribly time consuming.

drewish’s picture

drewish commented
Status: Active » Fixed

in D6 these are now CCK nodes. i won't be doing anything with them in D5.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.