cotonti.com : URL gateway API

Trustmaster

пт, 26 сен 2008 01:52:21 -0000

Pretty similar to what I've started implementing. First revision is hopefully coming this week, and then we will improve it.

Kilandor:
You know we could even go so far as to add a sql row, to store pre-generated URLS, only change them if say when something is edited.

Oh, yeah, I recognize Kilandor :D

Lombi

чт, 25 сен 2008 16:22:10 -0000

Isnt that quite the same as Trustmasters proposition?

Kilandor

чт, 25 сен 2008 03:27:36 -0000

Well I kinda disagree This is a example of my plan.

We already have tons of data already in variables for every single part of the page, you don't even have to do extra query's or anything. So we can use that data with no other impact.

so here is a rough idea-example

if($cfg['customurls'])
{
	$url_data[] = $row['page_id'];
	$url_data[] = $page_alias;
	$url_data[] = $row['page_cat'];
	$url_data[] = $row['page_title'];
	$url_data[] = $cfg['mainurl'];
	// Etc so on, would store like cat/title/alias
	//maybe some others I can't think of atm
	$page_url = sed_url('page', $url_data);
}
else
{
	$page_url = 'blah the custom default url here';
}

function sed_url($area, $data)
{
	global $cfg;
	$url = vsprintf($cfg['customurls'][$area], $data);
	if($cfg['customurls'][$area]['callback'])
	{
		$url = $cfg['customurls'][$area]['callback']($url);
	}
	return $url;
}

Then we only simply need in the config area to list, what value matches. Which is a simple and easy enough task, allowing easy customizablity, a admin only need setup a string themselves like /%1$s/%2$S.html. You could even go so far as to substitute that with like special words /*category*/*title*-*id*.html, although this takes a bit more work, but would make it easier for the user. Also giving them an option to use a custom callback of their own creation, to filter/handle the url how they need.

To me this is the best way above any other to do it, we already have all the data there, all we have to do is push it into an array, and send it in, then everything is done.

And we can still use the masks to generate the mod_rewrite data as need, you have the data format in the mask of whats at each part. Even then if need, we could store whats what in a like hidden config, used by the plugin, or simply hard code what each part is if need be.

You know we could even go so far as to add a sql row, to store pre-generated URLS, only change them if say when something is edited. Just like the HTML cache does[/][/][/][/][/]

Lombi

ср, 24 сен 2008 23:38:10 -0000

sounds good.

Trustmaster

ср, 24 сен 2008 22:26:59 -0000

Okay, I have thought this feature over, also reviewed WordPress to see what most users request. I would say, exact WP way is suitable for WP since it's a very specific thing, but Seditio is somewhat much more generic on its own. So, I suppose URL management will be done with a small script in very simple and efficient "URL Transform Language" consisting of rules like:

page al=* /page/{$al}{$query_string}

Which means "for urls with area 'page' and parameter 'al' set to any, transform it into /page/alias_value and append the rest of the query string in default format", where "default format" is also customizable.

The rules will be editable in Admin and saved into one script file, so different URL-transform presets will be bundled as simple files (without any SQL bloat, etc.). The editor will automatically generate mod_rewrite files too, support for the following webservers will be provided: Apache, IIS, Nginx.

In the code, any URLs will be constructed by calling one simple function sed_url() which takes 3 parameters: site area (script name, e.g. 'page'), list of parameters (as associative array key => value, or in traditional query string format) and optionally page anchor.

Agree/disagree?

Lombi

чт, 18 сен 2008 00:07:32 -0000

also...

Trustmaster:
Looks easy so far, but it's not so easy when it comes to API design. First we could create a separate function for each site area, e.g. (the example is taken from one of existing solutions):

Actually looking at that code the three variables could be made global so there's 1 line instead of 4 per each function...

Lombi

чт, 18 сен 2008 00:06:38 -0000

Whatever works :)

Kilandor

ср, 17 сен 2008 14:46:58 -0000

Don't need multiple functions for this, Need only a single function that's configurable with patterns. Then User can fully customize the URL to their needs. The only thing I can think of other than that is, allow them to specify a callback function to run the url through before being output.

Antar

ср, 17 сен 2008 02:11:36 -0000

Lombi:
one normal, one with comments and one with ratings is absurd.

Yes, idiotic. I wish it'd gone already

Lombi

ср, 17 сен 2008 01:53:56 -0000

Actually i think that comments should be specifically turned OFF, not on. The way seditio now runs which means that you have three version of the page, one normal, one with comments and one with ratings is absurd.

I mean not just from a seo standpoint which results in three pages that are exactly the same, but also from an useability standpoint.

Trustmaster

ср, 17 сен 2008 01:38:03 -0000

This feature is proposed for the following benefits:
[list=1]

Humanize and SEO your URLs without modifying all the core and plugin files.

Customizable URL patterns selected or composed in Admin panel.

Well, if you want to see an example how it would work, here it is.
Call:

'SOME_TPL_URL' => sed_link('page', array('al' => 'some_title', 'comments' => 1))

Result with pattern1:

/pages/some_title.htm?comments=1

Result with pattern2:

http://page.mysite.com/some_title/comments-1.htm

I don't mean it will work this way, but just to give you an idea what we will discuss here.

So, the URL gateway consists of the following parts:
[list=1]

Customization tool in Admin, which lets you construct patterns like 'http://{$cat}.{$domain}/{$alias}.html', set options, etc.

Core API, providing functions for assembling URLs.

All the URLs in core and plugins use API instead of plain URLs.

Looks easy so far, but it's not so easy when it comes to API design. First we could create a separate function for each site area, e.g. (the example is taken from one of existing solutions):

It's quite easy at first but keep in mind that we need tens of such functions to cover all site areas, and this number is likely to grow with plugins, and these functions will be requested to be pluggable themselves later on.

Another approach is having 1 generic function, which takes a pattern (from config) and URL parameters (as its arguments) and assembles an URL by following some common rules. Most probably some people will request for custom logic for exact site areas, so we could make it pluggable/customizable somehow (but I'm afraid it affects performance).

Sorry, I'm not a good explainer this time, because I've caught a cold and it's hard to concentrate. But I hope it's enough for you to start posting your ideas.