RE: [armstrong] Publishers using Armstrong CMS

[Brian Wheeler]

Charlottesville Tomorrow is another site that has just implemented the Armstrong CMS.  We launched the new site in July and plan to share our new code modules (e.g. events) with the user community shortly. 

 

http://www.cvilletomorrow.org/page/technology

 

Brian

 

 

Brian Wheeler, Executive Director
Charlottesville Tomorrow
P.O. Box 1591
Charlottesville, VA 22902
bwhe...@cvilletomorrow.org
tel: 434-260-1533
www.cvilletomorrow.org

www.cvillepedia.org

 

 

 

From: armstr...@googlegroups.com [mailto:armstr...@googlegroups.com] On Behalf Of Marco Rohner
Sent: Wednesday, October 10, 2012 8:07 PM
To: armstr...@googlegroups.com
Subject: [armstrong] Publishers using Armstrong CMS

 

I have followed Armstrong CMS since 18 months now. Also signed the letter of intent. What are the real world examples so far beside tribune and citizen? I'm really interested in specific cases so see how it Armstrong developed and join you. 

[Brian Wheeler]

We make heavy use of the events module, but less so with recurring events/series.  When we need them it has worked fine.  Here is a screen shot of that part of the event entry form with one of our only examples, a weekly radio show.

 

Brian

 

 

 

 

 

 

From: armstr...@googlegroups.com [mailto:armstr...@googlegroups.com] On Behalf Of J. Heasly
Sent: Saturday, February 23, 2013 2:03 AM
To: armstr...@googlegroups.com
Subject: Re: [armstrong] Publishers using Armstrong CMS

 

Hi Brian,

How do you like the events portion of Armstrong? Is it easy/possible to enter recurring events? And/or those the recur on irregular patterns? I visited http://www.cvilletomorrow.org/ but couldn't find a event submission form for clues as to handle these types of situations.

 

Thanks in advance for any info you can provide.

 

Thanks,
John

--
You received this message because you are subscribed to the Google Groups "Armstrong News Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to armstrongcms...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[J. Heasly]

Hi Brian —

The screenshots really help. Thanks!

1.) So if you did select a Repeat option of "Monthly (Example: 3rd of every month)" and it was the 10th, say, how do you tell Armstrong that?
2.) Are there pre-built repeat patterns that come installed with Armstrong? Can you define your own? (I wonder if it uses Gustavo Niemeyer's handy python-dateutil rrule ... )

Thanks again,
John

[Brian Wheeler]

Afraid I’m just the end user… so I can’t answer these follow-ups.  Our developer may be watching this thread and he might be available to chime in.

 

Brian

 

From: armstr...@googlegroups.com [mailto:armstr...@googlegroups.com] On Behalf Of J. Heasly
Sent: Sunday, February 24, 2013 2:29 PM
To: armstr...@googlegroups.com
Subject: Re: [armstrong] Publishers using Armstrong CMS

 

Hi Brian —

--

[Paul Bailey]

Here is the event module I developed:
https://github.com/pizzapanther/armstrong.apps.calendar

And to answer you questions:

1) When you repeat events, it will create an event for the interval you select.  All these events are linked together.  Now when you update an event in that series you get to choose, whether you update the series or just that event.  So you could repeat events on the 3rd of the month, and then change one to the 10th.  Or you could create a new event on the 10th and add it to the series.

2) Right now the patterns are pre-built.  See line 182 at:

https://github.com/pizzapanther/armstrong.apps.calendar/blob/master/armstrong/apps/calendar/admin.py

[J. Heasly]

Hi Paul,

So if you had an event that was, say, the third Thursday of each month, the way you'd probably enter it here is to pick a repeat pattern of monthly and then an end date of the run. And then go into each month and move the event to the third Thursday and save? Then you'd have a series that "knows" about other series-mates. So looking at models.py, it seems the Series members are just Event instances ForeignKey'd to one other Event, right? Do the date relationships have to run parallel to the ForeignKey relationship

Thanks for your help/explanation!

John

p.s.: Have you seen the rrule feature of python-dateutil?

[Paul Bailey]

You could do the repeat event exactly as you stated, but I was actually going to make that rule up for that case but never did it.

Events in a series are just linked by a foreign key field like you stated.  So the repeat dates can have a pattern or not.

Never tried the rrule feature out, but I'll check it out. 

[J. Heasly]

One last question: I can't quite get my head completely around the Series model; does the series get created in a one-to-one kind of chain?

