This might be a bit hard for me to explain, but I will try anyway.
In my PHP application, I have a main navigation which leads to different "Trackers", where I add a parameter "?trk=1" to the end of the URL for example.
I have a secondary navigation which I need to be different for the different "Trackers" in the system. From the main tracker page, I can easily get the id of the "trk" parameter, and create the secondary navigation based on that. But, my app has many sub-pages below the "Tracker" level. For example, every Tracker has Programs, where the Programs have Projects, etc.
One of the solutions I was considering was passing the "trk" parameter through all my pages. This way, my tracker.header.php file (which is run in all levels below the Tracker level in my app) could correctly generate a custom secondary navigation for each Tracker.
I was sorta thinking I could make a class for my secondary menu. I would create this menu object in tracker.header.php and I would then have access to this object variable throughout all lower levels which would then be very easy to customize per tracker.
Is it standard to hold all HTML generated in PHP in variables and then just echo the variables in the very last lines of the application?
Yes, it is fairly standard to have a single entry page (index.php) and all pages called are merely index.php with parameters either via GET or POST. Many people also use apache rewrites to hide the fact that they are doing this.
In your example, you might have a URL such as this: "./index.php?trk=1&prog=23&proj=12" and you would have to decide what to do in the event that a particular parameter was not passed.
It is also common to hold page state information in a session.
I think there's two questions in your post, but I'll do what I can to answer them:
If you need to pass along a category that's buried within other categories, there's a few ways to go about it, some easier than others. One such approach would be to append the chain of categories browsed in the URL itself. For example, ?trk=123&program=456&proj=789 could be reduced to ?trk=123|456|789 where the script splits trk every pipe character. If the end section is missing, you can assume it hasn't been set yet.
Also, it is common practice to output the page while it's being generated, usually with echo or by escaping the PHP tags for static HTML. If you're going to be sending a large page (such as one with a large amount of table data in the middle), then waiting until the page is fully generated may cause some browsers to assume the server has stopped responding. Also, in such situations it may be advisable to somehow make the giant midsection of the webpage asynchronous so users won't get impatient.
Related
I've just started learning PHP and just done with $_POST/$_GET.
Now I want to know, what is the pro's and con's of having the PHP to process the data from a form inside the same file, or send the data to another file (action="anotherfile")?
Logically I will think that sending it to another file would increase the time process it, but is that true?
When I have the PHP script inside the same file, the page doesnt seem to reload when I hit the submit button (but the content changes). Or does it? If it does, wouldn't the only difference would be that I would have to type the script for the menu (lets say you have the same menu on all pages) in both files? Which would lead to more coding/less space?
what is the pro's and con's of having the PHP to process the data from a form inside the same file, or send the data to another file (action="anotherfile")?
You are conflating files and urls.
By having the logic split between different files (and then included where appropriate) you seperate concerns and make your code easier to manage.
By having a single URL be responsible for both displaying the form and processing the form data you don't end up in the awkward situation where the result of processing the form data requires that you redisplay the form with error messages in it. If you used two different URLs there you would need to either display the form on the processing URL (so you have two different URLs which display the form) or perform an HTTP redirect back to the original URL while somehow passing details of the errors to it.
Logically I will think that sending it to another file would increase the time process it, but is that true?
No. It makes no difference on the time scales being dealt with.
When I have the PHP script inside the same file, the page doesnt seem to reload when I hit the submit button (but the content changes).
It does reload.
If it does, wouldn't the only difference would be that I would have to type the script for the menu (lets say you have the same menu on all pages) in both files?
That's what includes are for.
In any language we always try to write clean code. That's why we follow MVC.
Logically I will think that sending it to another file would increase the time process it, but is that true? I think NO.
Because when we send data to another page and on another page at the top we echo that post data and exit. you will see it will not take time. it take time when we redirect/load some html page after that.
It does not matter where we sending data (same page or another page). matter is what is loading after that.
There is no difference about speed.
Whetever you post the content of your form in standard submit, this data will be sent to the server and a response (after processing ) will be downloaded.
The only difference is about organization of your code. The logic that draws themplate of page (menu or other fixed parts) should be stored in some file that you can include separately or call by a function.
Is also true that when you post your data you do for some reason, register a user for example. Is a good pratice that the php file that handles user registration will do that and output the messages and not other functions.
If your file has some logic switches that make it output either an empty form or a a registration message based on the presence of post or get variables, you will notice that when you scale to more complex tasks this will add complexity and make code mantainment harder.
I'll try to make sure I understand your question by restating it.
If you have a form (/form.php), and the "action" of that submit button leads you to a separate php page (/form_action.php), there is absolutely no difference in speed. Each HTTP request (form.php and form_action.php) is independent - "form_action.php" doesn't remember anything about "form.php" unless you pass that information through (as parameters). This is what people mean when they say that HTTP is stateless. It's worth learning about how HTTP works in general alongside the details of PHP.
If you have a PHP script which in turn includes other PHP scripts, there is a tiny performance impact - too small to measure in pretty much any case I've ever come across.
However, using includes allows you to separate your markup (the HTML) from the logic (the PHP). This is a really good thing if you are doing anything other than tinkering. It allows you to re-use functionality, it makes it much easier to change and maintain the code over time, and it helps you think through what you're trying to achieve.
There are many different ways people have solved the "how do I keep my code clean" puzzle; the current orthodoxy is "Model-View-Controller" (as #monty says). There are also PHP frameworks which make this a little easier to implement - once you've got the basics of the language, you might want to look at Zend or TinyMVC (there are several others, each with their benefits and drawbacks).
Apologies in advance for the lengthy post, just trying to explain the situation clearly.
I've created a PHP-driven website for searching a big (millions of records) MySQL database of people. On the search page you have your usual form for search criteria. Due to the way the people often use the site, the search criteria are saved into session variables so that if the search page is reloaded the previous criteria remain in the form fields (there's a button to manually reset the criteria, of course). This in itself works fine.
I also have two language selection links that store the language selection in a session variable (making the page header load an appropriate localization file), and as above, this in itself also works fine.
What's problematic is that when a user gets the search result, a list of people, and wants to open up detailed info on a person (thus going from search.php to info.php) and then wants to go back to the people listing via the back button, it takes too long to reload the previous page as the page re-sends the MySQL query etc, instead of going back to a cached page. It can take even 5 seconds or more sometimes as the queries produce up to 5000 results - but even say, 200-500 results takes long to reload because the database itself is big and not the fastest in the world. And limiting the number of results isn't really practical.
The obvious solution at first glance would SEEM to be enabling the browser cache. Which is exactly what I did via PHP header and pragma controls. And all seemed well, as going back to the list was basically instantaneous. However, I realized that enabling the cache means the updated session variables don't work. New search criteria doesn't properly replace the old ones when reloading the search page after having been to a different page, and even though you select another language, pages open up in the language you previously were using, because that's the way they were cached! You can force the language to update via F5, but that doesn't seem to help the search criteria much. But even if it did, F5-spam isn't really an answer, it needs to work automatically.
So long story short, how do I make the search result list open quickly without making session variables useless? Or will I simply have to make do with sluggish page loads when using back button, thus annoying users? I really don't want to open the info.php in a new page, either.
Have you considered caching the database results on the file system? I have found the Zend Framework caching class to be very easy to use. You can use any information you want, to differentiate cached results from other cached results. So the caching can be as fine grained as required.
http://framework.zend.com/manual/1.12/en/zend.cache.introduction.html
You don't need to use the whole of Zend Framework to use the class. You can use it on its own.
Ok what I am trying to make is a system that supports tickets. Tickets have all kinds of info on a specific job. How can I make a ticket menu with like links to tickets which contain all the info I need. For instance I click on ticket number 777 so it I have the php?id=777 in the url.
I need this page to constantly look for new tickets.
what you need to do is add a the correct ticket to an anchor
Ticket 777
Ticket 778
on the page.php you can access the ticket number using the $_GET variable
<?php
$ticket = $_GET['id'];
/// now you have the ticket number in the variable
?>
I need this page to constantly look for new tickets.
I'm not 100% sure what you're exactly looking for here, but there are two basic solutions here:
AJAX to update the content without reloading the page
Reload the page every few minutes and have PHP handle it
The first is better for things that are constantly updated, like Twitter posts, news, stock-tickers, etc, but it's a little overkill for something that updates relatively rarely (takes longer than 6 minutes or so).
The tickets should be stored in some kind of database and then read out and looped over to create the table. This would probably make more sense in a list format (stacked divs) instead of a table, but then again, I don't know the specifics.
For the simple PHP generation of links, #Ibu has a good example.
EDIT:
For more information about implementing AJAX, this page has a good example. I would recommend using a framework like jQuery or MooTools to handle the AJAX because there are some inconsistencies between browsers.
EDIT:
From the comments you made, it sounds like you are not very familiar with how PHP works.
PHP is just a templating language with some programming language features. It is best used to generate pages on the fly with dynamic content from a database.
When you try to request a .php page, you are actually telling the server to execute the code in that file. When all the code is finished, the resulting document is given to the requesting browser. The result should be valid HTML if done correctly.
I am syncing sessions between two different domains for Magento using a token passing technique with a remote iframe or img. I am about to implement it into Magento and was looking for some pointers.
I will have to do two things:
Every 5 mins, output an iframe or img with a remote SRC attribute for the second domain.
Q. Where is the best place to implement this? In the past I did storewide actions by overriding the renderLayout() method in Magento. Should I just do it by appended a block to the end of the page load? If I use a block, is it still keeping MVC?
I need to sync the session on the other domain when the script is called. I need to set the same cookie that Magento would set, that links to that session for the user.
Thinking about this, I think I am going to have to load Mage::app or whatever the call is that loads the Magento environment.
Q. Is there a lighter way of doing this?
Just for better understanding of what I am doing, here is a quick description of the flow.
User goes to Site A. If its time to sync the sessions, an IMG or IFRAME is outputted with SRC pointing to site-b.com/sessionSyncer?token=SHA1TOKEN
sessinSyncer validates the token and if so, creates a session and sends the cookie to the browser for the session. This should happen in a Magento manner
I am aware that Magento has the ability to pass session through the URL and generates the links to do so, but this is inadequate because the user must only switch sites using those special urls, plus the URL becomes ugly.
Thanks in advance!
Overriding renderLayout is overkill. Instead create a block that outputs your img tag and include it in the base theme, perhaps for the area before_body_end, that will safely place it on all pages.
Inventing your own token is also overkill since Magento is using the PHP session identifier and places it automatically for foreign domains. Your custom block might generate the URL with this:
$this->getUrl('OTHER/STORE/PATH', array('_store' => 'YOUR_STORE_CODE'))
If you think your script is going to need Mage::app() then you might as well use a controller which is a similar effort. On encountering a SID value the session will be updated behind the scenes, cookies set etc.
It using an iframe it doesn't need to output anything and if a small image can be static like this:
print "GIF89a\1\0\1\0\x80\0\0\xff\xff\xff\xff\xff\xff!\xf9\4\1\n\0\1\0,\0\0\0\0\1\0\1\0\0\2\2L\1\0;";
P.S.
When creating the URL of the foreign store without an SID use the _nosid parameter to force a clean URL.
Store sessions in DB and replicate database tables or entire databases it's much easier. You can configure that in your local.xml
<session_save><![CDATA[db]]></session_save>
I'm starting a experimental project and I was looking for advice to choose the best option I have.
The project will be on the 100 - 1,000 user count. It collects its main data using javascript + json data from the user's flickr page and then uses that to display specific flickr photos. The variables that need to be stored include user specific URL slug, and maybe 4 more short string variables. That all will need to be looked up on each page request. These variables will not change by time unless the user visits update page, and so these variables are static 99% of the time.
Each user's page will be located at /user-slug
I have thought out three options though I do not want to limit myself to these three (please offer your own), not being an experienced coder at higher access counts, I was looking for the fastest, most static & cacheable, least resource consuming way of achieving this, and I'm sure you guys are far more clever than I am at achieving this.
for the N amount users:
completely static approach: N static html pages are created, each user page is updated whenever asked, htaccess mod-rewrite is used to make each html file resemble a directory access. Updating; Php is used to rewrite the static pages when user asks them to be updated, or a full N user rewrite is performed when template needs updating. Most of the in-development code resides in a javascript file so the template itself will probably not be edited as frequently. Each time a user page is called, a static html file is displayed, javascript collects data from flickr server and displays it.
half static approach: Php + mod rewrite is used to simulate the different N user pages, user slug and only user slug is stored in MySQL database, then user specific variables are loaded via individual unique static texfiles named after the user slug (user-slug.txt) via javascript by the browser client (this data is not sensitive). Each time a page is called, 1 MySQL call is made and 1 extra txt file is loaded in the header via javascript. Javascript collects data from flickr and displays it.
full dynamic approach: Php + mod rewrite is used to simulate the different N pages (as the above method). All user specific variables are stored in MySQL. Each time a page is called, about 4 MySQL calls are made, Php creates the template page using those variables. Javascript collects data from flickr and displays it. In this method, which I believe is the more common approach to multi-user websites, I am also looking for ways to make these php/MySQL calls cacheable on the server itself. I'm on shared hosting btw, I don't have any low level access to the configuration itself.
Thank you so much for your input
Very, very appreciated!
I'd start with the full dynamic approach.
Then based on profiling and performance move those parts to caching that cost the most resources.
As they say 'premature optimization is the root of all evil'. Don't try to think what will take the most resources, but measure it by profiling time and memory usage.
I'd go with full dynamic as well. Though try your best to make whatever javascript/css you have static so it can be linked from an external file and not generated.