[geeklog-devel] [geeklog-cvs] Geeklog-1.x

Joe Mucchiello joe at ThrowingDice.com
Tue Nov 27 22:49:33 EST 2007

At 01:11 PM 11/26/2007, Dirk Haun wrote:
>Which is the whole point of me pushing to stop adding new features and
>finishing what we have started elsewhere. You should have no problems at
>all to find quotes for my position on that ... Plus a few where I argued
>that we should try and move to a shorter release cycle.

This is my last attempt, I promise. I've beaten this bloody, vaguely 
horse-shaped spot so hard because I don't see any upside to waiting 
for 1.5.1 but I see plenty of downside.

1.5 breaks several API interfaces. This means few 1.4.1 plugins will 
be 1.5 compatible without upgrades. The template library breaks 
sloppy order of calls to the template class. This means many plugins 
are not compatible out of the box with it. If you delay the template 
library to 1.5.1, users will be forced to upgrade there plugins when 
moving from 1.4.1 to 1.5 and 1.5 to 1.5.1.

Dirk, you want to shorten the release cycle. If you shorten the 
release cycle, that puts extra burden on the admins of those Geeklog 
sites. I would think it preferable to break the plugins only once and 
perhaps have a quick upgrade after 1.5 where plugins (for the most 
part) don't need to be updated and thus don't add to the burden of 
upgrade. I'm sure the plugin authors will prefer not having to 
release upgrades twice because Geeklog's core changes underneath them.

How about some plugin authors chiming in here? Or admins with a 
several Geeklog sites? The upside to extra hassles over the next two 
upgrades is 1.5 comes a few weeks sooner. I don't see how that's an 
even tradeoff.

Taking full advantage of the new template library will take time. 
Delaying the library also has the downside of not having stuff like 
this in Geeklog. Below is a code snippet from ADMIN_list that I've 
modified. There is no HTML in the code snippet. There are a lot fewer 
IFs in the code snippet. There are a lot fewer temp variables in the 
code snippet. Yes, the template file is a lot more complex. Arguably 
the onclick HREF might belong in code. Still this doesn't go far 
enough. With set_block, most of the files in the admin/list directory 
should go away. But I didn't want post hundreds of lines of code to the list.

Okay, I've said my peace. I'm done.

<!-- this is admin/list/header.thtml -->
<th class="{class}" nowrap="nowrap"
{!if sortable}
{!if chk_delete}
    <input type="checkbox" name="chk_selectall" 
title="{$LANG01[126]}" onclick="caItems(this.form);"{xhtml}>');
    {!if arrow} <img 
src="{layout_url}/images/{arrow}.{image_type}" alt=""{xhtml}>{!endif}

     if (is_array($options) AND $options['chkdelete']) {
         $admin_templates->set_var('chk_delete', true);
         $admin_templates->set_var('sortable', false);
         $admin_templates->set_var('class', "admin-list-field");
         $admin_templates->parse('header_row', 'header', true);
     $admin_templates->set_var('chk_delete', false);
     $admin_templates->set_var('image_type', IMAGE_TYPE);
     $admin_templates->set_var('separator', $separator);
     for ($i=0; $i < count($header_arr); $i++) { #iterate through all headers
         if (!empty($header_arr[$i]['header_class'])) {
         } else {
             $admin_templates->set_var('class', "admin-list-headerfield");
         $admin_templates->set_var('header_text', $header_arr[$i]['text']);
         $admin_templates->set_var('sortable', isset($header_arr[$i]['sort']));
         $admin_templates->set_var('order_var', $i);
         $admin_templates->set_var('prevorder', $prevorder);  // 
these variables come from the $_GET array and are processed above this snippet.
         $admin_templates->set_var('direction', $direction);
$order==$header_arr[$i]['field'] ? $arrow : false);

         $admin_templates->parse('header_row', 'header', true);

Joe Mucchiello
Throwing Dice Games

More information about the geeklog-devel mailing list