Re: [PHP] Re: iconv is messing up a spreadsheet generated by the Spreadsheet Excel Writer
Good question, according to the author 'There was only a little problem with _calculateSharedStringsSizes() and _storeSharedStringsTable() functions within the Workbook.php. They did not support unicode strings.' Ewen 2009/1/15 Thodoris t...@kinetix.gr Hi there, I'm not sure if this is the same problem but after I struggled with strange characters in Spreadsheet Excel Writer for some time I wrote an article from my lessons learned: http://research.elabs.govt.nz/generating-excel-spreadsheets-with-maori-macrons-in-php/ It contains some example code, hope it helps. Ewen 2009/1/14 c...@l-i-e.com c...@l-i-e.com The charset: latin1 and the collation: latin1_swedish_ci. Trivia quiz at a MySQL presentation at my Chicago PHP User Group a few year ago comes in handy! The defaults for MySQL are actually latin1_swedish as that is the native language of the original developer, (?Monty Widenus?) This charset differs in only one character (or two chars switched?) from English. It seems unlikely to produce drastic problems in iconv, but I have no idea what I'm actually talking about. We now return you to your regularly scheduled program! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Thanks man that did it :-) . What exactly was the problem you've noticed (I am seeing a diff between the two files bu t I am not sure I fully understand)? -- Thodoris
Re: [PHP] Re: iconv is messing up a spreadsheet generated by the Spreadsheet Excel Writer
Hi there, I'm not sure if this is the same problem but after I struggled with strange characters in Spreadsheet Excel Writer for some time I wrote an article from my lessons learned: http://research.elabs.govt.nz/generating-excel-spreadsheets-with-maori-macrons-in-php/ It contains some example code, hope it helps. Ewen 2009/1/14 c...@l-i-e.com The charset: latin1 and the collation: latin1_swedish_ci. Trivia quiz at a MySQL presentation at my Chicago PHP User Group a few year ago comes in handy! The defaults for MySQL are actually latin1_swedish as that is the native language of the original developer, (?Monty Widenus?) This charset differs in only one character (or two chars switched?) from English. It seems unlikely to produce drastic problems in iconv, but I have no idea what I'm actually talking about. We now return you to your regularly scheduled program! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Zend Framework...where to start? -- don't.
I think Daevid has some valid points although I think frameworks still have a lot of value, I've recently learned to use the CakePHP framework and have been happy with the development time improvements. But more then that I've found it has made my applications more extensible and flexible. As to the point about training new employees to the framework - in my experience I would have much prefered previous colleagues to have used a framework which would at least provide a reference for me to use rather than seeing several development styles throughout the code and inconsistent documentation. No, frameworks are not silver bullets but still a useful programming tool in the right situations/applications. Cheers, Ewen 2009/1/15 Phpster phps...@gmail.com Core files are what my plans include too. Bastien Sent from my iPod On Jan 14, 2009, at 9:26 PM, Kyle Terry k...@kyleterry.com wrote: On Wed, Jan 14, 2009 at 6:17 PM, Paul M Foster pa...@quillandmouse.com wrote: On Wed, Jan 14, 2009 at 01:39:02PM -0800, Daevid Vincent wrote: Not to start a Holy War (as these to framework or not to framework debates often turn into), but I personally had a horrible experience with using frameworks. I was forced to use Symfony at my last job and it was so cumbersome and slow to do even the simplest things. The whole MVC thing can be overkill. Plus the learning curve can be quite steep. Then if you want to hire other developers to work with you, you have to train them and let them ramp up on not only the framework but also your core project too! More wasted time. The pages are significantly slower than straight PHP by orders of magnitude: [1]http://paul-m-jones.com/?p=315 What a great link! I've never seen this kind of comparison before. HTML is 70% faster than straight PHP, and the frameworks (even codeigniter) deliver less than 20% of the performance of straight PHP. The basic problem with frameworks is they try to be one thing for all people. This carries a lot of baggage with it. There's a lot of crap you end up pulling in that you don't want/need. Plus if you want to deviate at all, you either have to roll your own, or sometimes you simply just can't. They seem attractive with all their plugins and stuff, but honestly, rarely do the plugins do EXACTLY what you want, the way you want. It might be as simple as trying to change the look/feel of a button or something and you'll find out that you can't -- so now you have this website that has this section that doesn't look like the rest of your site. And if you find a bug, you have to try to either fix it yourself and then keep those changes migrated into new updates, or submit it to the developer and hope they implement them (and trust me, you can submit to them and have them rejected for all sorts of lame reasons -- even though the work has been done and you're using it!) I advise against it. Just follow good practices and use thin wrappers and functions. Don't get all OO googlie eyed and try to over-engineer and over-OO the code. OO is great for some things (like a User class) but don't start making some OO page renderer or form builder. Don't fall into the DB Abstraction trap either -- just use a wrapper around your DB calls (see attached), so you can swap out that wrapper if (and you almost never do) you change the DB. Don't be suckered by something like QuickForms -- you WILL run into limitations that you can't get around and are at their mercy. Don't buy the hype that DIV's are the magic bullet and TABLEs are poor design -- Tables are still the best and most ubiquitous way to align things in a browser agnostic way (including mobile phones, etc.) and to layout forms. I agree and disagree. I agree there's waaay too much herd mentality in the programming field. (Fortunately, Linus Torvalds didn't listen to the academics who insisted that microkernels where THE WAY, or we wouldn't have Linux today.) OO is nifty for some things, but it's certainly not the fountain of reusability it was originally promoted to be. And I also agree about tables versus CSS. I can render a page very precisely with tables that would take me hours to get right with CSS. And I really don't give a crap about what experts say about anything. I find experts to be wrong much of the time. OTOH, I just finished writing about 80K lines of PHP/HTML, all by hand, no OO, no classes, no nothing. Each page in one file, except for a few helper functions in a couple of common files. I wouldn't want to go through that again. I've opted for a framework on rewriting this code, just to cut down on the number of lines of code I have to manually write. But I built my own framework, which doesn't call in 20 files for each page load. Very compact. Probably not suitable for every kind of project, but it works for this.
[PHP] Regular Expression differences between 4.4 and 5.2
Hi everybody, I'm trying to migrate our PHP code base to PHP5. For the most part the transition hs been smooth however I'm really stuck on a regular expression which gives different results in 4.4 and 5.2. I've looked through migration guides but as far as I can see nothing should have changed in Regex handling between the versions. I've created the following script below to test the match: ?php include( 'input.inc' ); $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/si; preg_match_all( $pattern, $string, $matches ); echo phpversion(); var_dump($matches); ? Input.inc contains the string that is giving the different results - its probably to long to include so you can find it at http://www.workingweb.nl/example/input.inc. The results of this being run can be seen at: PHP4 (desired result) - http://www.workingweb.nl/example/php4results PHP5 - http://www.workingweb.nl/example/php5results If the pattern modifier 's' is removed the regex behaves consistently again (but this breaks other pages on our website so can't be used as a workaround). Besides I don't see why that should make any difference. Here is the version information from the PHP CLI versions I've been testing with: [EMAIL PROTECTED]:~$ php4 -v PHP 4.4.4-8+etch6 (cli) (built: May 16 2008 15:59:34) Copyright (c) 1997-2006 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [EMAIL PROTECTED]:~$ php5 -v PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies Any help on this would be very appreciated. Thanks, Ewen
Re: [PHP] Regular Expression differences between 4.4 and 5.2
Hi Jochem, Replacing the 's' modifier with 'm' fixed it this instance but broke other parts on the site (the same result as removing 's'). But the other regex ( $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/Ui;) is working perfectly. I will continue to test and see if it throws up any other problems. Many thanks for such a quick and great response. I will file a bug report however I may need to submit the full test string as cutting it down any further seems to 'fix' the discrepency. Thanks again, Ewen 2008/9/12 Jochem Maas [EMAIL PROTECTED] Jochem Maas schreef: Ewen Cumming schreef: Hi everybody, ... BUT I may have work around for you, try this regexp (replaces s modifer with m modifier): $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/mi; the following pattern also seems to do what you want: $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/Ui; Im interested to know if either of these two solve your immediate issue.
Re: [PHP] Regular Expression differences between 4.4 and 5.2
Actually bummer - testing on wrong version. The U modifier is causing problems too - only matching the first character instead of the whole string. 2008/9/12 Ewen Cumming [EMAIL PROTECTED] Hi Jochem, Replacing the 's' modifier with 'm' fixed it this instance but broke other parts on the site (the same result as removing 's'). But the other regex ( $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/Ui;) is working perfectly. I will continue to test and see if it throws up any other problems. Many thanks for such a quick and great response. I will file a bug report however I may need to submit the full test string as cutting it down any further seems to 'fix' the discrepency. Thanks again, Ewen 2008/9/12 Jochem Maas [EMAIL PROTECTED] Jochem Maas schreef: Ewen Cumming schreef: Hi everybody, ... BUT I may have work around for you, try this regexp (replaces s modifer with m modifier): $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/mi; the following pattern also seems to do what you want: $pattern = /!T_([^ ]+)([^]*)(.*?)!T_end\\1|!T_([^ ]+)([^]*)/Ui; Im interested to know if either of these two solve your immediate issue.
