[isf-wifidog] Paths in WiFiDog auth server
Max Horváth
max.horvath at maxspot.de
Lun 30 Jan 04:27:45 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Benoit Grégoire wrote:
>>> Well, I'm not sure we need to separate them. But we must be
>>> consistent:
>>> either the structure of /wifidog/templates mirrors /wifidog for
>>> every
>>> directory containing public scripts, or it does not.
>>
>> Well, I just started to move HTML code from PHP code to smarty.
>>
>> MainUI class reads really easy now and resulted in just 3 really easy
>> templates.
>
> Be carefull, why 3, it should be only one!
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.
> Remember, macrotemplates, maybe 30 for the ENTIRE system. I will
> enfore this,
> it was too much time, tears and diplomacy to reach a consensus.
I don't know why this must be enforced.
I tell you that the MainUI class reads much easier right now and that
those 3 templates easy to read, too.
Also the MainUI class is much smaller now and you actually understand
the things it does much faster, because you just have to read the
code. Now you don't have to detect PHP inside of some HTML fragments.
>> To easy editing templates later I started to put those files into /
>> wifidog/templates/MainUI
>
> Please, not one directory per class, it's going to be a nightmare
> to edit a
> bunch of directories with only one or two files per directory.
>
> Either everything in wifidog/templates or separate them in
>
> wifidog/templates
> wifidog/templates/admin
> wifidog/templates/classes
> wifidog/templates/portal
That's fine with me. Templates for one specific class could be named
like MainUI_display.tpl, MainUI_whatever.tpl and so on ...
> 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.
Again - alone MainUI class reads much easier and is much shorter (and
looks clean, btw ;)).
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 ;) ...
>> Then I thought about moving the templates being used by actual sites
>> to /wifidog/templates/sites ...
>>
>> So wouldn't it be better for the survey to add the templates of the
>> admin section to /wifidog/sites/admin?
>>
>> I think it'll be much easier to customize if we have less files in
>> one templates folder, but all "sites" templates in just one folder.
>
> I don't understand what you mean by "sites". Nodes? The goal in most
> definitely not to have node specific Smarty templates, we are just
> about to
> finally finish moving AWAY from that!
Well, I meant what you defined as /wifidog/templates/portal ;) ...
> We want to discurage end users editing Smarty templates, except as
> a very last
> recourse.
Those who wanna hack the HTML code will do it ... you can't stop
anybody. :D
>>> It's for scripts that display or manipulate a content type but not
>>> from the
>>> portal or admin interface. In the case of PatternLanguage, it's to
>>> display
>>> the narratives created by the visiting users.
>>
>> Sounds like a nice feature ... is there any documentation on that?
>
> Seems it got lost at some point. Hopefully I'll have time to write
> it again.
I'll be happy to read the documentation someday ;) ... thanks for
your efforts!
>> Nice ;) ...
>>
>> But we shouldn't remove this folder ... customization images should
>> all go in this folder, shouldn't it?
>
> Probably not, but I don't know where they will go yet. Probably
> somewhere
> below local_content
Didn't you write, that /wifidog/local_content is to be removed somewhen?
So long, Max!
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFD3dwR+BKgC+eQ3ooRAqk0AKCQy1QzOCYWEjFhVXHnMkDJ/A+HfwCeP0wS
T/nBAnoNvAnGlL5880XbvPc=
=lrKh
-----END PGP SIGNATURE-----
More information about the WiFiDog
mailing list