[geeklog-devel] Request: Template Class Enhancement

[Tony Bibbs]

I had some time to rethink this and I think I'd be OK with *very* simple 
control structures in a templates (e.g. IF THEN).

All I would add is that we should do our best limit it's use.  When 
possible (95% or better I would guess), we should not need this logic.  
However, if it makese sense then use it.

That said, I'm still sure this will not be possible within 1.3.x unless 
there is an updated, backward compatible, version of PHPLib's template 
class with this support.  

As for GL2 I'll be looking into what PEAR has to see if this is supported.

--Tony

 On Fri, 21 Mar 2003, LIMBURG, 
Mark wrote:

> 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
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
> 

-- 
Tony Bibbs          "I guess you have to remember that those who don't
tony at tonybibbs.com  hunt or fish often see those of us who do as      
                    harmlessly strange and sort of amusing. When you  
                    think about it, that might be a fair assessment." 
                    --Unknown