strategies for including files when you're not allowed to make assumptions about directory names

**Fabian Wleklinski** · Jul 17 '05, 12:32 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

Hi Lawrence,
[color=blue]
> 1.) Can anyone think of a way to speed up this function?
> It is terribly slow. I plan to reduce the number of
> directories to 3, which I guess will speed it up in the end.[/color]

Don't know why it's slow at the first sight - accessing
the filesystem (using "include" or "require") is not very
expensive, especially if the file does not even exist.

The overall execution time of your code depends on what
exactly is contained inside the included file(s).

This checking is done for every single request, right?

In my opinion it would make sense to check the file's
location only once per session, and store it, using a
session-persistent variable.

Greetings from Frankfurt / Germany,

Fabian Wleklinski

**André Næss** · Jul 17 '05, 12:32 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

lawrence:
[color=blue]
> function import($name,
> $printAnErrorMe ssageAtTheEndIf TheFileIsStillU nfound="y") {[/color]

LOL!

André Næss

**lawrence** · Jul 17 '05, 12:32 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

André Næss <andrena.spamre allysucks@ifi.u io.no> wrote in message news:<bmgof4$60 q$1@maud.ifi.ui o.no>...[color=blue]
> lawrence:
>[color=green]
> > function import($name,
> > $printAnErrorMe ssageAtTheEndIf TheFileIsStillU nfound="y") {[/color]
>
> LOL!
>
> André Næss[/color]

One gets tired of $printError="y" after a while. But you're right
about the needless length.

**Paulus Magnus** · Jul 17 '05, 12:32 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

"lawrence" <lkrubner@geoci ties.com> wrote in message
news:da7e68e8.0 310141514.4947a 6f6@posting.goo gle.com...[color=blue]
> André Næss <andrena.spamre allysucks@ifi.u io.no> wrote in message[/color]
news:<bmgof4$60 q$1@maud.ifi.ui o.no>...[color=blue][color=green]
> > lawrence:
> >[color=darkred]
> > > function import($name,
> > > $printAnErrorMe ssageAtTheEndIf TheFileIsStillU nfound="y") {[/color]
> >
> > LOL!
> >
> > André Næss[/color]
>
> One gets tired of $printError="y" after a while. But you're right
> about the needless length.[/color]

Without sounding like a killjoy but this sounds like a recipe for disaster.

What if your oh-so-important graphic designers update a file and place a
copy of it in a different directory? It's possible that your designers could
then end up giving you multiple copies of a file and then they'll start
blaming you for not checking file dates as part of your processing and
establishing the most up-to-date version. Maybe they'll then open/save a
file without changing it so you can't tell any more which is the most
up-to-date version. Maybe you'll then have to add a version line to each
file and check that ... but then they'll maybe forget to update that line as
well.

Good programming is about control. Controlling the computer and controlling
the flow of information around the computer. You shouldn't use include_once
in a file because you as a programmer should know that your logic dictates
it wouldn't be included twice (recursive functions excepted). It's the same
with everything in a script, you don't introduce functions that lose control
or create a situation that leads to it. Your graphic designers should be
told what to do, that this is the design standard and that's what you expect
them to follow. If that's not possible, then you need to manually move the
files these incompetent designers have misplaced so that you maintain the
control in your application. If others are going to be stupid, you'll have
to make up for their stupidity and spend your time doing it. If that's what
your client or employer prefers then so be it. I'm sure if you pointed out
that developer's time is more expensive than designers time they may back
your point of view.

Paulus

**Alan Little** · Jul 17 '05, 12:33 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

Carved in mystic runes upon the very living rock, the last words of
lawrence of comp.lang.php make plain:
[color=blue]
> 1.) Can anyone think of a way to speed up this function? It is
> terribly slow. I plan to reduce the number of directories to 3, which
> I guess will speed it up in the end.[/color]

I don't know about faster, but a cleaner way would be to have an array of
directories and loop through it using is_readable(), and when you find it,
break out of the loop and include().

--
Alan Little
Phorm PHP Form Processor

http://www.phorm.com/

**lawrence** · Jul 17 '05, 12:35 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

Alan Little <alan@n-o-s-p-a-m-phorm.com> wrote in message news:<Xns941548 5D3F11alanphorm com@216.196.97. 132>...[color=blue]
> Carved in mystic runes upon the very living rock, the last words of
> lawrence of comp.lang.php make plain:
>[color=green]
> > 1.) Can anyone think of a way to speed up this function? It is
> > terribly slow. I plan to reduce the number of directories to 3, which
> > I guess will speed it up in the end.[/color]
>
> I don't know about faster, but a cleaner way would be to have an array of
> directories and loop through it using is_readable(), and when you find it,
> break out of the loop and include().[/color]

I think you're right. I will rewrite it as you say.

**lawrence** · Jul 17 '05, 12:37 AM

Re: strategies for including files when you're not allowed to make assumptions about directory names

"Paulus Magnus" <paulus.magnus@ loves-spam.com> wrote in message[color=blue]
> Without sounding like a killjoy but this sounds like a recipe for disaster.
> What if your oh-so-important graphic designers update a file and place a
> copy of it in a different directory? It's possible that your designers could
> then end up giving you multiple copies of a file and then they'll start
> blaming you for not checking file dates as part of your processing and
> establishing the most up-to-date version. Maybe they'll then open/save a
> file without changing it so you can't tell any more which is the most
> up-to-date version. Maybe you'll then have to add a version line to each
> file and check that ... but then they'll maybe forget to update that line as
> well.[/color]

You raise a good point. Basically, the graphic designers could throw
in a file that has the same name as a file that I wrote, and the
results could be disaterous.

[color=blue]
> Good programming is about control. Controlling the computer and controlling
> the flow of information around the computer. You shouldn't use include_once
> in a file because you as a programmer should know that your logic dictates
> it wouldn't be included twice (recursive functions excepted).[/color]

Um, if I don't include files till their needed, then when they are
needed I need to include them using include_once, because some other
function might have already included them. A graphic designer, working
in Dreamweaver, designing a site for a client, and using some of these
software tools we've developed as a convenient way to drop interactive
elements into the page, might write something like:

<div class="navBar">
<?php showNav(1); ?>
</div>

<div class="comments ">
<?php showComments(); ?>
</div>

Both these commands would need the database object, so both would
include_once(). Of course, I've no idea that the designer is going to
use either of these. They may only use one command that needs the
database object on the page.

[color=blue]
> It's the same
> with everything in a script, you don't introduce functions that lose control
> or create a situation that leads to it. Your graphic designers should be
> told what to do, that this is the design standard and that's what you expect
> them to follow.[/color]

The head of the project, who is a graphic designer, said to me,
"Listen, all this software is great, but I've got friends who'd like
to use parts of this system, but they don't want use the whole thing.
It's too much. A lot of times its too complicated for what's needed.
Is there a way we can break this up? Like, for instance, if one of my
friends just wants to use the comments software on their websites, but
not all the other junk, can they do that?"

Up till that point I had simply included every file when the page
loaded. Every file got loaded once, and I knew what directly every
file was in. But since that conversation with the lead guy, I've been
trying to figure out a way to allow "minimum installations." I want to
be able to say, okay, this software has 140 files but you only 7 of
them because all you want to do is run the comments.

Somehow I need to figure out a way that will allow this to work. (As
an architextural point, I've been breaking down the objects into very
small objects, again to allow the minimal of "minimal installations".

How to get a minimal installation? This was my first thought, and this
is what I've got working right now: There is a small kernel, 5 files
taking up 24k, that needs to be loaded always. A designer can put in
just the kernel, then attempt use whatever functions they wanted. The
kernel isn't enough to do what they want, but it is enough to print
intelligent error messages to guide them. The software would print a
string of error messages like, "The software needs the file
'mcMySqlDatabas e.php'" and then "The software needs a file called
'mcShowComments Public.php'". The graphic designer would add in
whatever files the software asks for. After 10 minutes, the software
has maybe asked for 9 additional files, beyond what is in the kernel.
There are no more error messages, because for the limited set of
abilities that the grapic desinger wants, this is all they need. Now
they've got the functionality they want, and with only 14 files
installed, instead of 140.

This is what I've got working, but had not thought of the problem you
point out: identically named files.

[color=blue]
> If that's not possible, then you need to manually move the
> files these incompetent designers have misplaced so that you maintain the
> control in your application. If others are going to be stupid, you'll have
> to make up for their stupidity and spend your time doing it. If that's what
> your client or employer prefers then so be it. I'm sure if you pointed out
> that developer's time is more expensive than designers time they may back
> your point of view.[/color]

I think you raised an excellent point about the multiple, identical
filenames. This product is still in beta and we are still testing a
lot of ideas and, frankly, we are making design mistakes like this. I
should say, I am making design mistakes like this. But we've got time
to make mistakes and test different ideas. We've given ourselves the
time to make mistakes.

My first reaction, upon hearing your concern, is to throw in a test
for files with the same name. If ever there are two files with the
same name, the software will just print an error, and explain the
situation. That should be enough to let the graphic designers know
what the problem is.

We don't want to be like PostNuke, and impose a monolithic answer on
how things should be set up and done.