Using PHP, HTML and Javascript.
With PHP we are using a MVC Framework.
I have a fundamental question regarding web communication, that perhaps someone could clear some things here.
REST apart, and taking only "post" and "get":
Let's say that, if we do:
http://blabla.com/companyA/income/
It will list all income of a given company.
If we do:
http://blabla.com/companyA/income/2010/
It will list all income on 2010 for that company.
And so on.
Now, I wish to allow the user to, from a html form, select some values, and according to those values, return, from the server, the appropriate data.
How does this work?
a) Should we concatenate the URL string on the client side, (form action) and send it to the server side?
b) Our, should we send the params to the server side, and it returns the URL?
Anyway will work? Only one way will work? What are the consequences of those paths? Is there a third possibility?
a) Should we concatenate the URL string on the client side, (form action) and send it to the server side?
That's how it's always been done historically and it still works fine. It's the equivalent of constructing the complete HTML by hand, but using PHP (or any server side language) to help you remove manual labor, by basing the HTML on the data you have easy access to.
b) Our, should we send the params to the server side, and it returns the URL?
That's unnecessary, you already have all the data ready so going with a) is more solid since it lets the client become a bit dumber, by excluding the render-url-from-arguments logic.
Is there a third possibility?
Yes. Since you already expose lists of resources at /companyA/income/2010/ (perhaps through JSON), you could serve an empty page from the server side, trigger an ajax call to your backend and generating the list dynamically on the client side. This brings a bunch of things to think of, some are:
How is SEO affected when (google) bots request empty pages?
Can we reuse the rendering logic for different views, without reloading the empty page?
You could read up on SPA, or, Single-page applications.
You should make url when processing with PHP, so you can pass ID or any other information from server. Making URL from client side requires additional processing.
<form action="companyA/income/<?php echo (int)$years; ?>">
...
<form action="<?php echo $this->makeUrl('companyA/income', $years); ?>">
...
Related
I want to know if the user has logged in or not and then display different elements of the navigation based on the username (login by email and password Not username). However, I have no idea how to deal with session. If php and html is separated in two documents, how can I store the required values using session in php document and then get them using javascript in html document? Or should I use cookies instead?
There are a several approaches to do this.
1) You can make a PHP file which will format your $_SESSION data, and all the other data you want as a JSON string (json_encode function in PHP lang). Then use echo to return it. Then use an AJAX request to get this file from javascript or JQuery, and you will receive the data you want. That's a bad approach for this purpose, from my point of view, because after loading the page you send another request to receive a static data, which will not change on the page like email or username.
2) Better approach: PHP is preprocessor hypertext. You can make an php file and write html tags in it, with php output(example: <div><?=$_SESSION['email']?></div>). Search for more info in google ("php inside html").
3) Much better. In modern web programming world its a mistake to use php inside html because you should think not only about how to make something work, you should think how you will maintain it after 3, 6, 12 months later, too. If you use just php inside html in a big project, then, with time, you realize that your code is hard to read and looks ugly. There are plugins that can make your view more readable and maintainable (Twig, Blade, Volt and others). I recommend you use one of them.
The session is a server side thing, you cannot access it using javascript. You can write an Http handler (that will share the sessionid if any) and return the value from there using AJAX
Many places have said that only elements with a name attribute go to the server on page change, and only the element name and its value attribute's value travel between client & server. Is this a PHP feature or is it also present in other scripting languages? For example, is this the case with Node.js, or any of its popular server frameworks like express or grunt? Also, are there ways to send other elements or attributes to the server?
I know that AJAX can cause pretty much anything to go to the server, but this is usually asynchronous, and even when it isn't the info doesn't usually go to the server right when the page is sent. If you have any relevant info on AJAX, though, please share it.
When you give an element a name attribute, the browser will send the form data in the body of the request (if using POST) or in the query string (if using GET). This happens no matter what language or framework you use.
name is the only attribute that does this - it will not work with an id - but you can also do this with AJAX, by passing a querystring to XMLHttpRequest.send (if you're using jQuery, read up on jQuery.post). Requests via AJAX are, to the server, identical to requests from the client. If you send data in an AJAX POST request, it will be identical to a request via an equivalent form to the server. This is the same whether you're using PHP, Node.js, or any other web framework.
Helpful references:
http://en.wikipedia.org/wiki/POST_(HTTP)
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Sending_and_retrieving_form_data
I am developing a web app which functions in a similar way to a search engine (except it's very specific and on a much smaller scale). When the user gives a query, I parse that query, and depending on what it is, proceed to carry out one of the following:
Grab data from an XML file located on another domain (ie: from www.example.com/rss/) which is essentially an RSS feed
Grab the HTML from an external web page, and proceed to parse it to locate text found in a certain div on that page
All the data is plain text, save for a couple of specific queries which will return images. This data will be displayed without requiring a page refresh/redirect.
I understand that there is the same domain policy which prevents me from using Javascript/Ajax to grab this data. An option is to use PHP to do this, but my main concern is the server load.
So my concerns are:
Are there any workarounds to obtain this data client-side instead of server-side?
If there are none, is the optimum solution in my case to: obtain the data via my server, pass it on to the client for parsing (with Javascript/Ajax) and then proceed to display it in the appropriate form?
If the above is my solution, all my server is doing with PHP is obtaining the data from the external domains. In the worst (best?) case scenario, let's say a thousand or so requests are being executed in a minute, is it efficient for my web server to be handling all those requests?
Once I have a clear idea of the flow of events it's much easier to begin.
Thanks.
I just finish a project to do the same request like your req.
My suggestion is:
use to files, [1] for frontend, make ajax call to sen back url; [2] receive ajax call, and get file content from url, then parse xml/html
in that way, it can avoid your php dead in some situation
for php, please look into [DomDocument] class, for parse xml/html, you also need [DOMXPath]
Please read: http://www.php.net/manual/en/class.domdocument.php
No matter what you do, I suggest you always archive the data in you local server.
So, the process become - search your local first, if not exist, then grab from remote also archive for - 24 hrs.
BTW, for your client-side parse idea, I suggest you do so. jQuery can handle both html and xml, for HTML you just need to filter all the js code before parse it.
So the idea become :
ajax call local service
local php grab xm/html (but no parsing)
archive to local
send filter html/xml to frontend, let jQuery to parse it.
HTML is similar to XML. I would suggest grabbing the page as HTML and traversing through it with an XML reader as XML.
A simple user registration may be completed by PHP (framework: Codeigniter,etc..) and Javascript.Following is simple flow:
PHP
A registration view with form input(user_name,e-mail,password)
post the data to an controller to validation
-Pass, redirect to a completion view
-Failed, go back to the registration view with some alert strings.
Javascript
A registration html with input text(user_name,e-mail,password)
Validation could be done by Javascript directly before submit; Alert strings could be
generated by Javscript. Even submission could be done by ajax. Then redirect to the
completion page.
I found myself code more javascript less PHP. Even the user registration could be done without the "form" tag,right? I am afraid of some parts I had miss or ignore.
Could someone gives me an simple comparison of good/bad parts about these two methods?
User registration details have to be stored on the server. You can use any language you like there, JavaScript (node.js is the current preferred way to achieve that), Perl (PSGI/Plack), Python (WGSI), C# (ASP.NET), PHP (mod_php), whatever. If you did it entirely with client side JavaScript, then the registration would exist only for a particular browser (which makes it rather pointless for almost anything on the WWW).
You can do a lot of things with client side JavaScript.
You can test if the data enter by the user conforms to the requirements you've set (such as "usernames contain only ascii alphanumeric characters").
You can't stop data that doesn't conform to those requirements being submitted to your server though - everything outside your server is beyond your control. Users can edit your pages in their browser as much as they wish. Client side validation is a convenience to the user (giving feedback without a server round trip and page reload), nothing more.
You can use Ajax instead of an HTML form … but there is no reason to do that. It just adds an unnecessary dependancy on JavaScript. That doesn't mean Ajax can't be useful, you could use it to ask the server if a username was already taken while the user is filling out the rest of the form.
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).