Page 4 of 9

Posted: Sat Apr 14, 2007 4:40 am
by Maugrim_The_Reaper
Should work - but check the .htaccess file. I'm using the ".*" regex which might differ.

Code: Select all

RewriteEngine on
RewriteRule .* index.php

Posted: Sat Apr 14, 2007 1:08 pm
by Christopher
Nope, could not get it to work and I am not sure why. I rebuilt the files from scratch in a separate tree and got it to work ... which is curious. I need to compare them to see what the difference is. The error I get is:

Code: Select all

Fatal error: Call to a member function isDispatched() on a non-object in C:\htdocs\php\Zend\Controller\Action.php on line 499
Which means that no response object is being created internally ...

Posted: Sat Apr 14, 2007 3:59 pm
by Maugrim_The_Reaper
Would be the Request object being invalid - shouldn't be happening if it's created internally. No external one being 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.
Noted - 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.

I'm not certain which factors determine the ZF's accuracy on detecting Base URL - previously it was failing practically all the time. Recently I noticed it worked most of the time under Apache (I haven't tested on others). I'll check the code later to see what goes on for that task...

Posted: Sat Apr 14, 2007 7:12 pm
by Ollie Saunders
Sorry I've been away guys. PHPBB stopped sending me emails for some reason and all of a sudden the thread is at 4 pages. I've got some opinions on what you have been discussing.

First of all. I don't think this is optimal:

Code: Select all

set_include_path(
    $AppDir . PATH_SEPARATOR
    . $AppDir . '/extends' . PATH_SEPARATOR
    . get_include_path()
);
I suggest

Code: Select all

set_include_path($AppDir . PATH_SEPARATOR . $AppDir . '../library');
Cruically this way each library doesn't need a new entry in the include path and

Code: Select all

spl_autoload_register(array('Zend_Loader', 'loadClass'));
will work straight out of the box - if you decide to use it. Because to load Zend_Controller_Front -> Zend/Controller/Front.php -> $AppDir . '../library/Zend/Controller/Front.php'. All very nice and clean.

Code: Select all

config
application
library
  Smarty
  Zend
  dBug
  MyZend  <-- Where I put my Zend Customizations
public
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 having

Code: Select all

library
    Framework
    Application
    Zend
    ..
so the application is like another library and all application resources are classes so I can load a view script, say Application_View_AuthDisplay easily.
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. :)
I agree. We may or may not end up there ... or it may be an option.
An option? No way dude. Convention over configuration, you people obviously don't believe in it then.

Code: Select all

encoding = "UTF-8"
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 = 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 called
The implications of this are you can easily add support for whole new character encodings to your application by writing adapters for existing libraries. However to allow support for UTF-16 as well as UTF-8 you would probably have to run every single string processing task in the application through the $encoding object resulting in a significant performance hit for UTF-8 as well. Sorry did I blow that one out of proportion there? I'll move on

Code: Select all

logfile =
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?

Code: Select all

bootstrap.timezone = "Europe/Dublin"
bootstrap.displayerrors = 1
bootstrap.reporting = 8191
All of these can be obtained via ini_get() and if the user wants to set them they can use php.ini or .htaccess

Posted: Sat Apr 14, 2007 7:34 pm
by Christopher
Two thoughts:

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.

2. We may not end up using the ZF parts that "figure out" what the base URL is...


I may put together a archive of the example I have working for people to compare and try out.

Posted: Sun Apr 15, 2007 2:55 am
by Ollie Saunders
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.
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.

Posted: Sun Apr 15, 2007 9:28 am
by Maugrim_The_Reaper
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:
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().

So yes, encoding should be capable of being changed in the configuration. UTF-8 is simply a nice universal one to use for web applications. The trick is in using the value with a little care, and knowing when other options are better. It's likely a good idea to have separate options for all three typical encoding uses - internal, output and database. Which are set on iconv, PHP, the default Response object, and the database connection - preferably as close to the start up layer (bootstrap) as possible to avoid halfway issues.
ole wrote:An option? No way dude. Convention over configuration, you people obviously don't believe in it then.
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.
Cruically this way each library doesn't need a new entry in the include path and
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.

This does add another reason why a /library can be skipped - the ZF has no base class to prevent an svn:external on the /application directory pointing to /Zend. Add another library, and that could change - so please note a /library is possible when it is needed.
$encoding->strpos($someIsoString); // normal strpos is called
UTF-8 incorporates ISO-8859-1 you know - that ISO string is still valid UTF-8 ;).
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?
No idea - logfile as a configuration value is simply traditional. A recognition of "What if?".
All of these can be obtained via ini_get() and if the user wants to set them they can use php.ini or .htaccess
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...

