[isf-wifidog] PHP-HTML separation.

[Benoit Grégoire]

On January 30, 2006 04:27 am, Max Horváth wrote:
> Well, we got three different html parts generated by the MainUI class.
>
> It simply isn't possible to to have three different sections of code
> in one Smarty template. Also Smarty has never been designed to serve
> those needs. And a template is a template for one specific part. If
> we would be adding something like 3 different function to a template
> it would be just too hard to read that template.

May be Ok, haven't seen it, just be carefull.

> > In adition, I'm affrait if you separate it completely, I'm affraid
> > someone in
> > the future will think we are trying to separate all html fragments
> > into
> > Smarty templates.
> 
> I partly understand what you're afraid of.
> 
> But let me tell you, that having all HTML code (which makes sense to
> be put into templates) in templates, will ease the job of the
> developers.

That point of view has been carefully considered, and it was decided that it 
would not.

We spent about 13 hours total debating the view and coutomization separation 
as a group (some in London, some in Montreal).  I personally tool several 
aditional hours writing several pages of text, several times, explaining it 
in detail the consensus and it'implication on the mailing list and the bug 
tracker.  I can't be any more democratic than that.  But eventually real work 
has to be performed, enough has been wasted on design.

All HTML will NOT be taken out of the HTML files.  It's the result of a 
compromise, and after all this time I will not keep re-visiting it all the 
time.

> Again - alone MainUI class reads much easier and is much shorter (and
> looks clean, btw ;)).

MainUI was the first target for templating, it'S presentation only, no one 
pretended that it wouldn'T be a good target for templating.

> But also: what are you afraid of? Those groups, who'd like to
> customize every single piece of HTML code of WiFiDog auth server
> would be working even through 500+ templates. They even would
> customize every single HTML code to be found in the PHP files. Having
> the HTML code in templates gives them the chance to stay up to date
> regarding the WiFiDog auth server code.
>
> I am sure, that we'll be having just a few templates that can and
> will be customized by groups. So it'll be easy to customize - cause
> most of the templates won't be touched.
> 
> In the end I don't wanna do this for the opportunity for groups to
> customize their WiFiDog auth server, but to ease my developments
> activities (and of course the development efforts of all the other
> developers). I mean - all I needed was Smarty templates for the
> MainUI class for maxspot. But I can assure you, that this seperation
> of HTML and PHP is good for everyone ;) ...

I'm sorry you don't understand getting all the generated HTML would be a bad 
idea for code size, developement convenience, performance and even MVC 
separation, but I'm just exhausted of answering those questions point by 
point.  We all share the same goals, but a decision was made as to how we 
would do it:

-We want to move the presentation OUT of the HTML and into the CSS as much as 
current technology will allow.
-In general, only HTML that is "view only" will be moved to templates (mostly 
part of top level scripts, the MainUI class, and the base Content classs).  
In general HTML that is controler (forms, select box, etc.) will remain near 
controler logic.
-Display area is going to be split into zones to which you can associate 
arbitrary content fragments.
-Normal path to customisation will be custom themes and typing text in the web 
interface.  Changing Smarty templates will be a last resort.

The why would take pages to explain, and most of those pages have already been 
written.  I'll only answer one here:

-Why bother to move to Smarty templates at all considering these objectives?
1-It will be less effort to move most or all presentation style HTML into 
templates and then strip presentation out of it is easier for developers than 
trying to do it all in the HTML.
2-It is unlikely that we will manage to move all text and presentation out of 
the HTML considering we don't want to rewrite a full CMS.  As such, it's 
inevitable that in the short term some HTML will be frequently edited 
(header, footer, FAQ, signup, etc.).  Might as well separate it out and make 
it easy to find.

There, that's it, I did it again, another long explatantion.

> PS: If you like, open a new branch - so I can commit my changes to
> that new one. Then we all could decide whether or not to merge those
> changes into the trunk.

No, I'd rather we have to revert a few misunderstandings than to have a 
monster monster merge to perform that may or may not fit well with other 
changes.  This is a progressive process, I'll try to keep it on trac.
-- 
Benoit Grégoire, http://benoitg.coeus.ca/
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 189 octets
Desc: non disponible
Url: http://listes.ilesansfil.org/pipermail/wifidog/attachments/20060130/8831f6c2/attachment.pgp