CCK Field / Views support

[mrconnerton]

So my vision here was when the user created a new "event" content type, this widget would have a list of all the events in their eventbrite account that they can select from. Select list, auto complete, etc (I'm not a UI guy)

From here, we can pull in the event information / sync data to or from eventbrite.

In views, the goal is to make it compatible with the primary calendar module. I was starting to look into the date module to use the dateapi for field support/widgets.

[bmann]

We can probably do auto complete on event title and retrieve from the API.

But, we were more focused on actually creating events directly in Drupal, and then posting them to Eventbrite.

[dtarc]

From my impression these are two different UI modules:

The vision that Matthew has, building on the current module, would be a light weight way of plugging Eventbrite events into Drupal, while still taking care of event configuration on the Eventbrite site.

The plan that Boris has laid out would mean that after getting an initial API key from the Eventbrite server, almost all configuration could be done from within Drupal.

These would both use the same API module to communicate with the Eventbrite server, but users would choose which UI module they want to enable and use.

Another UI module would be the current feature set of the Eventbrite module--pulling all user events in and building 5 blocks for each. This has been set up in a sub module called Eventbrite Blocks and currently works the same as the 1.x module. This will allow users happy with the legacy functionality to help us by testing the API.

I see either UI module proposed as being useful for different kinds of sites, but they are very different use cases.

[mrconnerton]

I agree, my ultimate goal was to have complete control over eventbrite from drupal, but was afraid that some people would be looking for something simple in the beginning. And as it was/is my first time hooking cck, I figured I would start small as well.

So here are my questions:

1. The widget that syncs with eventbrite, do you plan to have some sort of field mapping for title-title, body-description, or are you going to handle ALL the eventbrite fields independent from the basic node fields?

2. If we do create two widgets, one for just pulling data, and a second for complete sync control, I would l like it to be very easy to just switch from the basic to advanced widget (and back) so they start using the advanced options whenever they want.

3. Do we need to create two widgets or just one widget that has a "sync" checkbox that will expand/ahah the cck widget into advanced mode or back? Then on they fly they can sync their data, desync their data, all in one widget.

[bmann]

I think the widgets always have to sync. The exact way the mapping works is something we have to do a prototype for and test. The goal is to have all the event data available in Drupal.

Actual event mapping is just one use case -- the user registration for a big conference is much more interesting (and it would only be one event). So that is about syncing attendees.

Cut and pasting embed codes is a fine way of integrating today, so I think we can skip that use case. I need to post some of my high level use cases, but most of it is around deep user registration or mass event listing, where you don't want to do it manually.

[bmann]

Here's my high level use cases page: http://github.com/affinitybridge/eventbrite_drupal/wiki/High-Level-Use-Cases

[dtarc]

1) The widget that syncs with eventbrite, do you plan to have some sort of field mapping for title-title, body-description, or are you going to handle ALL the eventbrite fields independent from the basic node fields?

This is a good question. I don't think there will be field mapping. I think that a node type that has a complex eventbrite cck field will allow for multiple events to be attached to a single node, and we so we cannot map between title and body.

Having events as fields rather than as nodes gives a UI advantage to users using the site. However, it does not allow us to leverage a lot of what Drupal, CCK, and Views does out of the box. Having events as module-defined nodes using CCK fields to hold event data would allow us to hook into all of that already. Views integration, rules integration, all of that would be running immediately.

Module-defined nodes are less common these days but it seems like that would produce a workable UX. Node references are pretty well supported now and there are widget modules that would allow for creation of referenced nodes on the fly. So, if there is a page node type that contains a noderef field pointing to event node types, users could create the event at the same time that they create the page. This would have the added bonus of being closer to the fieldable entities setup coming in Drupal 7.

Having events as fields only (ie not as nodes) means we'll be writing code to support each subfield.

2) If we do create two widgets, one for just pulling data, and a second for complete sync control, I would l like it to be very easy to just switch from the basic to advanced widget (and back) so they start using the advanced options whenever they want.

I'm not sure how easy it will be to switch back and forth. Are you talking about per-node here or per site? If a site wants to move up to the more advanced features I would think that would involve enabling a new module--but yes we would not want to lose previous data.

3) Do we need to create two widgets or just one widget that has a "sync" checkbox that will expand/ahah the cck widget into advanced mode or back? Then on they fly they can sync their data, desync their data, all in one widget.

Seems like two separate widgets to me.

[mrconnerton]

I understand your logic on create event nodes, with cck to hold the data. My only objection would be that the user could then mess up their module and break updates.

Do you think its possible that we could do a hook_form_alter on the cck config fields, tables, etc to prevent the user from editing those fields? Like when you view the default ields on a node they show up dulled out. I think that would be the solution and then we can rock and roll.