Can any one explain this?
Hardcoding the request URLs is a best practice for functional tests. If the test
generates URLs using the Symfony router, it won't detect any change made to
the application URLs which may impact the end users.
http://symfony.com/doc/current/book/testing.html#working-with-the-test-client
What sort of changes are they referring to? Why is this a problem if all url are generated using the router?
If a url changes, it affects bookmarks, links from other sites, page rank... If you test using a generated url, the test will succeed, even if you (accidentally) changed the url pattern.
By using hard-coded urls you can prevent this from happening. The test will fail if you accidentally change the url. If you meant to change it, you can just update the hardcoded url to match the new situation. This way you are in control.
For some applications, or some urls within a specific site or application, it might not matter at all if the url changes. In that case, you can generate the url of course. It's a general advice, not a law. :)
If URLs are not hard coded, the template code for generating a URL might look like:
{{ path('examplebundle_home_action') }}
Which the router will then expand to:
http://www.example.com/action
If your functional test refers to the path call as above, suppose that you change the path for the action, so that the URL is now:
http://www.example.com/newaction
Since your tests refer to the path call, they will continue to pass, since they seamlessly refer to the new URL. However, your users may disagree -- they may have bookmarked the old URL, or it may be referred to outside of Symfony elsewhere in your application, and so on. It is always dangerous to change a URL without fully understanding the impact, and having it hardcoded in a functional test is a good reminder that something significant has changed.
Related
I think I have a weird/complicated situation but I think I'm overlooking something simple. We are setting up a Yii application that will host other "skins" people set up. It's basically one big community but on many different sites. Everything will be handled by one single common core Yii application.
Our plan is to allow two different URL configurations depending on what the skin owner wants to do:
1) whatever.theirsite.com (which is set up as a CNAME to portal.oursite.com - for advanced users)
2) portal.oursite.com/theircommunity - for those who just want it to work with no other configuration
In the first case, it's easy enough to pick out the SERVER_NAME variable, look up the correct theme in the database, and serve up the correct theme/community. I have actually done this in the past and it works fine. However, I'm a little lost on the second case. I can still do the db lookup to find out what theme to serve from portal.oursite.com/theircommunity, but all the routing gets screwed up because theircommunity is not a controller. It's more like a virtual directory but its dynamic. I feel like I'm missing a simple htaccess or possibly a UrlManager rule.
Valid example urls would be:
http://whatever.theirsite.com/mycontroller/myaction
http://portal.oursite.com/theircommunity/mycontroller/myaction
or for a module:
http://whatever.theirsite.com/mymodule/mycontroller/myaction
http://portal.oursite.com/theircommunity/mymodule/mycontroller/myaction
In all cases, both pairs of requests need to go to the same place. Backend processing ensures that they look different but are handled by the same code.
Any advice?
Edit:
One solution I thought of but haven't tested yet (not sure if it is a good idea or not, or if it would even work) would be to extend the URL manager to add new routing rules depending on which community is being asked for.
ex:
before application runs, do a db lookup to figure out which theme we
are using.
if the theme uses a virtual root, then copy all existing url manager rules but append theircommunityname/ to the front of them.
Yes, I think your edit/URL manager setup is probably going to be your best option.
For what it's worth, those routing rules are going to look similar to the module routing rules, so you might be able to fake load a module that has the appropriate name using an app behavior. I did something similar for a client last year; it worked, but was complex. I would suggest your start getting comfortable writing unit tests against this system, you'll want them to make sure you don't break things in the future :-)
Interesting question! I may be way off mark here. But would something like this work?
/portal.oursite.com
/theircommunity1/index.php
/theircommunity2/index.php
In words: create a user-specific subdirectory of your webroot.
This means that user 1 will have the /theircommunity1/index.php entry script. User 2 will have /theircommunity2/index.php. In the entry scripts your can
Set user specific variables
include a 'secondary' entry script that may be outside the webroot.
I'm not sure I understood your scenario correctly. You can extend UrlManager and create some variable based on the site lookup. Eg $_GET['site'] = 'theircommunity'; and you can check for this variable later on your application.
This actually ended up having a simple solution but it took me a while to find it. It was simply a matter of extending CHttpRequest and setting the baseUrl property for the request in init().
if (Yii::app()->domainManager->isPortalDomain) {
// need to set the document root correctly
Yii::app()->request->baseUrl = '/' . Yii::app()->domainManager->domain->name;
}
When I did that, all routing worked and urls were created correctly.
When using english the following URL should apply:
http://example.org/services/myservice/
When using another language, the following URL should apply:
http://example.org/sirvici/misirvice/
Any easy/standard way we should handle this withing Yii ?
Yes you can do this in Yii but you will sacrifice:
Automatic Controller/Action mapping (depending how this works out)
A little speed due to the extra work load on every request.
If your still OK with that then you can go ahead with it. You need to create a custom URL rule and have it process every URL, this is well documented. Then you need to manually strip the URL apart (by also well documented methods) and translate each part from the users currently selected language ( you will need to know this unless you want to go through the hell of trying to guess a language O.o ). You now have the translations for each part of the URL. Congrats.
Heres the part that may or may not work
You can pass it back through the Yii URL parser to go through the automatic mapping of controllers and actions and parameters. This would mean your just doing a preparse on the URL and Yii continues from there.
If that can't work you'll have to build your own ( piggy back off Yii a little with CUrlRule etc. ) and do the mapping logic.
My Two Sense
For most Web Apps I wouldn't recommend this. It means you have multiple ways to access the same content, from very different URLs. This is bad thing in SEO terms and also in usability terms. It also doesn't provide you with a way of mapping those back to each other particularly easily to let google know not to index your content again. Plus I can't see that it gains you a whole lot. Most simpleton users won't pay attention to the URL bar, and even if it's in their native language most won't deduce much about the page and it's content from the wording of the URL.
Let me know if you proceed with this though, I'd like to know how it goes.
I am taking over an existing PHP project. I noticed that the previous developer uses a one index.php page for the entire site, currently 10+ pages. This is the second project that I have seen done like this. I don't see the advantage with this approach. In fact it seems like it over complicates everything because now you can't just add a new page to the site and link to it. You also have to make sure you update the main index page with a if clause to check for that page type and then load the page. It seems if they are just trying to reuse a template it would be easier to just use includes for the header and footer and then create each new page with those files referenced.
Can someone explain why this approach would be used? Is this some form of an MVC pattern that I am not familiar with? PHP is a second language so I am not as familiar with best practices.
I have tried doing some searches in Google for "single index page with php" and things like that but I can not find any good articles explaining why this approach is being used. I really want to kick this old stuff to the curb and not continue down that path but I want to have some sound reasoning before making the suggestion.
A front controller (index.php) ensures that everything that is common to the whole site (e.g. authentication) is always correctly handled, regardless of which page you request. If you have 50 different PHP files scattered all over the place, it's difficult to manage that. And what if you decide to change the order in which the common library files get loaded? If you have just one file, you can change it in one place. If you have 50 different entry points, you need to change all of them.
Someone might say that loading all the common stuff all the time is a waste of resources and you should only load the files that are needed for this particular page. True. But today's PHP frameworks make heavy use of OOP and autoloading, so this "waste" doesn't exist anymore.
A front controller also makes it very easy for you to have pretty URLs in your site, because you are absolutely free to use whatever URL you feel like and send it to whatever controller/method you need. Otherwise you're stuck with every URL ending in .php followed by an ugly list of query strings, and the only way to avoid this is to use even uglier rewrite rules in your .htaccess file. Even WordPress, which has dozens of different entry points (especially in the admin section), forces most common requests to go through index.php so that you can have a flexible permalink format.
Almost all web frameworks in other languages use single points of entry -- or more accurately, a single script is called to bootstrap a process which then communicates with the web server. Django works like that. CherryPy works like that. It's very natural to do it this way in Python. The only widely used language that allows web applications to be written any other way (except when used as an old-style CGI script) is PHP. In PHP, you can give any file a .php extension and it'll be executed by the web server. This is very powerful, and it makes PHP easy to learn. But once you go past a certain level of complexity, the single-point-of-entry approach begins to look a lot more attractive.
Having a single index.php file in the public directory can also protect against in the case of the php interpreter going down. A lot of frameworks use the index.php file to include the bootstrap file outside of the doc root. If this happens, the user will be able to see your sourcecode of this single file instead of the entire codebase.
Well, if the only thing that changes is the URL, It doesn't seem like it's done for any reason besides aesthetic purposes...
As for me - single entry point can help you to have better control of your application: it helps to handle errors easily, route requests, debug application.
A single "index.php" is an easy way to make sure all requests to your application flow through the same gate. This way when you add a second page you don't have to make sure bootstrapping, authentication, authorization, logging, etc are all configured--you get it for free by merit of the framework.
In modern web frameworks this could be using a front controller but it is impossible to tell since a lot of PHP code/developers suffer from NIH syndrome.
Typically such approaches are used when the contents of the pages are determined by database contents. Thus all the work would get done in a single file. This is seen often in CMS systems.
I have been in web programming for 2 years (Self taught - a biology researcher by profession). I designed a small wiki with needed functionalities and a scientific RTE - ofcourse lot is expected. I used mootools framework
and AJAX extensively.
I was always curious when ever I saw the query strings passed from URL. Long encrypted query string directly getting passed to the server. Especially Google's design is such. I think this is the start of providing a Web Service to a client - I guess.
Now, my question is : is this a special, highly professional, efficient / advanced web design technique to communicate queries via the URL ?
I always felt that direct URL based communication is faster. I tried my bit and could send a query through the URL directly. here is the link: http://sgwiki.sdsc.edu/getSGMPage.php?8
By this , the client can directly link to the desired page instead of searching and / or can automate. There are many possibilities.
The next request: Can I be pointed to such technique of web programming?
oops: I am sorry, If I have not been able to convey my request clearly.
Prasad.
I think this is the start of providing
a Web Service to a client - I guess.
No not really, although it can be. Its used to have a central entry point to the entire application. Its a common practice and has all kinds of benefits, but its obviously not required. Often thes days though even a normal url you see may not actual be a physical page in the application.. each part of the path may actuall be mapped to a variable through rewriting and routing on the server side. For example the URL of this question:
http://stackoverflow.com/questions/2557535/general-web-programming-designing-question
Might map to something like
http://stackoverflow.com/index.php?module=questions&action=view&question=2557535&title=general-web-programming-designing-question
is this a special, highly
professional, efficient / advanced web
design technique to communicate
queries via the URL ?
Having a centralized page through which all functions within an application are accessed is part of the Front Controller Pattern - a common pattern in applications generally used as part of the overall Model, View, Controller (MVC) pattern. In MVC, the concerns of the application are divided into the model which holds the business logic. These models are then used by the controller to perform a set of tasks which can produce output. This output is then rendered to the client (browser, window manager, etc..) via the view layer.
I think that essentially what you are asking about is query strings. In a url after a page, there may be a question mark after which, there may be URL parameters (generally called GET request parameters.)
http://www.google.com/search?q=URL+parameter
Generally, processing this would be done on the server-side. For example, in PHP, one could use the following:
$_GET['q']
The aforementioned code would be the value of the variable. Alternatively, to do this client-side, one could use anchors. Replace the question mark with a hash sign #
Since this is used for anchors, when a URL is changed to have an anchor tag, the page is not refreshed. This allows for a completely AJAX-driven page to manipulate the URL without refreshing. This method is often used also for enabling back-button support for AJAX pages.
In JavaScript, one can use the onload handler as an opportunity to read the URL of the page and get the hash part of the URL. The page could then make a request back to the server to read any neccessary data.
It's a consequence of using a front controller architecture. This fits neatly with the idea of a wiki where the same code is used to render multiple different wiki pages - the content is defined by the data.
Using the query part of the URL for the page selection criteria is not the only solution. e.g. if you are using apache then you could implement:
http://sgwiki.sdsc.edu/getSGMPage.php?8
as
http://sgwiki.sdsc.edu/getSGMPage.php/8
(you'll need to add your own parsing to get the value out.
Alternatively, you can use mod_rewrite to map components out of the path back into the query.
There's no particular functional/performance reason for adopting any of these strategies. Although it is recommended, where the URL is idempotent, that each page be addressable via a GET operation (also useful for SEO).
C.
What are the pros for using extension-less URLs?
For example, why should I change...
http://yoursite.com/mypage.html
http://yoursite.com/mypage.php
http://yoursite.com/mypage.aspx
to...
http://yoursite.com/mypage
And is it possible to have extension-less URLs for every page?
Update:
Are extension-less URLs better for site security?
The reason for extension-less URLs is that it is technology independent. If you want to change how your content is rendered you do not have to change the URL.
W3: Cool URIs don't change
File name extension
This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension....
Conclusion Keeping URIs so that they will still be around in 2, 20 or 200 or even 2000 years is clearly not as simple as it sounds. However, all over the Web, webmasters are making decisions which will make it really difficult for themselves in the future. Often, this is because they are using tools whose task is seen as to present the best site in the moment, and no one has evaluated what will happen to the links when things change. The message here is, however, that many, many things can change and your URIs can and should stay the same. They only can if you think about how you design them.
It's mostly done for aesthetic purposes.
There is a very minor potential security benefit (a user doesn't immediately know what language the backend code is written in) but this is negligible.
A related blog post.
People claim it makes for better SEO, even if I am not personally convinced of that. Many clients request these extension-less URLs nowadays, so it's just as well that it can be easily achieved.
If you are running IIS 7, you can switch the AppPool to run on the Integrated Pipeline, thereby removing the need to have specific extensions mapped to the ASP.NET engine. Once that is done, you can instruct Sitecore to use extension-less urls in the web.config setting (assuming Sitecore 6):
<linkManager defaultProvider="sitecore">
<providers>
<clear />
<add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel"
addAspxExtension="false" /* This one is set to true, per default */
alwaysIncludeServerUrl="false"
encodeNames="true"
languageEmbedding="asNeeded"
languageLocation="filePath"
shortenUrls="true"
useDisplayName="false" />
</providers>
</linkManager>
And you're set.
Be aware that early versions of Sitecore 6 had a few issues when running Integrated Pipeline. More information can be found here.
As stated, one of the advantages is that you do not tie URLS to a specific technology or language. Also, one of the advantages is that it allows you to manage the output format from within the application if you wish to do so.
But this is relevant only within a "routed" code framework, where you would basically attach url routes to code.
For instance, in my code library, you can specify the allowed output format of an url by
1) Setting an Accept header in the HTTP header
2) Attaching a valid extension to the URL
So the code for /my/simple/url.html, /my/simple/url.xml and /my/simple/url.json is exactly the same. The ouput manager will be responsible for outputing the content in the proper way.
So if you change the underlying technology, you are still able to keep the same URL pattern within the new version of you application.
From there, since you are parsing the URL withing your own code to extract the data, it generally gives you the opportunity to make SEO-friendly URL, i.e. more meaningful URLs in terms of search engine indexing. You can then define more meaningful URL patterns within you web application structure.
Because user does not need to know technology behind a page.
Example: domain.com/Programs/Notepad
Only thing I can think of is to make it easier for the end user to remember/type, other than that I don't see any reason, I also ran this by our admin and he says some say SEO but if he was to use it, he would use it for a level if security.