Re: .inc or .anything - better or worse ?

in binarycloud (I'll get to that in a minute) .inc is used for some stuff (specifically database access objects), but I've also used .lib (for libraries, doi :) .php, .conf, and a few others. In that case, though, everything that is included in in a pretty defined, big hierarchy of directories that is _always_ outside of DocRoot. Personally I think storing any includes in docroot is bad practice: if you don't want 'em to see it, and it doesn't have to be there, put it somewhere else :) On the stuff we've been doing with binarycloud, I've set .html to be processed because we specifically allow access to files though our permissions systems (except gifs and css, which would be annoying and pointless to control) I haven't noticed any performance hit from doing that. apache/php is already so ridiculously fast - unless you're trying to run a big site of a celeron with no ram :) .inc is clear (include me!) - but so long as its clear what something is for, I haven't seen any standard adhered to :) ---- ok, the part about binarycloud: some of you list old-timers may remember me talking about binarycloud a couple months ago. I didn't disappear, neither did binarycloud :) for those of you who don't know what the hell I'm talking about: binarycloud is an opensource system written entirely in PHP, which serves as a platform for building big webapps. it's meaty, beefy, big 'n bouncy :) my team is standardizing the comments for all the base code, and we're going to have PHPDoc-generated API documentation before the first release... as soon as that's done (probably a week or so) we'll release the whole thing. the basic idea is to provide a _complete_ set of integrated tools: advanced, robust error handling that is logged to your database, authentication, group-based file-level access permissions, a really, really cool template engine, database abstraction (metabase), something like 30 libraries: a multi-page form builder with string checking, cleaning, unspoofable... a table builder which uses template files (think table styles), a string type verification library, a string filtering/cleaning library, email, shopping cart, etc etc. probably overkill if you're building a small site, perfect if you're building something pretty big :) also, it's production. meaning we're running it in real, load-balanced webserver clusters. it's very stable, and it rocks :) the intent is to have a solid foundation that people like building applications on top of, so we maintain this core codeset, and watch the library of cool, compatible apps grow! Imagine being able to just plug in a knowledge base to your site, or forums, or a catalog engine, etc. anyway, soon! :) _a -- Alex Black, Head Monkey enigma@turingstudio.com The Turing Studio, Inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 Saul Zaentz Film Center 2600 Tenth St Suite 433 Berkeley, CA 94710-2522 > From: chris@ideal.net.au (Chris Aitken) > Newsgroups: php.general > Date: 5 Dec 2000 15:27:11 -0800 > Subject: [PHP] .inc or .anything - better or worse ? > > At 09:59 AM 28/11/2000, you wrote: > >> Most people add .inc to their PHP parser - AFAIK this is kind of a standard >> practice. A person looking at main.inc would get "Document Contained No >> Data". >> Not a huge security risk IMO - of course mine are outside of the docroot ;O) > > Is there any specific why it an unwritten law that included files are .inc ? > > The first ever tutorial I did for PHP actually made included files .php and > the reason it said this was because some places may not protect .inc (or > other extentions) and also may not allow you access to go back a directory > and use that area. > > Ive been using .php for all my included files (mostly all my functions are > in these files) and never had a problem but it seems that most people use > .inc instead. > > > > Chris > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >