[kdewebdev-site] Local test bench and defined variables

[Eric Laffoon]

On Thursday 10 March 2005 09:49 am, Andras Mantia wrote:
> On Thursday 10 March 2005 19:40, Eric Laffoon wrote:
> > > I don't know if site programmers think differently from application
> > > programmers, but I don't see a problem with providing an extra
> > > argument, especially that even the faq.inc.php requires a similar
> > > argument.
> >
> > We have to think differently. There is no persistence from page to
> > page, display elements and factors are different, computing factors
> > are different... There are a lot of differences. My thinking here was
> > only biased from experience of dumb errors I've generated.
> > 1) Use as few parameters as possible, especially if it make something
> > more portable.
> > 2) Give defaults to extra parameters whenever possible.
> > 3) Be extremely reluctant to add parameters and again try to make
> > them defaults, because of what they could break.
>
> I think I realize what is your problem: PHP does not warn if you miss a
> parameter.
It does, it just gives it to your entire web viewing audience if you don't 
catch it. If you add a required parameter to a function in use by other files 
then they will break. The only way to avoid this is...
1) get your parameters in ASAP
2) make parameters options by using an intelligent default
3) find every last call to your function and edit it

> C++ does unless you specify a default value for the 
> parameter. But this is nothing that should stop us to use customizable
> functions (by extra parameters). Global variables just as confusing.

I agree, but as I pointed out before we cannot use a varialble for a default, 
and in this case we do have a variable for the application name.
>
> > Understandable, but it illustrates why I want to do things the way I
> > do. Moura picked up and dropped in files from kallery... If we
> > optimize code to be able to move from subdomain to subdomain without
> > modification, or with the least possible modification, then we make
> > it very easy to build the site. Even the smallest modifications
> > require extensive testing. As we add sessions and user
> > configurability this becomes that much more critical.
>
> We will see. :-)

I think I'll go shoot myself now. Every time I say simple... ;-)
>
> > > That is only once concerns. The other is good design. If you read
> > > the releases.inc.php code now you don't have the slightest idea
> > > from where $_appFormal comes as releases.inc.php does not include
> > > anything from where it might come and it's not declared there.
> >
> > Then the same could be said of index.php,
>
> No, as index.php starts with <? include "applib.php" ?> which clearly
> says that some functions and variables might be declared there. If
> releases.inc.php starts with an <? include "applib.php" ?> I don't have
> (such a big) problem with $_appFormal. But now there is an assumption
> that releases.inc.php is included only in a file where applib.php is
> already included and I really don't like this.
>
> Andras
This is _not_ an assumption. applib.php manages files for local test and 
remote display. If you hard code a file for one, the other or a specialized 
personal set up it will not be able to be tested by others. Any file hard 
coded instead of using applib.php will become less portable between 
subdomains. When sessions and other features are added any file manually 
doing the extra work to emulate applib.php will fail to work with the new 
changes. Essentially applib.php provides a functional object base to the site 
by managing reuse, and any file operating on site displaying information or 
accessing libraries without applib.php should be considered majorly broken.

The inclusion of applib.php is not an assumption. It is a rule! Without it the 
consistency, portability and assured functionality of the site is broken. 
You'll note too that when I added $_appFormal I went to every applib.php on 
site and updated it in order to assure that any file using it could safely be 
copied to any other subdomain.

If there is one thing that I expect to happen it is that things will be 
created for use in one subdomain, like your release files, and used in 
others. The more this can be made to be a drop in file, like my drop in FAQ 
template, the easier my life is. If somebody doesn't break something I don't 
have to tell them to fix it. If somebody doesn't customize something I don't 
have to tell them to add content. For this I will happily trade my distaste 
for using a global variable where PHP does not allow me to pass a default as 
a variable.
-- 
Eric Laffoon
Project Lead - kdewebdev module