Fifteen years of software development has taught us that no technology lasts forever. It is inevitable that software will be rewritten, and for a second generation website, emulating the telltale signs of the previous technology can be a real chore. Telltale signs are the suffixes such as .php for PHP, .jsp for Java Server Pages etc. We therefore have chosen to adopt a URL style that avoids suffixes and question marks (?) for one-subject pages.
Preferred URL style:
Even the “innocent”
.html used for static pages must be avoided. Because what is
static today will be dynamic tomorrow. If the page has .html as its suffix then to
achieve persistence the webserver must often be configured to return dynamic
pages for all .html pages. Then you get into conflicts over which
technology has the privilege to serve .html pages. If you employ
you can let your static page with the name “tasks.html” be available on the
webserver as http://www.eionet.europa.eu/tasks. Then if you need to make it
be generated dynamically, you just set it up as tasks.php and still make it
available as http://www.eionet.europa.eu/tasks.
Another example of bad style is when the same source file is used to contain the information that really belongs in two or more files.
This can be fixed with a simple RewriteRule in Apache, making the user see http://...eionet.europa.eu/help/2, but the application see the above. It is still better if the application did this natively.
The next example is more complex. It would be natural to split the show.jsv into two or more files. One per value for the mode parameter, and then employ the rewrite rule from the first example.
Now you can consider how to structure your website to match the URL style. A static website is just a hierarchy of folders and files, and there is not much to design. It gets much more interesting when certain pages are operations on a database.
Eionet operates with a object oriented paradigm. It is something we have inherited from Zope. The principle is: Folder/Folder…/Object/method.
To view an object, you would normally need “r” permission for
This example is somewhat misleading. You should implement an insert-operation as a HTTP POST, as it changes state, but the POST operation
doesn't put the arguments in the URL, and therefore wouldn't be an understandable example.
To insert an object, you would normally need “i” permission for
/obligations/374 do? It would in most circumstances be a default view-operation,
just like Apache shows
index.html for a folder.
Exactly what parts of the object is viewed is up to the developer to decide.
Document last modified 2012/07/17. Content in this portal is modified daily by a community of providers.