দিগন্ত

Q:1 What are the differences between Get and post methods in form submitting. give the case where we can use get and we can use post methods? A:1 When to use GET or POST The HTML 2.0 specification says, in section Form Submission (and the HTML 4.0 specification repeats this with minor stylistic changes): ---> If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be GET. Many database searches have no visible side-effects and make ideal applications of query forms. f the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be POST. How the form data is transmitted? quotation from the HTML 4.0 specification --> If the method is “get” - -, the user agent akes the value of action, appends a ? to it, then appends the form data set, encoded using the application/x-www-form-urlencoded content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes. --> If the method is “post” –, the user agent conducts an HTTP post ransaction using the value of the action attribute and a message created according to the content type specified by the enctype attribute. Quote from CGI FAQ Firstly, the the HTTP protocol specifies differing usages for the two methods. GET requests should always be dempotent on the server. This means that whereas one GET request might (rarely) change some state on the Server, two or more identical requests will have no further effect. This is a theoretical point which is also good advice in practice. If a user hits “reload” on his/her browser, an identical request will be sent to the server, potentially resulting in two identical database or guestbook entries, counter increments, etc. Browsers may reload a GET URL automatically, particularly if cacheing is disabled (as is usually the case with CGI output), but will typically prompt the user before re-submitting a POST request. This means you’re far less likely to get inadvertently-repeated entries from POST. GET is (in theory) the preferred method for idempotent operations, such as querying a database, though it matters little if you’re using a form. There is a further practical constraint that many systems have built-in limits to the length of a GET request they can handle: when the total size of a request (URL+params) approaches or exceeds 1Kb, you are well-advised to use POST in any case. I would prefer POST when I don’t want the status to be change when user resubmits. And GET when it does not matter. Q:2 Who is the father of PHP and explain the changes in PHP versions? Rasmus Lerdorf is known as the father of PHP.PHP/FI 2.0 is an early and no longer supported version of PHP. PHP 3 is the successor to PHP/FI 2.0 and is a lot nicer. PHP 4 is the current generation of PHP, which uses the Zend engine under the hood. PHP 5 uses Zend engine 2 which, among other things, offers many additionalOOP features . Q:3 How can we submit a form without a submit button? A:3 The main idea behind this is to use Javascript submit() function in order to submit the form without explicitly clicking any submit button. You can attach the document.formname.submit() method to onclick, onchange events of different inputs and perform the form submission. you can even built a timer function where you can automatically submit the form after xx seconds once the loading is done (can be seen in online test sites). Q:4 In how many ways we can retrieve the data in the result set of MySQL using PHP? A:4 You can do it by 4 Ways--> 1. mysql_fetch_row. 2. mysql_fetch_array 3. mysql_fetch_object 4. mysql_fetch_assoc Q:5What is the difference between mysql_fetch_object and mysql_fetch_array? A:5 mysql_fetch_object() is similar to mysql_fetch_array(), with one difference - an object is returned, instead of an array. Indirectly, that means that you can only access the data by the field names, and not by their offsets (numbers are illegal property names). To be Continued ......