SEF by design?

[wr1138]

Is there any reason _not to use SEF? Just wondering whether it makes sense
from a design POV to assume the desirability of SEFness in all cases. Is there a situation where SEF links would be a disadvantage (presuming code that does not require .htaccess/mod_rewrite)?

[counterpoint]

That's a very good question And it provokes a somewhat long response!

At the basic level there is the question of how fully SEF can be implemented, and this relates to whether Apache URI rewriting is available. Without it, URIs of the form .../index.php/pseudo/path/to/something can be used, but it's not desirable to allow both since it counts as duplicate pages. (Must check how well Aliro handles that at present - in general it always sends 301 Redirect headers if it decides that it prefers an alternative URI).

On the positive side, a bundle of capabilities were added to Aliro fairly recently (not covered in my book). They both add functionality and also make packaging tidier. The features are the ability to add to an application integrated modules and plugins and also the "urilink" capability. This makes for much more integrated code and far fewer packages to be installed.

It's the urilink that is directly relevant to your question. The urilink feature allows the packaging XML for an addon application (and remember there are no so-called core applications, they're all added on) to specify a pattern of URI and relate it to a class and method.

The way the pattern is specified is to give a prototype of the URI (not including domain) that is split into units by slashes, if more than one unit, with each unit being a Perl regular expression without the bracketing characters. Incoming URIs are checked for matching, with longer patterns matched before shorter ones. If a match is found, the class is invoked (if a getInstance method exists it will be used; otherwise new) through the specified method.

This (I believe) is the foundation for the future direction of how the incoming URI will be related to software units. It is somewhat similar to the Drupal mechanism of taking the first portion of the URI (after domain) as signifying the module that is to process the input. But it is a lot more flexible and does a lot more work by routing requests to the correct detailed processing straight away.

There are two general reasons for not immediately moving everything to this mechanism, and at least one practical problem. One general point is simple familiarity. People with any Mambo family background (including Joomla) are familiar with the idea of transforming query strings to SEF strings and back again. There's a whole industry doing this! The other general point is that the urilink mechanism is new and it will take practical experience to see how it works out and to make any necessary refinements.

A practical problem to which I have no immediate solution is that people will want to have their URIs in local languages. This issue will grow in importance as web standards change to accommodate a wider range of characters in URIs. We will need to evolve a standard mechanism for dealing with translation in the packaging XML, which is not really amenable to the use of T_() as used in PHP code.

Apart from these considerations, I'd think that the use of urilinks is the way forward to better and more fully integrated SEF that is not a bolt on extra.

However, there will almost certainly continue to be a need for bolt on URI processing. Demanding web designers want to see URI strings that have no redundancy and look exactly how they want them to look. This means that devices like the inclusion of a marker word (such as "component") is unacceptable, and the need for a standardized application name at or near the start of the URI string is also unacceptable.

On account of these factors, I'd expect to see aspects of the Aliro SEF handling remain. One feature is the ability to add arbitrary regex processing to outgoing URIs (and then recognise them later!). Another is the ability to recognise URIs and use them as a basis for setting metadata, such as titles and indexing instructions for robots. This post-processing requires the final URI to be saved in the database for later recognition, which can result in a substantial volume of data for applications that generate many different URIs such as a discussion forum.

So the summary of my view is that I'd think that query strings are on the way out, but will be a long time dying because of their robustness and simplicity of implementation. And driving applications directly from a SEF URI will become more usual, but will still require some further manipulation.

[wr1138]

Originally Posted by counterpoint

Demanding web designers want to see URI strings that have no redundancy and look exactly how they want them to look. This means that devices like the inclusion of a marker word (such as "component") is unacceptable, and the need for a standardized application name at or near the start of the URI string is also unacceptable.

I have to stand in that class as well. Since the contents of the address bar are ultimately a component of the site UI (presuming its visibility), and a fundamental navigational reference (exceedingly important when the page is part of external/inevitable processing outside of site-context), it should be subjected to a stringent usability (or even outright branding!) regime. The appearance of technical parameters or non-descriptive strings would rightly be considered dilutive (or at least asemantic).

But I certainly understand the counter-forces you've outlined! Thanks!