Re: [PEPr] Images::Imagick proposal, Small Errors

Thorsten Suckow-Homberg wrote:

- there are some small coqs: @ccess @access IMAGE_IMAGICK_ERROR_RORATE_FAILED IMAGE_IMAGICK_ERROR_ROTATE_FAILED Moreover this constant is not used anywhere, like the other ones. - You forgave HTML debug code in addMotionBlur() in the alpha 0.2

Fixed!

- in loadImage() function: the second parameter for substr() should be the string length, rather than the end position: $_sImageName = substr($_sImage, $mTmpPos_1 + 1, $mTmpPos_2 - $mTmpPos_1 -

1);

An there's also a trick on this, sometimes on the web, people don't put

any

file extention at all. The more "avant-garde" for this are W3C ;-) http://www.w3.org/Icons/w3c_home http://www.w3.org/Icons/WWW/html_48x48 http://www.w3.org/Icons/valid-xhtml11 And if the filename does have a dot in its name? Yes I know there are a lot of 'if', but the case is possible. (The php func pathinfo() cannot handle this case neither.) far more greedy but should work: preg_match('!([^/]+?)\.\w{1,5}$!', $this->_sImage, $m); // or an ereg

version

$this->_sImageName = $m[1]; If you shoose to not handle tricky cases, perhaps put a warning in the

doc?

to prevent users don't put dots in filenames if they don't put file ext. (This one won't be 100% perfect too, the only ultim way would put all extentions in an array and comparing with it.)

Well, starting with respecting tricky cases would lead us into the question about usability - there could be a neverending discussion about which errors should be catched and which not. Since I am aware of the fact that errors may occur if a user submits an image-name without a file-extension, I don't want to handle this case. I have put a notice into the doc-block that the file-name MUST have a file extension. (Btw I don't know a case where a user would save an image without file-extension. ) However, if there will be more feedback about this I will think it over.

If you really want to remove all '@' from your code, perhaps another solution would be to use: if(file_exists() && is_readable()) {/*safe include*/}

Good suggestion, but I do not see an easy way to handle an error without putting @ before the include statement. The problem: The filters may all be saved into the directory PEAR/Image/Filter/. file_exists() Does not know the include_path, and PHP doesn't know the PEAR Directory. You could search the include-paths for the filter, but what if the script finds more than one directory named /Image/Filter with the specific file in it? I know this may not happen too often, but instead of doing a workaround with the include_paths I think this is by far the better (and faster) choice. Thanks for your comment I will handle your other posts now ;) Regards Thorsten

Why did you send this message to the pear-dev list four times? -- paperCrane <Justin Patrin>