[kdewebdev-site] Local test bench and defined variables

[Eric Laffoon]

On Wednesday 09 March 2005 12:39 am, Andras Mantia wrote:
> On Wednesday 09 March 2005 00:55, Eric Laffoon wrote:
> > On Tuesday 08 March 2005 12:59 pm, Andras Mantia wrote:
> > > On Tuesday 08 March 2005 22:48, Andras Mantia wrote:
> > > > I cannot believe this does not work in PHP....
> > >
> > > showReleases("releases/releases.xml", $_appFormal);
> > > works fine.
> > >
> > > Andras
> >
> > Oops. What will not work is...
> > showReleases("releases/releases.xml", $appName=$_appFormal);
> >
> > I don't understand the comment about this being kdewebdev.org
> > specific? That's what we're building.
>
> When you write libraries (and this is basicly a library) you usually try
> to be not application on environment specific. So if it's possible to
> write code that does not depend on some other code (like in this case
> inclusion of applib.php before releases.inc.php) you should do it.

I would not argue with this in principle, but it can also make things harder. 
In this case everything is being made to depend on key files, but you know 
where they are. For instace I made the faq.php template so it requires 
nothing at all to function in a subdomain.
>
> > The question is whether we want
> > to make it easier for people on our site or add things to remember
> > for some other reason? Having a value that is automatically available
> > in an application subdomain should minimize the requirement to call
> > it since it will be there.
>
> 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.
>
> > In this case I pulled CVS this morning and found an error on
> > KLinkStatus in the release area showing on the page. The error was
> > that a required parameter for the function was missing. It seems a
> > good idea that if we add parameters to functions that may be in use
> > they should have a default value if possible so as not to create
> > errors, or we need to search out each instance of the function call
> > in CVS and update it.
>
> This might be my fault, as I said I fixed KLinkStatus locally.

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.
>
> > There are several ways to address the portability if that is what you
> > want.
>
> 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, except that applib.php is the one 
place where where application variables are declared and as it begins with 
"$_" it indicates it is an application variable. Note there are a lot of 
these in there for referring to various parts of the site. It's imperative 
these are used for addressing or they will break the testing sites.

So not knowing where to find $_appFormal or what it was would mean that you 
should probably be asking questions on the list.
>
> > through various methods to absurd levels of complexity in spite of
> > efforts to modularize and simplify. I'm probably paranoid about this.
>
> What I suggest is exactly the sane modularization.

If we were truly sane would we be busting our asses doing this waiting for the 
calvery? ;-)
>
> Andras

-- 
Eric Laffoon
Project Lead - kdewebdev module