Code: Select all
RewriteEngine on
RewriteRule .* index.phpModerator: General Moderators
Code: Select all
RewriteEngine on
RewriteRule .* index.phpCode: Select all
Fatal error: Call to a member function isDispatched() on a non-object in C:\htdocs\php\Zend\Controller\Action.php on line 499Noted - could be pushed back a level then. The notable thing is that the Base URL isn't always required - it depends on the system in use as to whether ZF correctly identifies it or not (hence the manual setting is actually optional). Given the uncertainty I'd still manually assign it (to be on the safe side) but fetch it from the Request object directly in case it's not manually set.Looks good. My only quibble is that baseurl will probably be used frequently enough through the app that I think just $Config->baseurl would be better.
Code: Select all
set_include_path(
$AppDir . PATH_SEPARATOR
. $AppDir . '/extends' . PATH_SEPARATOR
. get_include_path()
);Code: Select all
set_include_path($AppDir . PATH_SEPARATOR . $AppDir . '../library');Code: Select all
spl_autoload_register(array('Zend_Loader', 'loadClass'));Yep I do this. In fact I take it to another level and put all my classes in there and they can all be autoloaded if I choose. In my framework I've gone a step further with this by actually just havingCode: Select all
config application library Smarty Zend dBug MyZend <-- Where I put my Zend Customizations public
Code: Select all
library
Framework
Application
Zend
..An option? No way dude. Convention over configuration, you people obviously don't believe in it then.I agree. We may or may not end up there ... or it may be an option.Should be noted nobody is saying a /library dir is bad - it's just not required as yet with only the one library in use.
And you are going to allow people to change that? You know to implement UTF8 in PHP is quite a bit of extra effort and to have someone able to change it to something else and have the application cope is going to be even more. I'm not saying you shouldn't do it but I just wanted to point out what this entails. I've actually written a set of classes for achieving exactly such a thing. They work kinda like this:Code: Select all
encoding = "UTF-8"
Code: Select all
$encoding = Ole_Encoding::getInstanceFromString(ini_get('default_charset'));
$encoding->strpos($someUtf8String); // PHPUTF8 library is being used and functions are dynamically loaded as used
$encoding->preg_match('/a/', $someUtf8String); // 'u' modifier automatically appended
$encoding->clean($dirtyUtf8); // appropriate action performed by a couple of functions in PHPUTF8
$encoding = Ole_Encoding::getInstanceFromString('ISO-8895-1'); // searches for a specialised ISO-8895-1 class
// in this case it doesn't exist and uses a standard single byte class, appropriate in this case
$encoding->strpos($someIsoString); // normal strpos is calledI don't think log file should be a configuration either. How about adding a log directory to your directory structure and putting them in there. You know that they are going to be outside of the document root. Where is a more appropriate place?Code: Select all
logfile =
All of these can be obtained via ini_get() and if the user wants to set them they can use php.ini or .htaccessCode: Select all
bootstrap.timezone = "Europe/Dublin" bootstrap.displayerrors = 1 bootstrap.reporting = 8191
So the user doesn't have to set the configuration. Plus it is a drop in the ocean compared to the overall work of the front controller and its friends.1. I don't know why you want to spend time every request figuring out a simple value that never changes for a configuration. If you have more complex needs that a single URL and path the you obviously are going to need some code.
Encoding is variable - and its execution quality differs quite a lot in PHP. The basic requirements are to set the output, database and internal PHP encodings. This is enough to make an application relatively safe to users. The first is based on HTTP headers (and assumes output is encoded correctly which is still a very common problem), second is up to the relevant DBMS, the third is handled by either the iconv or mbstring extensions. It's worth noting Iconv should be available on most systems - it's bundled with PHP for Win32, and available as standard on Unix platforms. You just need to reset the php.ini file default settings using iconv_set_encoding().ole wrote:And you are going to allow people to change that? You know to implement UTF8 in PHP is quite a bit of extra effort and to have someone able to change it to something else and have the application cope is going to be even more. I'm not saying you shouldn't do it but I just wanted to point out what this entails. I've actually written a set of classes for achieving exactly such a thing. They work kinda like this:
There's only one library. If there are more it takes a few seconds to add /library, another few to set the svn:externals, another few to commit, and then a little while to update. It barely qualifies as a task... The only manual work should be mkdir and an svn prop commit. If you feel strongly about it than use your preference - because it is only a preference. The purpose of using /extends over another subdir is to separate it from other libraries in a separate tree - by itself it's nothing, it can only be used if the Zend Framework or an approximation based on ZF interfaces is available.ole wrote:An option? No way dude. Convention over configuration, you people obviously don't believe in it then.
I have to differ - if you rely extensively on svn:externals you'll quickly discover most libraries need their own individual include_path entry because you cannot externalise base classes (ZF's prior Zend.php, Swiftmailer's Swift.php, etc.) into an existing directory like /library or the base directory - you need to actually add a new one which breaks the PEAR naming convention. Part of the reason why a /library is not needed with just the ZF is that it has no base class to require the extra level (Zend.php is deprecated and can be ignored in subversion). Your single include_path is only possible without subversion - usually by copying a library directly into a versioned filesystem and committing it to your own repository.Cruically this way each library doesn't need a new entry in the include path and
UTF-8 incorporates ISO-8859-1 you know - that ISO string is still valid UTF-8$encoding->strpos($someIsoString); // normal strpos is called
No idea - logfile as a configuration value is simply traditional. A recognition of "What if?".ole wrote:I don't think log file should be a configuration either. How about adding a log directory to your directory structure and putting them in there. You know that they are going to be outside of the document root. Where is a more appropriate place?
php.ini is a global setting. It's also impossible to change on a shared host. I know telling users to go edit the php.ini is common, but honestly, how many people use shared hosting vs other options? Even I use inexpensive shared hosting...All of these can be obtained via ini_get() and if the user wants to set them they can use php.ini or .htaccess
I think I know what you mean by that but could you clarify please.Encoding is variable - and its execution quality differs quite a lot in PHP
No, its not. Where is ambush commander when you need him?The basic requirements are to set the output, database and internal PHP encodings. This is enough to make an application relatively safe to users.
your application isn't going to have great portability if both of those are required. both of them have to be compiled in. This means you have to have PHP libraries to back them up where they aren't there. In a lot of cases you need that anyway because they aren't particularly comprehensive.iconv or mbstring extensions.
Absolutely. So why don't we make that the convention? It can represent every unicode character and the only reason why more people aren't using it is one of laziness or ignorance.UTF-8 is simply a nice universal one to use for web applications.
Fraid not. Any byte greater than 127 out of context will result in invalid UTF-8. Also you shouldn't always use multibyte functions because they aren't always necessary.UTF-8 incorporates ISO-8859-1 you know - that ISO string is still valid UTF-8
Fine, so what's wrong with .htaccess? What I'm saying is there is a good standard configuration system here, why don't we use it? We could even use the "default" configs herewe don't necessarily have to be using mysql to ini_get() those values.php.ini is a global setting. It's also impossible to change on a shared host. I know telling users to go edit the php.ini is common, but honestly, how many people use shared hosting vs other options? Even I use inexpensive shared hosting...
Code: Select all
set_include_path($AppDir . PATH_SEPARATOR . get_include_path());Code: Select all
application
config
controllers
models
views
Smarty
Zend
dBug
MyWhatever
publicI was being vague - inconsistent encoding support is my personal bane. My name contains the a-acute character but many websites remain incapable of storing and re-displaying it correctly. It happens to the best of them...but it's symptomatic of the low priority correct encoding has on the web for many programmers who speak English and haven't a clue about European accent characters. If you examine such sites in turn it's easy enough to figure out where they went wrong.ole wrote:I think I know what you mean by that but could you clarify please.
I never addressed input validation - not so much as a mentionNo, its not. Where is ambush commander when you need him? Razz Just because you are telling the browser to send form submissions as UTF-8 doesn't guarantee that they will come back as those. You have to check that the UTF-8 is well formed. If the user is able to specify other encodings we have to have to have polymorphic checking functionality. Some encodings require none at all.
Iconv should be a given - check what it is, and why any half decent Linux system will have it. It's also precompiled into the Windows binaries by default. If it's not available then a PHP library like PHPUTF8 can be brought in. In truth it's a common extension for PHP5 and hardly optional if you intend running an application on anything but ASCII. Check for the libiconv library on your system - I bet it's available.Your application isn't going to have great portability if both of those are required.
One assumes you checked the encoding...dohFraid not. Any byte greater than 127 out of context will result in invalid UTF-8. Also you shouldn't always use multibyte functions because they aren't always necessary.
It doesn't work for PHP under CGI. That's 50% of your choice in PHP configurations out the window...Fine, so what's wrong with .htaccess?
Yeah actually that begs a question. For whom are we defining these best ZF practises for? I don't think its going to be possible to have a one-size-fits-all way of doing things. if we just want something for ourselves personally it may well be satisfactory to choose a single encoding (and that choice should be UTF-8 or UTF-16I only intended noting that an application needs to agree on an encoding in three areas before it will correctly function...
In PHP5 there are plenty of places where you know you won't have to deal with multibyte strings. Any string processing of callbacks, variables names or class names as strings or where you set the data and something is conditional about the processing, you know you are going to be working with a specific string.To the other - why not? Outside a standard (say URI which won't be multibyte unless from IDNs) there are few areas multibyte encodings don't potentially reach
If you are sure you are correct I accept that as a fair and strong point.It doesn't work for PHP under CGI. That's 50% of your choice in PHP configurations out the window...
I'm not saying it's simpler. I'm saying that it's more logical (and therefore better) to have your libraries in a library folder (even if there's just one). If a particular app had just one controller, would you pull it out to the root level, too? How about your views? Why not just pull them out and throw them in the root folder? Logical hierarchies are so 1969.If you don't like it, then add more paths. But don't say that some other layout is simpler or that there will be too many dirs in one folder or that there will be name clashes. As long as you can do include 'Libname/foo.php' then you are compatible. And given that there are as many different layouts as there are programmers in this conversation -- compatible is good enough.
Well ... we agree on simpler, we just don't agree that one way is more logical. I have given my pros and cons, and I don't find one more "logical" than the other -- just different. As I said, the path we require for include within the program is what matters most and any of the layouts work.bpopp wrote:I'm not saying it's simpler. I'm saying that it's more logical (and therefore better) to have your libraries in a library folder (even if there's just one).
Code: Select all
/Application
/Config
/Controllers
/Models
/Views
/Vendor
/Smarty
/Zend
/Swift
/public