After looking at the event code for 4.6, and also the upgrade path, I want to discuss the idea of perhaps creating a simple event node type. I reallize that long term flexinode-like concepts will go into core, but flexinode is not an ideal solution for *simple* event needs -- it's not simple to theme, the upgrade path is horribly complicated, and it (unnecessarily) places a requirement of using flexinode if you want an event that doesn't "use up" a core node type. So, my suggestion is as follows: * create an event.module that is the *real* 4.6 version and duplicates the functionality of the 4.5 events module (i.e. a location field) but ties into the new event code * move Aaron's event API stuff to a module called eventapi.module An alternative would also be to make event + eventapi a bundle: this would mean a single download enables a basic event node type. -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
+1. I was about to do pretty much the same thing, because I can't think of a way to search Flexinodes. On 4/18/05, Boris Mann <boris.bryght@gmail.com> wrote:
After looking at the event code for 4.6, and also the upgrade path, I want to discuss the idea of perhaps creating a simple event node type.
I reallize that long term flexinode-like concepts will go into core, but flexinode is not an ideal solution for *simple* event needs -- it's not simple to theme, the upgrade path is horribly complicated, and it (unnecessarily) places a requirement of using flexinode if you want an event that doesn't "use up" a core node type.
So, my suggestion is as follows: * create an event.module that is the *real* 4.6 version and duplicates the functionality of the 4.5 events module (i.e. a location field) but ties into the new event code * move Aaron's event API stuff to a module called eventapi.module
An alternative would also be to make event + eventapi a bundle: this would mean a single download enables a basic event node type.
-- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
On Mon, Apr 18, 2005 at 08:06:02PM -0700, Boris Mann wrote:
* create an event.module that is the *real* 4.6 version and duplicates the functionality of the 4.5 events module (i.e. a location field) but ties into the new event code
Sure, this will be a simple copy of page or story. As long as the event module has not been tagged for 4.6 I think this sugestion should be considered. I'll abstain from voting on this. -Neil
On Wed, 20 Apr 2005 neil@civicspacelabs.org wrote:
On Mon, Apr 18, 2005 at 08:06:02PM -0700, Boris Mann wrote:
* create an event.module that is the *real* 4.6 version and duplicates the functionality of the 4.5 events module (i.e. a location field) but ties into the new event code
Sure, this will be a simple copy of page or story.
As long as the event module has not been tagged for 4.6 I think this sugestion should be considered.
I have discussed this with Aaron and we came up with the idea to provide a scirpt that generates a flexinode content type of name "event" similar to the update script. Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Apr 2005, at 5:54 AM, Gerhard Killesreiter wrote:
I have discussed this with Aaron and we came up with the idea to provide a scirpt that generates a flexinode content type of name "event" similar to the update script. This is why we we brought this up, this script already exists.
Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCaMHzgegMqdGlkasRAmZ1AJ41ZGTg8klg6qY5NrdL6zgBp2qyIACdFgLG S4xw8XJvo6RWyhCgm16UD/I= =DatI -----END PGP SIGNATURE-----
On Fri, 22 Apr 2005, Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22 Apr 2005, at 5:54 AM, Gerhard Killesreiter wrote:
I have discussed this with Aaron and we came up with the idea to provide a scirpt that generates a flexinode content type of name "event" similar to the update script. This is why we we brought this up, this script already exists.
Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it.
I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
Boris mailed me about this "problem". I really do not want to re-introduce a new (old) event type. If Bryght wants to have a simple module for events I suggest treating story.module with sed -e 's/story/basicevent/g'. We could put the result into a subdirectory of event module. Cheers, Gerhard
On 22-Apr-05, at 3:11 AM, Gerhard Killesreiter wrote:
I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
Boris mailed me about this "problem". I really do not want to re-introduce a new (old) event type. If Bryght wants to have a simple module for events I suggest treating story.module with sed -e 's/story/basicevent/g'. We could put the result into a subdirectory of event module.
It's not quite the same as story. It would have the location field, just like the existing event module, and be "event-enabled" by default. And it's not just Bryght....I'm thinking about all the users out there right now that have the event module installed, and don't use flexinode today (never mind any arguments about the complexity of flexinode -- theming it, and so on). Even with CCK, I can see the utility of having a pre-defined "basic" event type. For instance, we'll likely add some other views to it, like a tabular view of an entire year's worth of events (which is something that has been oft requested). -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
On Fri, 22 Apr 2005, Boris Mann wrote:
On 22-Apr-05, at 3:11 AM, Gerhard Killesreiter wrote:
I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
Boris mailed me about this "problem". I really do not want to re-introduce a new (old) event type. If Bryght wants to have a simple module for events I suggest treating story.module with sed -e 's/story/basicevent/g'. We could put the result into a subdirectory of event module.
It's not quite the same as story. It would have the location field, just like the existing event module, and be "event-enabled" by default.
We've been discussing removing the event node type for about half a year. I think it is now a little bit late for changes. As I said: Create a basicevent.module, and put it into modules/event/basicevent. Cheers, Gerhard
On 22 Apr 2005, at 11:20, Adrian Rossouw wrote:
Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
I'm skeptic as well. A dedicated node type sounds a lot easier to work with (but has its limitations). How is this going to work in terms of the CCK? Is there going to be an 'event field' which you can extend node types with? -- Dries Buytaert :: http://www.buytaert.net/
On Apr 22, 2005, at 12:38 PM, Dries Buytaert wrote:
On 22 Apr 2005, at 11:20, Adrian Rossouw wrote:
Since flexinode is a very usefull and popular module, I don't think it is a problem to depend on it. I think it's a big problem to depend on it. Flexinode is incredibly complex for what we are trying to do. Most of the sites we develop don't use flexinode, and until some form of node caching is in core, I don't believe we should depend on it for functionality like that.
I can understand if there are caching issues with flexinode, but in terms of complexity, I think flexinode is an incredibly easy to use module - both simple and powerful.
I'm skeptic as well. A dedicated node type sounds a lot easier to work with (but has its limitations).
How is this going to work in terms of the CCK? Is there going to be an 'event field' which you can extend node types with?
Perhaps a dedicated node type is an interim solution, but it is VERY limiting. As an example of what can be done by using flexinode/event: I am currently developing a site where the client wants visitors to be able to signup for (paid) workshops and classes. I created a flexinode content type with fields for things like 'presenter', 'subject', 'additional info', and whatnot. Then I configured this node-type to receive fields from event.module and location.module. We can then use the ecommerce "product" tab to add price and inventory management (workshop capacity) to this geocoded, date-tagged node! And it shows up on the calendar, on the product page, and is searchable by location. Very powerful! Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is. -Jeff Robbins aka jjeff
Perhaps a dedicated node type is an interim solution, but it is VERY limiting.
not limiting at all. see below.
As an example of what can be done by using flexinode/event: I am currently developing a site where the client wants visitors to be able to signup for (paid) workshops and classes. I created a flexinode content type with fields for things like 'presenter', 'subject', 'additional info', and whatnot. Then I configured this node-type to receive fields from event.module and location.module. We can then use the ecommerce "product" tab to add price and inventory management (workshop capacity) to this geocoded, date-tagged node! And it shows up on the calendar, on the product page, and is searchable by location. Very powerful!
a very fine example - thanks.
Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is.
a dedicated event node type would be an *option* for people who just want to add events to their site in a quick, easy way. noone is talking about precluding other node types from becoming events.
On Apr 23, 2005, at 6:48 AM, Moshe Weitzman wrote:
Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is.
a dedicated event node type would be an *option* for people who just want to add events to their site in a quick, easy way. noone is talking about precluding other node types from becoming events.
Oh. Okay. Nevermind. ;-) -jeff
On 23-Apr-05, at 3:48 AM, Moshe Weitzman wrote:
Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is.
a dedicated event node type would be an *option* for people who just want to add events to their site in a quick, easy way. noone is talking about precluding other node types from becoming events.
Exactly. It's not a move backward, it's an easy option for basic uses *and it still ties into the event API*. I still maintain that the current event module is actually eventapi.module, but I'm not going to worry about naming issues. We'll go ahead and build a basic event module plus update.php which should ease migration. -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
On Sat, 23 Apr 2005, Boris Mann wrote:
On 23-Apr-05, at 3:48 AM, Moshe Weitzman wrote:
Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is.
a dedicated event node type would be an *option* for people who just want to add events to their site in a quick, easy way. noone is talking about precluding other node types from becoming events.
Exactly. It's not a move backward, it's an easy option for basic uses *and it still ties into the event API*.
I still maintain that the current event module is actually eventapi.module,
Yes, nobody is debating that. It was the Grand Plan(TM) to make event.module an API.
but I'm not going to worry about naming issues.
Great!
We'll go ahead and build a basic event module plus update.php which should ease migration.
Could you integrate this into the existing update.php script? That is, if you agree to distribute your module as a subproject to the API. Cheers, Gerhard
Sorry to weight in late on this. My only concern is that Event module has been in the works for many months and we are hoping that it will spawn a large amount of additional module development around events based applications. There are lots of encouraging prototypes and designs being proposed. I think we need a clear vision of which event concept is going to win in the end. The risk is that we see two types of additional development going forward, development build around flexinode/CCK and development around event as it's own node. If we do get competing event development communities this is going to cause problems. Can we agree that the event API module is the path for additional development and the new eventnode is a stand alone module? Cheers, Kieran On Apr 23, 2005, at 11:54 AM, Gerhard Killesreiter wrote:
On Sat, 23 Apr 2005, Boris Mann wrote:
On 23-Apr-05, at 3:48 AM, Moshe Weitzman wrote:
Let's be sure that we don't inadvertently limit that with a narrow view of what an "event" is.
a dedicated event node type would be an *option* for people who just want to add events to their site in a quick, easy way. noone is talking about precluding other node types from becoming events.
Exactly. It's not a move backward, it's an easy option for basic uses *and it still ties into the event API*.
I still maintain that the current event module is actually eventapi.module,
Yes, nobody is debating that. It was the Grand Plan(TM) to make event.module an API.
but I'm not going to worry about naming issues.
Great!
We'll go ahead and build a basic event module plus update.php which should ease migration.
Could you integrate this into the existing update.php script? That is, if you agree to distribute your module as a subproject to the API.
Cheers, Gerhard
On Mon, 25 Apr 2005, Kieran Lal wrote:
Sorry to weight in late on this.
My only concern is that Event module has been in the works for many months and we are hoping that it will spawn a large amount of additional module development around events based applications. There are lots of encouraging prototypes and designs being proposed.
Yes, very interesting.
I think we need a clear vision of which event concept is going to win in the end.
This vision exists (as agreed to in Antwerp).
The risk is that we see two types of additional development going forward, development build around flexinode/CCK and development around event as it's own node. If we do get competing event development communities this is going to cause problems.
No, since the event.module is "only" an API, it does not care which module creates event nodes.
Can we agree that the event API module is the path for additional development and the new eventnode is a stand alone module?
That is what has been agreed on at the Event module session in Antwerp. Cheers, Gerhard
participants (10)
-
Adrian Rossouw -
Boris Mann -
Boris Mann -
Dries Buytaert -
Earl Dunovant -
Gerhard Killesreiter -
Jeff Robbins -
Kieran Lal -
Moshe Weitzman -
neil＠civicspacelabs.org