[EventCalendar] Plans the future

[Matthew Middleton]

(see replies inline)

--- Alex Tingle <alex at firetree.net> wrote:

> > Doing so allows events to be easily selected a
> > sorted, for example.
> 
> No. All it's doing is re-inventing the wheel.
> Wordpress has a well- 
> tested and well supported way of querying the
> database. The more we  
> try to re-invent that, the more problems we make for
> ourselves AND  
> FOR OTHERS.

Unless I'm mistaken, there is no way to sort by event
time with query_posts().  Its sort-by-time option
would sort by the time posted.

Right now, one sql query is done per calendar/list
generated.  All I did with my patch was to modify
these requests to select categories and sort by
start_time.  I didn't add any new queries.


> Elizabeth's recent problems with encodings are a
> perfect example of  
> this. My own code to query the database didn't
> properly encode the  
> text. It took a very long time and trouble before
> that was spotted.
> 
> The only way to write bug-free code is to WRITE NO
> CODE. Where  
> Wordpress already has functionality that we can use,
> then we WILL use  
> it.

It still seems to me that we need database level code
to provide functionality (sort by arbitrary fields,
obtaining a list of events during the loop, fast
generation) that is not provided by WordPress.  Of
course, you're right: this does mean more bugs and
testing.  That doesn't mean that the bugs can't be
fixed though - plenty of plugins do database calls for
increased flexibility.

If we don't provide a mechanism to query events in
arbitrary ways - other than doing query_posts() -
other display extensions will fill in the gap
themselves with database level code themselves...
which would be even worse.


> > 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.
> 
> That's a fair objection. (What follows is
> speculation, and suggestions:)
> 
> I'd suggest loading the calendar as XML and
> rendering it client-side.

That would break compatibility when javascript is
disabled, which should be avoided at all costs.  Some
people use old browsers or turn javascript off, yet
still want to see calendars.  Search engines don't run
javascript either.


> One of my main concerns about EC is the duplication
> of the calendar  
> rendering code. There's one version in Javascript,
> and another in PHP  
> - the two have to produce exactly the same results.
> The more  
> complicated the calendar gets, the harder it is to
> ensure that the  
> two versions are producing the same result.

My solution to this problem (in my patch) was to make
php do all rendering.  For the big calendar, ec3_xml
simply returns base64'd HTML for each table cell.  (I
could have just written the same display code in
javascript easily, but this was easier to test/debug)


> Perhaps we should jettison the PHP calendar builder
> code, and keep  
> the JS.

Again, we need compatibility with search engines and
browsers with javascript disabled.  It may be a
degraded experience, but at least it still works.

[snip]
 
> You are simply describing the current state of
> affairs. Long  
> experience has taught me that it's not viable.
> 
> The core code *does* offer a function for drawing
> event lists. It's  
> pretty customisable, but still people want it to do
> things that it  
> cannot. The solution is to make it easy for people
> who know PHP to  
> write their own plug-ins.
> 
> That allows people like you to come along and fulfil
> the need for  
> full page calendars (or whatever else) without
> having to disrupt the  
> core code. And then everyone else can benefit from
> your great work.

I made these template functions more extensible by
adding a category filter option, which would have been
hard to do after-the-fact in php.  (WordPress doesn't
have a getPostCategories(ID) function)

 
> As I say, I think I'd keep the ?ec3_xml interface. I
> think a JSON  
> equivalent would be good too.
> 
> The reason to NOT go the extra 10% would be to
> provide a good example  
> for newcomers, in order to encourage them to write
> their own plug-ins.
> 
> Furthermore, the less code in the core, the more
> reliable and well- 
> tested it will be.

I think I will write the new (still unwritten)
functionality I was planning on writing for the ec3
core as an additional plugin.  (See the features in my
recent message "Big Calendar features & suggestions") 
These planned features would bog down the core with
additional code, and there is really no benefit to
having those features in the core.  I might have a
plugin called "EC3 Everywhere" that allows "page tags"
to be used in pages.  The core code would still
provide things such as ec3_get_calendar(), which my
plugin will call to generate calendars.  I don't want
to have to write a plugin that does the entire job of
calendar drawing and updating just to get calendars to
display.

Providing a stable, simple function to generate a
calendar seems like basic functionality in any
calendar plugin.  There isn't a lot other extensions
could do to improve something that amounts to
"<table><tr><td><span>1</span><span>{event}</span>..."
- this is pretty basic code.

How about offloading the css and javascript to another
plugin, so they can fine-tune the basic calendar drawn
by the core?  Plugins could then use core
functionality to draw a calendar table, and then
extend it with desired features.  Of course, a plugin
could use query_posts() to manually draw a calendar
table if it wanted to do something beyond the basics -
such as listing tags in the calendar table itself. 
When using query_posts(), however, it would not be
possible to get the full flexibility of the current
ec3_get_calendar(), such as the ability to generate a
calendar inline in a post.


> You are absolutely right that the default install
> must be complete  
> and easy to use.
> 
> I agree with you, ease of use must be paramount.
> That's always been  
> my major design goal. That causes friction, because
> people always  
> want features that are not supported. A multitude of
> features (enough  
> to satisfy everyone) CANNOT be supported while
> retaining ease-of-use.  
> Hence, plug-ins.

As I said, my patch doesn't implement any user-visible
features.  All it does is add additional options to
the existing template tags to allow calendars to
display larger, for example.

The options of removing the display code from the core
pllugin and remaining "complete" seem to be mutually
exclusive.  In this case, would two plugins be
required to do ec3_get_events()?  More plugins isn't a
good answer to the average user - who wants all the
basic functionality provided by a single plugin.


> > 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.
> 
> No, it will make the code simpler. That's the whole
> point. If things  
> get more complicated then I'm wrong.

Again, I don't see any way of sorting by start_time
with the loop.  Doing that would make the code
simpler, but XML requests should be as fast as
possible to make the ajax experience good.  Simple is
better, of course, but we can't take any steps
backward to get there.


> > 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
> 
> No, there's no "finishing the functionality". People
> will always want  
> more and more and more features. The problem is to
> define a framework  
> that can accomodate that ever expanding desire for
> features.

Allowing a full-page calendar to be displayed is what
most people would consider core functionality in a
calendar plugin.  It is really just a small extension
of the existing code.

The 3.1.1rc2 release has nearly all that is required
to draw a big calendar, with the few logical
extensions that I provided.  I don't see any reason to
omit this functionality, since it is a popular and
useful feature with the community.  It would be nice
if a cleaned-up version of my patch could go in a
"3.2" release, before the rewrite/simplification
happens, to provide this functionality on the existing
codebase.  WordPress is much more than blogging
software now - it is commonly used as a complete CMS. 
Displaying a big calendar is something that most CMS
programs - including Wordpress - should do.  (hence
why I wrote the patch to provide it)

Once a leaner, meaner EC3 with equivalent
functionality is available (with your separation of
the display code), then new plugins can start to build
on top of that and its functions.  It seems that at
the moment we should move forward with what already
exists, to provide users with things such as full page
calendars now.  (Back to the Mozilla analogy...
consider how Mozilla went ahead with Firefox 2 based
on the 1.8branch rather than on the trunk
improvements)  Doing so will provide a better user and
developer base for the future.

-Matthew