Current model for Events and Calendars

[dcinzona]

Our model uses event categories, to associate an event to a calendar (or multiple calendars). This helps reduce duplication of events, as you can give an event multiple categories and have the calendar display select categories to filter out the events.
This could be done multiple ways, but we created an event category record table, instead of using taxonomies or tags to categorize the events. We designed this so that when you create a calendar widget, you select the calendar you want, and when you create a calendar, you select the event categories to display.

This way you could create a "Holidays" event and display it in multiple calendars, instead of having to do it for each one. Same goes for other shared event types like "Office closures", etc.

Does this make sense? Is it too late to alter the model to support this?

[jeffolmstead]

It's never too late to alter the model :) - early stages. The only question in my head is whether this is a display issue (in which case it could be handled by a separate feature as some users might just want to use taxonomies / tags with projection to accomplish their goals while, on a complex project as you did, having the separate dedicated event tags really helped out in the process. My gut says this would be a feature within the module. What do you think?

[dcinzona]

I'm ok with this as a feature. It definitely handles the display, but it's also used for association and editing, so it's deeply embedded into the admin UI - i.e. when viewing the Calendar Events list in the admin ui, I can show events that are only visible in a specific calendar. This filter would be optionally visible if the feature is enabled.

Here are some screenshots:
Calendar index:

Events Index:

Categories index:

Event Edit:
(The address portion uses Google Maps API calls to auto-lookup addresses. Addresses can also be saved)

The events edit page also includes content permissions to allow events to be private.

[jeffolmstead]

If we can accomplish that type of control it would be awesome. Having looked over everything the one that doesn't seem doable (now) is the "private"... Maybe that can be done with different content types as opposed to having a single type of event be either private or not private (i.e. carry the security on the content type). The other argument would be to abandon Projections... man, that is a big jump. I guess it isn't unprecedented, Taxonomies does it. I can definitely see why you went this route, it is a lot cleaner. Do you have more arguments for avoiding the projections?

Side note, what WYSIWYG editor are you using that supports "Preview Theme" - looks interesting.

[dcinzona]

The preview theme functionality is just an addition to the ckeditor module. Basically, it reloads the editor with CSS from whichever theme is specified there.

Regarding avoiding projections... I don't really have any reasons to avoid projections other than projections don't take into account content item permissions, so if something is marked as private using the content permissions module, it will still show up in a projection.

[jeffolmstead]

presumably a user could filter the query by "private = FALSE" or we could add a query filter that did that (i.e. Event Is Private). Ok, so that is good to know. Personally, I love having the "Event Categories" being a feature of this module and functioning like a Tag. I really don't like it when you want to have unique tags by a content type but then those tags are shared across ALL blog posts, pages, whatever. I just hate the maintenance of having a separate "Tags" feature. Do you think we should approach it differently and try to alter the native Tags functionality? I mean, if we had a "Tag Type" option on Tags, then we would get all of the functionality without needing to maintain this "Event Categories" I know, yours is a lot cooler as it sounds like we can have colors associated with the "Event Categories" but throwing it out there as something less to maintain (and would really make the Orchard Tags module more useful). If you feel it isn't a big deal to maintain "Event Categories" then let's bake them right in. Thanks for bringing this up!

[dcinzona]

My only hesitation really with using tags is preventing user error... what if a user who has edit tag permissions deletes it? Also, isn't Tags deprecated?

[jeffolmstead]

well, if Tags was expanded with a "Tag Type" then permissions could be set by "Tag Type". In other words, you could have a "Tag Type" of "Event Categories" and the site administrator could set permissions on this Tag Type separately (or leave as is and permissions are inherited. This would allow control of the selection / usage of those particular tags. It could also prevent them from being used on other content types as each content type could have a Tag Settings where you pick your Tag Type (or leave as Default for all Tag Types). If Tags are deprecated though I agree with you, let's not waste any time there. However, I have not heard of any plans for it to be pulled out. Your call though, Orchard is always a balance, want to keep extensible but also want easy to use. I believe your method is easier to use while I believe using native features keeps it more extensible.

[dcinzona]

I thought they had mentioned it before (regarding the deprecation). They recommended using taxonomies, but regarding when it is actually removed...probably never ;).

[jeffolmstead]

ok, that is interesting and kind of makes sense as taxonomies now allows you to add terms dynamically. Well, I don't know, you could argue we could have an Event Categories taxonomy type that was created in migration and serves as the basis for your feature. It could then have a field (emulated via the color picker field) that allows you to select the color and you could add anything else on the event you wanted. Security could be controlled that way also. Maybe that is best as long as it doesn't take long to adapt your logic.

[dcinzona]

Yeah, the taxonomies is actually kind of interesting if, let's say, we want to add a particular event category for term type of RSVP in the future... taxonomies may add more flexibility that hard typing event categories.

[dcinzona]

Actually, ignore that... I don't think there will be a category type of RSVP that couldn't be handled by the standard category model

[jeffolmstead]

And we don't have to maintain it for every change that comes along. I like the example you give though, when combined with Projections it could be powerful. In other words, maybe you have two event categories that you want on an event (i.e. two ways of classification). By using taxonomies, could make a new taxonomy, attach it as a field, and update your calendar projections. This makes me think that the "Color" of the actual calendar event should be implemented via an interface. Then your feature could implement "IEventColorProvider" and have it determined by a "EventColorPart" that could be attached to the Taxonomy Term and thus those taxonomy terms would end up providing the color to the Event. Also, if IEventColorProvider accepted a class to be returned, could incorporate "Color" and "Weight" with the highest weighting winning. This would then work well with a "DefaultEventColorProvider" which could implement this interface and provide the default color.

[jeffolmstead]

In regards to your last comment, maybe not, but it does stay more flexible should something come up. See my notes.

[dcinzona]

Agreed, taxonomies does provide this flexibility, especially with projections. Another example would be if you had a dashboard type area that you wanted to show all RSVP events that the user is invited to visit. This is a fairly common scenario and there are two types of RSVP events to return:

• A private event where the user is specifically invited
  • This can have two scenarios, where the user is invited due to some business logic (i.e. membership role) or the user is invited by manual selection (i.e. user id).
• A public event where everyone is invited

[Devqon]

When talking about categories, I would definitely choose for the usage of Taxonomies. I would rather not choose for re-inventing functionality, where Orchard already has a lot to provide. Therefore I would opt for making use of an event category field of the type TaxonomyField, which seems like a nice addition to the calendar.

Regarding projections, I actually don't see if there are any use cases where you want to display a fine-grained selection of events, other than categorized and permissionable. Therefore we might need to consider to indeed abandon the projection usage, and instead build the query ourselves.

[dcinzona]

Sounds good to me