[geeklog-devel] Request: Template Class Enhancement

[LIMBURG, Mark]

Howdy,

Just a quick point before I go on, it's *great* that we can have this kind
of discussion!  Seriously, I'd like to thank Tony and indeed the whole GL
dev community for their efforts not just in coding, but keeping issues like
this above board, logical, democratic (the whole reason I left phpnuke
development in the first place .. well, that and the code sucks donkey balls
also, but that aside), and honest.

 > You'll have to give an example.  Nothing you have mentioned 
 > here seems like a problem with the current system.  I think 
 > all you are getting at is you don't like the current system 
 >(which you've stated a number of times already).  

I do like the current system, I just think parts of it can be done
better/differently.  Parts of the subsystems do limit what I can do, both as
a developer (code and themes) and as an admin of GL.  My whole aim is to
provide a wider and larger implementation conceptually.

The perfect example (taking themes aside for a second) is the use of a
centre block on the index page.  Rather than having to hardcode the ability
to flip between a staticpage, nwes or both was a fairly limited hack to help
a single user .. which has since flowed down to be used by many people.
Implementing a centre block, akin to left and right blocks and providing
control over it as such, would expand GL greatly.

 > The 'alter code' argument holds no water IMHO.  What you are 
 > saying is to avoid changing PHP logic, instead add logic to 
 > the template.  That seems flat out wrong to me.  If the 
 > requirements for display for a specific page have changed, 
 > it is OK to alter the PHP to use templates differently to 
 > meet those requirements.  

The problem is keeping the code 'clean'.  Making a php hack is all well and
fine, but upgrading is a nightmare.  If the alteration is significant,
having to hack the code each time and ensure it works with the changes
between functions/bugfixes *and* altering the hack to suit added features is
a headache I want to avoid, as well as help others avoid it.  Again, back to
the staticpage hack .. if I had just released the hack to the public as a
hack, it would need to be changed all over each release.  

This is what I want to do with templates.  I had a really sweet theme, but I
simply couldn't do it because it all come down to needing to show different
<td> containers depending on if there was a left or right block being shown.
Something as simple as ...

  <td>
  <!-- START if leftblock -->
    whatever code
    {leftblock}
  <!-- else -->
    other code
  <!-- END if leftblock -->
  </td>

... would have saved the theme design.  I couldn't do it, so the theme
suffered.  I almost had to kill it off, but I ended up sacrificing the whole
look and feel.  Smooth_Blue was going to be much cooler that it currently
is, but no can do.

 > You are right, we don't agree at all which isn't bad, necessarily.

Read my first comment :)

 > > You don't NEED to use them.  They're there if you WISH to use them.

 > If you are going to go that route, we should just go back to 
 > PHP-based html embedded in functions that know about substitution 
 > variables.  Mixing logic and HTML is bad...period.

You know, I mostly agree with your last comment.  I resisted Smarty for ages
on that exaclty those grounds .. and then I had to use it internally here,
and the additional DESIGN powers given as such is amazing.  Smarty's use of
logic is overblown, hell, it's become to the point where you can code PHP
inside the template .. which is something I *am* againt.  

The logic control I want to add is *solely* content based, not php based -
as per my example above.  

 > As I said, I think the PEAR template stuff may support this. 

Bonus.  I'm not trying to sound petty (seriously!) but maybe they're doing
this *because* the theme development type folks need this also.

 > My opinion, however, is we not use that if we can get away 
 > with it.

I am in 100% agreement with you here.  But what of the areas where we DO
need it ...?

 > This only complicates the HTML for people aren't programmings.  

Again, you don't NEED to use it.  It's there for those cases when I need to
do pretty graphic things when there is no content there, and different
pretty graphic things when it IS there.

 > Case and point, I'm working on a web-based theme editor 
 > so that GL admins can tweak their layouts without needed 
 > shell access.  

Saweet :)

 > Adding a bunch of logic to templates will simply confuse 
 > some of the very people this tool is intended for.

And empower the rest of us!  I'm not saying 

My concern is this angle can be used further .. why use HTML, when TEXT
convays the same information.  It expands on the functions and features we
can provide.  This is not a bad thing.  If templates REQUIRED logic, then
that would be bad.

<devo>
  Freedom of choice, that's what you want..
</devo>

 > To be clear, while I oppose adding this, it is up to us all as a 
 > collective whole.  If I'm in the minority then so be it.  

Same here.  Theme designers, speak up!

 > However, I'd like to see us concentrate on value-added 
 > functionality in Geeklog (e.g. new features, better 
 > plugins, improved performance, etc) instead of 
 > wasting words on something that I feel isn't a priority.

I see and feel that simple logic control in themes IS a value-added function
in GL.  As a theme designer, I can do MORE with it.  This can also be rolled
out with more options for plugins, etc.

I don't feel like this is wasting words - communication is never bad, only
MIScommunication - and I've had to endure this a few times here.  I'm trying
to get a single view up for all to see and assess.  Personally, I'm not
thinking about coding this at the moment, as I am concentrating on other GL
issues, and will continue to not look at coding this until I do the other
code I see as more important.  Removing HTML from the GL core code being a
case in point.

I do feel, however, that this is a feature which many other web applications
have benefited from, and I don't see why we shouldn't benefit from it also.

Apologies for a long email.  

Regards,

Mark Limburg
Team Leader, Unix Operations, Information Systems

BAE SYSTEMS, AUSTRALIA
PO Box 1068, Salisbury
South Australia,  5108
Phone: +61 8 8480 7971
Fax:   +61 8 8480 8866
Mobile:+61 4 0448 0599