i.e. a conceptual Series sketch might look like this: [Jan. 1 event] -FK-> [Feb. 1 event] -FK-> [March 1 event]

The above ordered left to right by database row ID. If the above is a more-or-less illustration of the concept, does it matter/is it possible if it (somehow) got created like:

 [Jan. 1 event] -FK-> [March 1 event] -FK-> [Feb. 1 event]

Again, ordered by row ID. I suppose even if it did, you could get in "proper" calendar order by doing a SORT BY on the date?

[Brent]

Hey J. Heasly,

I haven't been following this thread real close and I haven't looked at any of the armstrong packages lately, but back when I was looking for events, Armstrong didn't have a public packages that had recurring events, iirc. So I started looking around and django-schedule had that best data model that I found, however the templates, etc were pretty bad, so I created my own branch (https://github.com/epicserve/django-schedule/tree/dev).

The thing I like about django-schedule is that with events only one record gets created in the DB for a recurring event, unless you make a change to an individual occurrence or date that is different from the parent recurring event. At the time this was the only package that had this kind of a data model.

--Brent

[Paul Bailey]

The series field is the same for all events in a series, usually the first event created.  So it would look something like this:

[Jan. 1 event ] -FK-> event 1

[Feb. 1 event] -FK-> event 1

[March 1 event] -FK-> event 1

So it is kind of weird that the first event is linked to itself, but it makes querying the events in a series really easy.

Then if you need to add an unconventional event to the series, no problem, you just choose "event 1" as the series.

[Paul Bailey]

So while having less data with Django Schedule is awesome, it makes it really hard to query events over time because you always have to calculate repeat events.  So it can slow down your views a lot.

It is better to repeat the data like in my model because you then can make faster and easier queries.  The data size will not really be an issue if you are storing text.  We have thousands of events, articles, and places at http://houston.culturemap.com/ and our database is still only like 100MB.  So while as an engineer it feels bad to be repeating data, it is much faster this way.

The added benefit of this model type is that now you can also just update one event, in a series.  For a example, at a theatre, say they cancel one show.  No problem, just edit that one event and leave the rest of the series alone.

[Brent O'Connor]

So your saying that it's faster to have more data in the Database than to calculate events in python code using an iterator?

How do you handle an event that doesn't have an end date?

With Django-schedule, if I want to delete/cancel a single occurrence it's easy, it just adds an event in Occurrence table with the cancelled field set to True.

--Brent

--

[Paul Bailey]

So that is the one downside, the event series has to have an end date.  But in that case, you can repeat it so far in the future that it doesn't matter.

And yes i'm saying it is faster to to query the db then calculate the in python.  Here is why.  Say you want all the events for today.

Django Schedule Model:  Find all possible events that might repeat over today.  Calculate which ones fall on today, show thoses.

Armstrong Events Model:  Do a query for today.

You can see with the Schedule model, you could possibly querying more events and calculating for them all.  For the Armstrong method, you just get the data and that is it.

Lastly for the occurrence table.  That works nicely but again it slows your code down.  In addition to the calculations, now you have to do a join to see if there are any overrides.  So in my experience the data size is not what you need to optimize for.  It is usually the joins and the calculations that can really slow you down.

I know it is not the most optimized method of storing data, but if you have a lot of events on one page, using the Schedule method can get slow very quick.

[J. Heasly]

Hi Paul —

Thanks for taking the time to elaborate on the under-the-hood differences of the two approaches. Pretty interesting.

FWIW. for anyone that comes across the thread, in addition to Brent's django-schedule fork above, there's an outfit near Sydney, the Interaction Consortium, that's done a lot of work on a django-schedule data model-based event calendar, glamkit-eventtools. It's part of a larger effort, GLAMkit, a free, open-source content platform for Galleries, Libraries, Art galleries and Museums (hence, GLAMkit).

— John

[J. Heasly]

p.s.: Make that Galleries, Libraries, Archives and Museums (hence, GLAMkit)

[J. Heasly]

Also, I just learned that GLAMkit eventtools uses the Armstrong Events record-per-event method (as opposed to the django-schedule Event/Occurrence approach. GLAMkit eventtools started out as a django-schedule fork, but about a year and a half ago it was re-written to use the record-per-event approach. 

According to the Interaction Consortium's Greg Turner, besides the above performance improvement, with a saved instance, you also get an ID for each event iteration, so you can then have discrete URLs for each event. Also, with a generated Occurrence, you can't easily have a Foreign Key to that Occurrence from anything.

— John