Re: [PHP] designing a post fix
@Nergin: are you trying to create an application like Squirrel Mail using PHP? On Thu, Mar 17, 2011 at 9:46 PM, Jason Pruim li...@pruimphotography.comwrote: So what exactly is the question? Jason Pruim On Mar 17, 2011, at 11:23 AM, Negin Nickparsa nickpa...@gmail.com wrote: i want 2 design a php web for staff members that can sign in with their accounts n then mail 2 each other i don't know how it really works by using a mail server i'm beginner at it! but i studied alot abt it. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP-WEBMASTER] php with htmlspecialchars function
Well Lisa, that is exactly the way htmlspecialchars is supposed to work. Here you could also display - Test - without using any function at all, simply echo a href='test'Test/a; and this should work well. NetEmp On Fri, Mar 11, 2011 at 11:51 PM, Daniel Brown danbr...@php.net wrote: On Fri, Mar 11, 2011 at 13:07, Lisa Nguyen lisa.ngu...@jpl.nasa.gov wrote: Hi I use one of your example to test the htmlspecialchars : ?php $new = htmlspecialchars(a href='test'Test/a, ENT_QUOTES); echo $new; // lt;a href=#039;test#039;gt;Testlt;/agt; ? On my browse, it display like below a href='test'Test/a Instead: Test Please help me how display on browse only Test, not like view source. First, this isn't a support channel. Please view http://php.net/support for a brief list of available support methods. The list you want is PHP General (CC'd on this email, and you can subscribe at http://php.net/mailinglists ). Second, you're using htmlspecialchars(), which is converting the and to lt; and gt; respectively, which will cause the browser to display it as if it was source (though viewing the source of that would show you the entities). Instead, check out strip_tags(), which is likely what you want: http://php.net/strip_tags -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Zend Framework - getParam() Question
Hi Dan
One method for this is to use URL Rewriting (which can be implemented on
Apache using htaccess).
Through URL Rewriting you can first make the following URL:
http://www.website.com/article-clean-url
http://www.website.com/article-clean-urlto internally behave as the
following:
http://www.website.com/index/user/ http://www.website.com/index/user/11
http://www.website.com/index/user/1and then you can use the same getParam
method to grab the value and carry out further processing.
Hope this helps.
Cheers
NetEmp
On Sat, Mar 12, 2011 at 10:04 AM, Dan Joseph dmjos...@gmail.com wrote:
Hi Everyone,
Zend Framework getParam question
I'm trying to get a value from the url...
I know how to grab:
http;//www.website.com/index/user/1
that's the index controller, $this-_getParam('user'); (value = 1)..
What I'd like to be able to grab is just off one thing from the url...
example.. I want to give an article a unique/clean url... so, when I go
to:
http://www.website.com/article-clean-url
I can somehow grab that 'article-clean-url' as a value and use it for a
lookup in the database.
I've tried everything and search all over the place. I can't find the
answer. Can someone tell me how this is done? Thanks...
--
-Dan Joseph
Re: [PHP] $$var
As per my experience so far, there is no such depth limit existing. The only limit is imposed by the system resources (like script execution time etc.) but not by PHP. Cheers NetEmp On Sun, Mar 6, 2011 at 8:42 PM, shiplu shiplu@gmail.com wrote: Just being curious, I have a question. How many times PHP interpreter will replace this variables? I mean how deep it will be? If I use variable variables like $$a how long it will be evaluated? -- Shiplu Mokadd.im My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu Innovation distinguishes between follower and leader
Re: [PHP] Re: Somewhat OT - Stored Procedures
Hi Team I very much agree with the points shared by Florin (esp. the two rules). But unfortunately, these rules are not standards and that is where the real problem lies. The injudicious use of SPs leads to un-manageable code which is rarely portable (real life situations J which are too common to be overlooked). Hoping that everyone will stick to and follow the best practices while creating code. Regards NetEmp On Sat, Mar 5, 2011 at 6:01 PM, Florin Jurcovici florin.jurcov...@gmail.com wrote: Hi. I would always recommend stored procedures, as long as there are a very few rules obeyed: - keep them simple - they should mostly implement just CRUD operations plus application-specific searches, and should not encapsulate any other logic - use just portable SQL (well, as long as this is possible) My reasoning for using stored procedures and sticking to these rules is the following: - no matter what you do, especially with PHP, you can't achieve the same performance if you generate your SQL on the fly as when you just call a precompiled stored procedure - by keeping stored procedures very simple, and sticking to the convention of packing just CRUD + specialized searches into them, plus using just portable SQL, inasmuch as possible, you can easily switch databases - in most cases, just copying over the stored procedures does the trick - for the same reasons listed for the previous point, the readability of your application is much improved - reading users_getByLogin(:login) is IMO easier to comprehend than SELECT * FROM USERS WHERE loginName = :login, without sacrificing any performance or portability, compared to using inline SQL statements as strings The consequences of not sticking to the above listed two criteria can be very bad: - packing more than reasonable logic into the database makes your application incomprehensible - for instance company_doMonthEndCalculations() is likely to include such a huge quantity of logic, that the PHP code calling it is mostly irrelevant, and you must actually comprehend both the details of the SQL in the database (in the stored procedures) and the way PHP is connecting them to understand an application - obviously harder if you have all your logic in just one place - using non-portable SQL may be quite a deterrent from porting to a new database, or may cause a lot more effort than needed, and isn't in fact justified in most cases - whereas if packing only very specific and simple operations into stored procedures allows you to keep the design of the PHP application very object-oriented, packing very much logic into stored procedures may cause your PHP code to be just an adapter to an application written in SQL, instead of being the application itself; SQL being procedural, your application will have all the flexibility, extensibility and maintainability problems that a non-OO design causes br, flj -- Fine counsel is confusing, but example is always clear. (Edgar A. Guest, The Light of Faith) PS: I'm not trying to be a smart-ass, but IMO stored procedures are underrated (not just by PHP programmers), and it's a pity (and it leads to sub-optimal applications, and to the development of cures for the symptoms instead of the cause, at least on other platforms than PHP), and not letting a database do what it does best is simply stupid. That's why I try advertising their use whenever I have an opportunity. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Somewhat OT - Stored Procedures
Hi Team I very much agree with the points shared by Florin (esp. the two rules). But unfortunately, these rules are not standards and that is where the real problem lies. The injudicious use of SPs leads to un-manageable code which is rarely portable (real life situations J which are too common to be overlooked). Hoping that everyone will stick to and follow the best practices while creating code. Regards NetEmp On Sat, Mar 5, 2011 at 6:01 PM, Florin Jurcovici florin.jurcov...@gmail.com wrote: Hi. I would always recommend stored procedures, as long as there are a very few rules obeyed: - keep them simple - they should mostly implement just CRUD operations plus application-specific searches, and should not encapsulate any other logic - use just portable SQL (well, as long as this is possible) My reasoning for using stored procedures and sticking to these rules is the following: - no matter what you do, especially with PHP, you can't achieve the same performance if you generate your SQL on the fly as when you just call a precompiled stored procedure - by keeping stored procedures very simple, and sticking to the convention of packing just CRUD + specialized searches into them, plus using just portable SQL, inasmuch as possible, you can easily switch databases - in most cases, just copying over the stored procedures does the trick - for the same reasons listed for the previous point, the readability of your application is much improved - reading users_getByLogin(:login) is IMO easier to comprehend than SELECT * FROM USERS WHERE loginName = :login, without sacrificing any performance or portability, compared to using inline SQL statements as strings The consequences of not sticking to the above listed two criteria can be very bad: - packing more than reasonable logic into the database makes your application incomprehensible - for instance company_doMonthEndCalculations() is likely to include such a huge quantity of logic, that the PHP code calling it is mostly irrelevant, and you must actually comprehend both the details of the SQL in the database (in the stored procedures) and the way PHP is connecting them to understand an application - obviously harder if you have all your logic in just one place - using non-portable SQL may be quite a deterrent from porting to a new database, or may cause a lot more effort than needed, and isn't in fact justified in most cases - whereas if packing only very specific and simple operations into stored procedures allows you to keep the design of the PHP application very object-oriented, packing very much logic into stored procedures may cause your PHP code to be just an adapter to an application written in SQL, instead of being the application itself; SQL being procedural, your application will have all the flexibility, extensibility and maintainability problems that a non-OO design causes br, flj -- Fine counsel is confusing, but example is always clear. (Edgar A. Guest, The Light of Faith) PS: I'm not trying to be a smart-ass, but IMO stored procedures are underrated (not just by PHP programmers), and it's a pity (and it leads to sub-optimal applications, and to the development of cures for the symptoms instead of the cause, at least on other platforms than PHP), and not letting a database do what it does best is simply stupid. That's why I try advertising their use whenever I have an opportunity. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Vivek 88 6096 7077
