[EventCalendar] Plans the future

[Matthew Middleton]

(By the way, some messages to this mailing list aren't
making it to me, this one included.  I saw this on the
archive rather than having it arrive in my inbox.)

See my replies inline:

Alex Tingle wrote:
 >I want to eliminate the high level presentation
stuff
 >from the core  
 >plug-in, and replace them with separate plug-ins.
 >Here's a list of  
 >stuff that will go into separate plug-ins...

This is definitely a good goal for the future, but it
shouldn't halt progress in the meantime.  Instead of
focusing on rewriting all the display code to be
separate from the core, we should in my opinion be
focusing on improving the core (by adding more
flexible functions to it) to make the former task
easier.

Keeping the display code separate from the core code
does have its benefits; however, rewriting all of the
frontend code for the sole sake of separating it seems
a bit drastic and premature to me.  It seems to me
that the core calendar and event output should still
take place in the core using direct database calls. 
Doing so allows events to be easily selected and
sorted, for example.  Additionally, a plug-in might
want to display a calendar inside of the main message
loop - in a post for example - in which case starting
a second loop would not be a good idea.  Let me
address this in a bit more depth...

 >sidebar calendar
 >That's ec3_get_calendar(), the calendar widget and
 >the ?ec3_xml XML backend for Ajax
 >(Hmmm... might keep the XML output in core)
 >Upcoming events -ec3_get_events()
 >iCalendar output

These functions are basically just displaying a single
raw database query with <ul>'s and <table>'s thrown
in.  I don't see any reason to convert them to loop
code; instead if the display itself is to be
extrapolated to another plugin, an
"ec3_query_events(start_time,end_time,limit,sortby,categories,tags)"
 function could return an array of ec3_event classes -
directly from a database query - ready to be displayed
in a calendar, list, XML response or other form.

 >"schedule box" in-post summary.

This is set during the loop using a filter, so doing a
query_posts here would not be a good idea either. 
There could always be an ec3_IsEvent(id) function to
do this.

 >The core that will remain is...
 >...
 >*NEW* template functions, that make it easier to
access EC data.

Functions that return data which could be used to
trivially draw calendars and lists would be a good
idea.  Ideally, we don't want to have plugins going
through a loop of posts and attempting to manually
sort and process them with php, when the core could do
it with a simple sql query.  We should try to make it
simple to display things, not bog people down in php.

Additionally, I don't see any harm in leaving a
default interface within the core - at least for now. 
If the main plugin goes 90% of the way towards drawing
a calendar - producing an array of classes that can be
trivially turned into a table - why not go the extra
10% and add trivial code to actually generate the
table?  There is also the issue of requiring multiple
plugins - it would fragment the project and make it
harder for people to install/troubleshoot things.

(begin boring aside)
There is also the non-technical element of popularity.
 It will likely be much harder for the plugin to
become popular/successful (and thus gain more testers
and contributers) if it doesn't have a very good
default front-end interface.  The current interface,
with my patch to add extensibility, is a very good one
- by far the best available for Wordpress.  Any
separation work that is done should be purely
technical for now - we shouldn't require users to
install two plugins to execute ec3_get_calendar(). 
Consider the Mozilla Firefox example - some people at
Mozilla started decoupling the browser from the xpfe
backend way back in 2002.  This allowed for the
codebase to be vastly improved - but the old xpfe code
was left in use until Firefox was ready.  Eventually,
in the eventcalendar3 case, hopefully the backend
becomes powerful enough that the display code can be
separated whenever circumstances (such as checking the
backend into the main Wordpress distribution) warrant.
(end aside)


 >I'd like to see work like yours as a standalone
 >presentation plugin  
 >that depends upon the EC core. Rather than query EC
 >tables directly,  
 >you should be using a WP custom query, with the
 >query_posts()  
 >function, followed by a loop that implemts whatever
 >functionality you want.

While selecting by class would be easier to do with
query_posts than with raw sql, most other queries
would not be.  As I mentioned before, calendars and
event lists may happen during other loops, and it is a
lot more efficient to sort events with mysql than
by-hand with php.  Additionally, mysql processes data
a lot quicker than hand-written php.

If the ajax backend "?ec3_xml" remained in the core,
while the calendar widget itself was drawn using a
wordpress loop, for example, there would be two
different data sources for the same calendar widget. 
Using a loop for the ajax backend in the core would
not make sense, as it would only serve to slow the
page load and make the code more complex.

In my opinion, rewriting all the display code with
query_posts() would be a step backwards at this point.
   The plugin is currently quite stable and functional
with a solid foundation.  I think we should focus on
finishing the functionality of the existing interface
- which is what my patches attempt to do - while
simultaneously improving the backend to support other
plugins.  My patch basically uses the existing code
and sql queries - I just modified the internal
functions to make them more flexible.  Using
query_posts() would have resulted in quite a bit of
additional overhead and processing time, as well as
significantly more code.  If people don't like our
display code, they can simply choose not to call it in
their templates.

I have no problem with eventually separating the
display code out - I just see no reason to rush into
it.  Ideally, before removing it entirely, we would
improve the internal functions to the point where
separating them involves simply copying the remaining
functions verbatim into another plugin.  Using the
example function I gave above, an improved
ec3_get_calendar() function might rely only on
ec3_query_events() for its information.  At this
point, the display code could then be trivially
separated into another plugin if the need arose.

Let me know any ideas you have for improved template
functions, as they are desperately needed.  Ideally,
this code could be improved to the point where it
could be used as a basis for native event handling
within wordpress itself.  If the ec3 core code became
part of Wordpress, it would then of course make sense
to separate the display code into another plugin. 
Working towards this goal doesn't require the
immediate removal of functions such as
ec3_get_calendar().

Also, let me know what you think of my 'big calendar'
patch if you get a chance to look at it.  It basically
just extends the existing code and functions in
logical ways to add useful features, so it would
probably be a good idea to include at least the big
calendar part in a release.  In any case, they should
make ec3 more popular and useful.  So far, my changes
don't change any user experience or break template
code from 3.1.1rc2 - they just extend the
functionality.  Additionally, most of my changes are
quite simple in nature.

-Matthew