Hi all,
I'm focusing on event managment because I'm setting up a site that will advertise events.
In the previous versions of event.module the structure of the module was fixed, and so it was simple to create a newsletter that will print out the title, teaser, date and location informations.
With the new version, event is more and more flexible, so any flexinode-type node can become an event.
This is REALLY powerful, so I can create several flexinode-based node types (with different informations, based on the type of event you need).

Now, the problem.

Suppose I have different event types (everyone with its location and teaser field); how can I write a GENERALIZED newsletter module that will recognize that in 'flexinode-1' based events (suppose a stage), location field is named 'flexinode_15' and teaser field is named 'flexinode_16' while in 'flexinode-2' based events (let's say a concert) location field is named 'flexinode_24' and teaser field is named 'flexinode_23' ??

I wouldn't like to write everytime a specific module that everytime must be tailored in order to print out the right fields, and I'm thinking of a universal solution.

The only simple way I found would be to put location informations and the teaser into event table, so that data structure would become fixed, and every other module could benefit of it.

What is your opinion on this matter ?? Does it sound interesting ?? Is anyother working or thinking of something similar ???

Please let me have your opinions,

Matteo
[webmaster at cantincoro dot org]

Comments

scroogie’s picture

scroogie commented

I think the right way would be to make the newsletter more flexible, to let the admin Click together components (node-types and fields) to build up a text. The other way around - making event less flexible - is not solving the problem, but shifting it in another direction.

matteo’s picture

matteo commented

I understand, but this should be done also for event feed, because you would have the same problem...
Matteo

drewish’s picture

drewish commented

I don't think this will be implemented. The taxonomy module will let you differentiate the types and the location module allows location data to be attached to any node type (at least it does in 4.7).

progressnerd’s picture

progressnerd commented
Version: 4.6.x-1.x-dev » 4.7.x-1.x-dev

Event should depend on location. I understand why location is it's own independent module. But event should depend on location and presume it exists. That way, lists and calendars of events, like most calendar programs, can show the location as well. While you can certain have data that has a location but no time, it is extremely rare -- just improbable -- to have data with a time but no location. Events should always have locations!

drewish’s picture

drewish commented

progressnerd, loosely coupled is best. you want examples, what about a web chat? that's got a place but no location. or, how about a schedule for a web stream? times but no places.

drewish’s picture

drewish commented

whoops, that should have read "that's got a time but no location."

progressnerd’s picture

progressnerd commented

Sure, a webchat has a location: it has a url or the name of a website it's located at. But even if you were to construe a few examples where something plausibly doesn't have a location, then just allow the location to be left blank. Every Drupal user I know is annoyed that their list of upcoming events and their calendars don't show the event location. Every other event/agenda/calendar application includes this.

Event = Time + Location. Nothing that has a time doesn't also have a place. It just makes sense.

drewish’s picture

drewish commented
Status: Active » Closed (won't fix)

well killes has stated, and i agree with him, that he won't change it. the drupal way is loosely coupled modules.