UNL Event Publisher Rewrite

[Brett Bieber]

Greetings,

I'd like to open up some discussion about a rewrite of the UNL Event
Publisher and where I'd like to see the project go.

First I'd like to share where we're at:

* There are at least 10 institutions using the system, which is fantastic.
* Development has slowed over the past 5 years (this could be viewed
as a bad thing, but I view it as maturity).
* External contributions has been very low, with notable exceptions
such as: a simplified installer and recurring event support.

Now, the problems I have with the current codebase, and why I'd like
to begin a rewrite:

* High dependency stack.
* Aging dependency stack with poor support for PHP 5.3 advancements.
* Some code (including markup) is in the backend models (manager
portions, for forms etc).
* Models implementing ORM are used both as collections and single objects.
* Poorly supported social coding environment (google code).
* UNL specific in many cases.

Finally, what I'd like to see happen.

This rewrite would target complete compliance with existing databases,
and would be a drop-in replacement as far as that is concerned. As for
templating, the frontend, and manager templates would need to be
modified slightly. The work would be split into three phases.

First phase, backend & model development:

* Move codebase to a platform that supports more social coding
(GitHub) (backend is at https://github.com/unl/UNL_UCBCN).
* Rewrite the models using a slimmer ORM instead of DB_DataObject.
* Remove DB_DataObject_Formbuilder
* Add separate objects/models for collections so they can be
templated separately.
* Improve testing and reach over 85% coverage.
* Remove require_once statements and move to a PSR-0 compliant
codebase for better autoload support

Second phase, frontend/viewing calendar data:

* Develop templates for "Mock U" a mock university/college
* Re-architect frontend templates using Savvy/Savant4
* Use an HTML5/responsive design so separate mobile templates aren't needed
* Utilize a router in PHP so all sites use clean URLs instead of just
those using Apache

Third phase, event submission/modifying calendar data:

* "Mock U" authentication?
* Re-architect manager templates using Savvy/Savant4
* Convert FormBuilder forms into static forms so they're easier to customize

(Fourth phase? CalDAV frontend? Your ideas?)

I've already moved the backend code to GitHub, and would encourage
people to look there to contribute - https://github.com/unl/UNL_UCBCN
I plan on moving away from GoogleCode once the rewrite is in
full-swing and we have alpha or beta installs available.

Does anyone have any thoughts on this proposal, or would anyone like
to help — even if it's testing once we're ready for that? It would
also be great to hear your 'pain points' and know if there are any
specific problems you'd like included in a rewrite.

Thanks,

--
Brett Bieber
University of Nebraska-Lincoln

[Nathan Kern]

Recurring events functionality will improve as more browsers code for
the <input type="date"> element in HTML5. In the mean time, I feel
like jQuery would be an easier approach for having date-pickers and
modal dialogs. I also like the idea of replacing
DB_DataObject_Formbuilder and using GitHub for hosting.

I should note that the functionality of recurring events seems to have
been broken since my last commit (as of the last time I checked).

Nathan Kern

> (GitHub) (backend is athttps://github.com/unl/UNL_UCBCN).

>  * Rewrite the models using a slimmer ORM instead of DB_DataObject.
>  * Remove DB_DataObject_Formbuilder
>  * Add separate objects/models for collections so they can be
> templated separately.
>  * Improve testing and reach over 85% coverage.
>  * Remove require_once statements and move to a PSR-0 compliant
> codebase for better autoload support
>
> Second phase, frontend/viewing calendar data:
>
>  * Develop templates for "Mock U" a mock university/college
>  * Re-architect frontend templates using Savvy/Savant4
>  * Use an HTML5/responsive design so separate mobile templates aren't needed
>  * Utilize a router in PHP so all sites use clean URLs instead of just
> those using Apache
>
> Third phase, event submission/modifying calendar data:
>
>  * "Mock U" authentication?
>  * Re-architect manager templates using Savvy/Savant4
>  * Convert FormBuilder forms into static forms so they're easier to customize
>
> (Fourth phase? CalDAV frontend? Your ideas?)
>
> I've already moved the backend code to GitHub, and would encourage

> people to look there to contribute -https://github.com/unl/UNL_UCBCN

[University of Central Florida Web Communications Team]

Hello Bret,

We've been using a modified install of the UNL Events System at UCF
since June of 2010 (http://events.ucf.edu). The system that it
replaced had been running for over 6 years without any significant
feature updates or maintenance.

While the UNL system was a great leap forward for us, it didn't meet
all of our needs. We have made some significant modifications to the
system including writing an iCalendar format importer and largely
stripping out the permissions system.

We've recently been evaluating what the way forward is for us in terms
of an events system. We are finding the current system difficult to
maintain and extend for many of the reasons you listed. To list
specific "pain points":

- FormBuilder forms are incredibly difficult to work with. If it were
up to us, that would be the first thing to be changed.
- The documentation, specifically about the data model, is pretty thin
- PEAR reliance
- Auto-creation of calendars on login
- Lack of user management
- Messaging and notifications
- No Social networking integration

While we have been evaluating commercial offerings, we've also been
discussing writing a system in-house. Our proposed system would most
likely utilize the Python programing language in conjunction with the
Django Web Development Framework; this will help us address some of
the issues you've described in the current system as well as speed up
the development process.

How far along are you in the rewrite process/phases you described in
your email?

We look forward to learning more about your plans/progress and
potentially collaborating on system architecture design and
development.

Sincerely,
The Web Communications Team
University Marketing
University of Central Florida

[Brett Bieber]

On Mon, Oct 3, 2011 at 10:03 AM, University of Central Florida Web
Communications Team <ucf...@gmail.com> wrote:
>
> We've recently been evaluating what the way forward is for us in terms
> of an events system. We are finding the current system difficult to
> maintain and extend for many of the reasons you listed. To list
> specific "pain points":
>
> - FormBuilder forms are incredibly difficult to work with. If it were
> up to us, that would be the first thing to be changed.

Yep, that's on the list for the 'event manager' portion.

> - The documentation, specifically about the data model, is pretty thin

The data model is all taken from UC Berkeley's information, which is
very detailed, and based on a lot of research. That's available here:
http://groups.ischool.berkeley.edu/EventCalendar/

> - PEAR reliance

Agreed. Reducing the dependency stack is a big goal of mine. But,
installation without PEAR from an SVN checkout or tarball download has
been working for about 2 or 3 years now thanks to contributions from
Brian Steere at Cornell College.

> - Auto-creation of calendars on login

This would be something to target for the manager rewrite once the
backend is finished.

> - Lack of user management

Right, users and permissions are very basic right now within the
manager... and there's no real "Admin" interface.

> - Messaging and notifications

Great point. Are you talking about the public/frontend portion, or
something within the event management?

> - No Social networking integration

Facebook integration is available in the repository, since December of
2010. What other platforms would you be interested in support for?

> While we have been evaluating commercial offerings, we've also been
> discussing writing a system in-house. Our proposed system would most
> likely utilize the Python programing language in conjunction with the
> Django Web Development Framework; this will help us address some of
> the issues you've described in the current system as well as speed up
> the development process.
>
> How far along are you in the rewrite process/phases you described in
> your email?

Just in the beginning phases. Tests have yet to be written, and all
we've completed is ripping out the DB_DataObject dependency. The next
item is iterators for collections which shouldn't take that much time.

> We look forward to learning more about your plans/progress and
> potentially collaborating on system architecture design and
> development.

Sounds great. Thanks for the feedback.