Posted: Sun Apr 15, 2007 10:59 am
by Ollie Saunders
Encoding is variable - and its execution quality differs quite a lot in PHP
I think I know what you mean by that but could you clarify please.
The basic requirements are to set the output, database and internal PHP encodings. This is enough to make an application relatively safe to users.
No, its not. Where is ambush commander when you need him? :P 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 or mbstring extensions.
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.
UTF-8 is simply a nice universal one to use for web applications.
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 incorporates ISO-8859-1 you know - that ISO string is still valid UTF-8
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.
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...
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.

Posted: Sun Apr 15, 2007 1:04 pm
by Christopher
A few thoughts:

Regarding the include_path, it really doesn't matter how many dirs you have in your include path -- that's up to you. My point has been that this is the simplest layout:

Code: Select all

set_include_path($AppDir . PATH_SEPARATOR . get_include_path());

Code: Select all

application
  config
  controllers
  models
  views
  Smarty
  Zend
  dBug
  MyWhatever
public
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.

Regarding UTF-8 or log files or any other disputed options, I am fine removing them until it is proven that we need them. Perhaps we can move them to an optional section of the config file to denote that this is how we would define them, but we don't use them until needed. They certainly are common considerations.

Posted: Sun Apr 15, 2007 2:40 pm
by Maugrim_The_Reaper
ole wrote:I think I know what you mean by that but could you clarify please.
I 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.
No, 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.
I never addressed input validation - not so much as a mention ;). That's another ballpark. I only intended noting that an application needs to agree on an encoding in three areas before it will correctly function (for a multibyte charset). There's no point in having UTF-8 content if it's being mangled into ISO-8859-1 by PHP, or if someone writing templates fouled up and never encoded them correctly, or if the database is clueless, or HTTP headers are wrong. My point was that these are simple and common mistakes.
Your application isn't going to have great portability if both of those are required.
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.
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.
One assumes you checked the encoding...doh ;). 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. I thought that's why PHP6 was so looked forward to.
Fine, so what's wrong with .htaccess?
It doesn't work for PHP under CGI. That's 50% of your choice in PHP configurations out the window...

Posted: Sun Apr 15, 2007 4:10 pm
by Maugrim_The_Reaper
On a lighter note ;).

http://w3style.co.uk/devnet-projects/pet-store/trunk/

Thanks to d11wtq, we now have subversion access to a repository online. I have committed the code we have thus far which is basically a "Hello World!" example for the ZF. It's divided into the main "zfPetShop" application directory, and the "www" directory for stuff to be placed in the document root of the webserver.

There's a quick install document in the trunk root. At present myself and arborint have accounts - anyone else want one for future progress?

Posted: Sun Apr 15, 2007 5:57 pm
by Ollie Saunders
Ughh I don't like arguing with people. But that's usually where somebody stands to learn something. Unfortunately the UTF-8 character encoding problem is such a massive and multi faceted one I would take some time to make sure every knew the facts and then agree on everything.
I only intended noting that an application needs to agree on an encoding in three areas before it will correctly function...
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-16 :P) and code to that. If we are doing it for the whole world to get maximum portability we are going to need maximum portability and then, well, we are going to need to design a complex solution and have a thorough understanding of all the possible encoding scenarios - I don't think that is what we want to do.
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
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.
It doesn't work for PHP under CGI. That's 50% of your choice in PHP configurations out the window...
If you are sure you are correct I accept that as a fair and strong point.

Posted: Sun Apr 15, 2007 7:18 pm
by bpopp
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.
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.

I can't believe there is anyone out there that would actually disagree with this point so if you're that determined to just throw everything into the root directory, we probably can't convince you otherwise. To me it seems as fundamentally obvious as using functions instead of goto statements, but then again, there are people out there (ie. Perl programmers) that still prefer the latter.

Posted: Sun Apr 15, 2007 7:32 pm
by Christopher
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).
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.

Posted: Sun Apr 15, 2007 9:30 pm
by dreamscape
App directory structure can be one of the most difficult things to agree on. I often weeble-wobble between options on solo projects.

I can understand about not wanting the include path to have too many places to search... on the other hand, I always use the absolute path so it's not too much of an issue for me personally.

Personally, I also don't like to throw 3rd party code in with my own... It tends to get rather messy...

I take one from the Rails book and put all non-application specific code into a vendor directory, including the framework, even if I'm using my own.

I'd prefer to see something like:

Code: Select all

/Application 
  /Config 
  /Controllers 
  /Models 
  /Views 
/Vendor
  /Smarty
  /Zend 
  /Swift
/public
But then again, the Zend Framework follows Pear naming conventions, and I'm not especially a fan of Pear naming conventions or directory structure... so my ideas of what constitutes a good application directory structure probably don't mesh that well when you bring Pear into the picture.