Itemid refactoring in 1.5
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
Hi all,
Thanks for the feedback. I have made the following changes to SVN :
^ Deprecated sefRelToAbs, use JRoute::_() instead
^ Removed Itemid in JRoute implementations, JRouter handles this automatically
^ Removed JURI::resolve, moved functionality into JRoute::_()
Instead of directly pushing the parse route information into the request as explained earlier, I know added a JRouter->setVar function to push it into the JRouter and let him handle the rest. This is a needed change in order to get the pagination working fully again. Be carefull with the code as it is unfinished and still a work in progress.
I also removed JURI::resolved and added a JRoute static class. The functionality that was in JURI::resolve has been moved into the JRoute::_($url, $ssl) function. The JRoute::_() function is also replacing the sefRelToAbs function. People who are writing components that have the legacy layer turned off make sure you use JRoute::_() instead of seRelToAbs.
And finaly I screened the whole codebase and removed $Itemid out of the component JRoute calls. This completely decouples the components from the $Itemid. I haven't been able to handle all issue, some of them require specific attention.
To answer some of the other questions raised :
@Kenmcd : Thanks, I'll keep that in mind and implement a rewritter in JRouter to easily change the format of the slugs. I have put this on my to do list.
@Doko : Best would be to test this with the none-legacy menu style. The legacy styles have not been tested yet. Your issue is probably caused by a small bug in these styles.
@Pollen : Could do that don't really see the advantage ? Could you try explaining why you would want this change ? The index.php part can be removed by enabling mod_rewrite.
@Alejo : It would work without a hitch. This is exactly what the system does, allow you to create links to a component and allow different settings for each of these links based on the menu parameters.
That's it for today, as always, shoot those questions my way
Johan
Thanks for the feedback. I have made the following changes to SVN :
^ Deprecated sefRelToAbs, use JRoute::_() instead
^ Removed Itemid in JRoute implementations, JRouter handles this automatically
^ Removed JURI::resolve, moved functionality into JRoute::_()
Instead of directly pushing the parse route information into the request as explained earlier, I know added a JRouter->setVar function to push it into the JRouter and let him handle the rest. This is a needed change in order to get the pagination working fully again. Be carefull with the code as it is unfinished and still a work in progress.
I also removed JURI::resolved and added a JRoute static class. The functionality that was in JURI::resolve has been moved into the JRoute::_($url, $ssl) function. The JRoute::_() function is also replacing the sefRelToAbs function. People who are writing components that have the legacy layer turned off make sure you use JRoute::_() instead of seRelToAbs.
And finaly I screened the whole codebase and removed $Itemid out of the component JRoute calls. This completely decouples the components from the $Itemid. I haven't been able to handle all issue, some of them require specific attention.
To answer some of the other questions raised :
@Kenmcd : Thanks, I'll keep that in mind and implement a rewritter in JRouter to easily change the format of the slugs. I have put this on my to do list.
@Doko : Best would be to test this with the none-legacy menu style. The legacy styles have not been tested yet. Your issue is probably caused by a small bug in these styles.
@Pollen : Could do that don't really see the advantage ? Could you try explaining why you would want this change ? The index.php part can be removed by enabling mod_rewrite.
@Alejo : It would work without a hitch. This is exactly what the system does, allow you to create links to a component and allow different settings for each of these links based on the menu parameters.
That's it for today, as always, shoot those questions my way
Johan
Last edited by Jinx on Fri Feb 16, 2007 12:54 am, edited 1 time in total.
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- vancanneyt
- Joomla! Ace
- Posts: 1098
- Joined: Fri Aug 19, 2005 9:30 pm
- Location: Buiten de wereld
- Contact:
Re: Itemid refactoring in 1.5
practicly:
sefreltoabs("index.php?task=view");
becomes:
JRoute::_("index.php?task=view");
sefreltoabs will go into the legacy mode i presume?
sefreltoabs("index.php?task=view");
becomes:
JRoute::_("index.php?task=view");
sefreltoabs will go into the legacy mode i presume?
Member of the Dutch (nl-NL) translation team - http://joomla.taalbestand.nl - http://joomlacode.org/gf/project/nederlands/
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
Correct.
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- ianmac
- Joomla! Virtuoso
- Posts: 4784
- Joined: Sat Sep 24, 2005 11:01 pm
- Location: Toronto, Canada
Re: Itemid refactoring in 1.5
If ItemID and option are both used internally (presumably in the session), then what happens when the link is referred to from outside the session? Can these be looked up?
Would I be correct in assuming that the first part (news-feeds, web-links and etc...) refer to the option parameter at least in some way?
Ian
Would I be correct in assuming that the first part (news-feeds, web-links and etc...) refer to the option parameter at least in some way?
Ian
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
The first part, what i call the application path is used to lookup the menu item in the menu database table. The information in this table is used to find out what the option is. Bascially you have two options :
1. You come in through a menu item link, which means the system will be able to find the option based on either the $Itemid in the URL (in case of a raw URL) or the application path (in case of a humanly readible URL).
Example
- http://localhost/joomla15/index.php/web-links
- http://localhost/joomla15/index.php?Itemid=x
2. You come in directly through the component, which means the option will need to be defined in the URL. At the moment we are only supporting raw URL's in this case. I might be able to get a standard rewriting algo in place that can also handle these URL's but that's not on the list at the moment.
- http://localhost/joomla15/index.php?option=weblinks
Note : in this case the system will not be able to load any specific menu item parameters because you are coming in directly throught component.
Does that make sense ?
1. You come in through a menu item link, which means the system will be able to find the option based on either the $Itemid in the URL (in case of a raw URL) or the application path (in case of a humanly readible URL).
Example
- http://localhost/joomla15/index.php/web-links
- http://localhost/joomla15/index.php?Itemid=x
2. You come in directly through the component, which means the option will need to be defined in the URL. At the moment we are only supporting raw URL's in this case. I might be able to get a standard rewriting algo in place that can also handle these URL's but that's not on the list at the moment.
- http://localhost/joomla15/index.php?option=weblinks
Note : in this case the system will not be able to load any specific menu item parameters because you are coming in directly throught component.
Does that make sense ?
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- ianmac
- Joomla! Virtuoso
- Posts: 4784
- Joined: Sat Sep 24, 2005 11:01 pm
- Location: Toronto, Canada
Re: Itemid refactoring in 1.5
So if I enter through a menu item link (into say, the web links component), and then browse through the component, to look at a particular weblink, then I might get to the URL:
http://localhost/joomla15/index.php/web ... omla-rocks
where joomla-dev is a weblink category and joomla-rocks is a link in that category.
This address does not depend on the session, right? I think that is what you are saying.
I guess the bottom line is, if somebody browses through my site (well hypothetically if I were to have a site that somebody would want to browse through), and find a web link or perhaps a photo in a gallery that they found entertaining/useful/for some masochistic reason wanted to link to, could they bookmark that page, perhaps send it to their buddy Jose who lives down the street and around the corner, so that he can open up the link?
I'm assuming yes, right? And further, I'm assuming that the first part of the URL points to a menu item (i.e. the web-links part), which in this case would point to a component, and the rest of the URL would tell the component which page to load. Correct?
Ian
http://localhost/joomla15/index.php/web ... omla-rocks
where joomla-dev is a weblink category and joomla-rocks is a link in that category.
This address does not depend on the session, right? I think that is what you are saying.
I guess the bottom line is, if somebody browses through my site (well hypothetically if I were to have a site that somebody would want to browse through), and find a web link or perhaps a photo in a gallery that they found entertaining/useful/for some masochistic reason wanted to link to, could they bookmark that page, perhaps send it to their buddy Jose who lives down the street and around the corner, so that he can open up the link?
I'm assuming yes, right? And further, I'm assuming that the first part of the URL points to a menu item (i.e. the web-links part), which in this case would point to a component, and the rest of the URL would tell the component which page to load. Correct?
Ian
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
None of this information is stored in the session, it's all create at runtime based on the request URL.ianmac wrote: So if I enter through a menu item link (into say, the web links component), and then browse through the component, to look at a particular weblink, then I might get to the URL:
http://localhost/joomla15/index.php/web ... omla-rocks
where joomla-dev is a weblink category and joomla-rocks is a link in that category.
This address does not depend on the session, right? I think that is what you are saying.
Offcourse, wouldn't be any point in destroying the whole magic behind hyperlinking would itI guess the bottom line is, if somebody browses through my site (well hypothetically if I were to have a site that somebody would want to browse through), and find a web link or perhaps a photo in a gallery that they found entertaining/useful/for some masochistic reason wanted to link to, could they bookmark that page, perhaps send it to their buddy Jose who lives down the street and around the corner, so that he can open up the link?
Again correct !I'm assuming yes, right? And further, I'm assuming that the first part of the URL points to a menu item (i.e. the web-links part), which in this case would point to a component, and the rest of the URL would tell the component which page to load. Correct?
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- absalom
- Joomla! Ace
- Posts: 1199
- Joined: Thu Aug 18, 2005 12:37 am
- Location: Melbourne, Australia
- Contact:
Re: Itemid refactoring in 1.5
Congratulations, Johan. Finally a SEF structure that is set like an API (see the Flickr URI structure and other REST-based URI APIs for this).. I'm impressed. Perhaps it's time to send across a slab of Boags express freight to Germany..Jinx wrote:None of this information is stored in the session, it's all create at runtime based on the request URL.ianmac wrote: So if I enter through a menu item link (into say, the web links component), and then browse through the component, to look at a particular weblink, then I might get to the URL:
http://localhost/joomla15/index.php/web ... omla-rocks
where joomla-dev is a weblink category and joomla-rocks is a link in that category.
This address does not depend on the session, right? I think that is what you are saying.
Have you considered making the Router function (or at least its output) API'able for as soon as you remove the numbers, index.php and colons, you're dealing with a pure hierarchical REST structure ?
Last edited by absalom on Fri Feb 16, 2007 9:27 am, edited 1 time in total.
Design with integrity : Web accessible solutions
http://www.absalom.biz
http://twitter.com/absalomedia
http://www.absalom.biz
http://twitter.com/absalomedia
- alledia
- Joomla! Ace
- Posts: 1070
- Joined: Tue Jul 18, 2006 3:55 pm
- Contact:
Re: Itemid refactoring in 1.5
This really is great news - one of the biggest improvements yet to emerge in 1.5
One thing I do want to throw out for consideration is that, from an SEO perspective, Google is thought not to search any deeper than three directories, so this would be crawled:
http://mysite.com/web-links/2:joomla-sp ... oomla
But this would not:
http://mysite.com/index.php/web-links/2 ... oomla
There is no official proof or confirmation from Google, but it is a generally accepted notion in the SEO world.
One thing I do want to throw out for consideration is that, from an SEO perspective, Google is thought not to search any deeper than three directories, so this would be crawled:
http://mysite.com/web-links/2:joomla-sp ... oomla
But this would not:
http://mysite.com/index.php/web-links/2 ... oomla
There is no official proof or confirmation from Google, but it is a generally accepted notion in the SEO world.
Joomla extensions and templates: http://Joomlashack.com
- keliix06
- Joomla! Ace
- Posts: 1022
- Joined: Wed Aug 17, 2005 11:46 pm
- Location: Minneapolis, MN
- Contact:
Re: Itemid refactoring in 1.5
Here's some pretty good proof that isn't correct:alledia wrote: This really is great news - one of the biggest improvements yet to emerge in 1.5
One thing I do want to throw out for consideration is that, from an SEO perspective, Google is thought not to search any deeper than three directories, so this would be crawled:
http://mysite.com/web-links/2:joomla-sp ... oomla
But this would not:
http://mysite.com/index.php/web-links/2 ... oomla
There is no official proof or confirmation from Google, but it is a generally accepted notion in the SEO world.
Query: http://www.google.com/search?q=site%3A+ ... =firefox-a
That is 4 directories deep, and it's not a supplemental result either. Best of all, the site runs on Mambo.Understanding Your Website Traffic
If you’re getting a respectable number of visitors to your site from online forums or blogs, ... And if they’re a content-focused site, who knows? ...
webhosting.devshed.com/c/a/Web-Hosting-Articles/Understanding-Your-Website-Traffic/ - 81k - Cached - Similar pages
Last edited by keliix06 on Fri Feb 16, 2007 9:06 pm, edited 1 time in total.
Doyle Lewis
BuyHTTP Internet Services
http://www.buyhttp.com/joomla_hosting.html - No Overselling Guarantee. Your Joomla site, faster.
http://www.joomlademo.com - 30 day free trial of Joomla
BuyHTTP Internet Services
http://www.buyhttp.com/joomla_hosting.html - No Overselling Guarantee. Your Joomla site, faster.
http://www.joomlademo.com - 30 day free trial of Joomla
- absalom
- Joomla! Ace
- Posts: 1199
- Joined: Thu Aug 18, 2005 12:37 am
- Location: Melbourne, Australia
- Contact:
Re: Itemid refactoring in 1.5
I'd second what Doyle says.
I help co-ordinate sites that have over 7 levels deep(800+ nav items inside the stack), and Google still can leverage content out of them.
The unacceptable bit may be the redundancy of index.php referencing and the colon issue in regards to RFCs.
I help co-ordinate sites that have over 7 levels deep(800+ nav items inside the stack), and Google still can leverage content out of them.
The unacceptable bit may be the redundancy of index.php referencing and the colon issue in regards to RFCs.
Design with integrity : Web accessible solutions
http://www.absalom.biz
http://twitter.com/absalomedia
http://www.absalom.biz
http://twitter.com/absalomedia
- louis.landry
- Joomla! Ace
- Posts: 1380
- Joined: Wed Aug 17, 2005 11:03 pm
- Location: San Jose, California
- Contact:
Re: Itemid refactoring in 1.5
One of the driving principles behind having a framework driven CMS application is so that the framework IS exposed as an API. Nearly everything in the framework is flexible and extensible. The application router object (JRouter) can be decorated and/or replaced by any object implementing the same interface... the same is true of many of our most important and fundamental classes.absalom wrote:
Congratulations, Johan. Finally a SEF structure that is set like an API (see the Flickr URI structure and other REST-based URI APIs for this).. I'm impressed. Perhaps it's time to send across a slab of Boags express freight to Germany..
Have you considered making the Router function (or at least its output) API'able for as soon as you remove the numbers, index.php and colons, you're dealing with a pure hierarchical REST structure ?
index.php is added in the event of not having the ability to use mod_rewrite or an equivalent. If mod_rewrite is enabled then you switch support on in the global configuration (right next to switching human readable urls on and off) and index.php goes away.
Louis
Joomla Platform Maintainer
A hacker does for love what others would not do for money.
A hacker does for love what others would not do for money.
- pollen8
- Joomla! Explorer
- Posts: 350
- Joined: Wed Aug 17, 2005 10:32 pm
- Location: la Rochelle - France
- Contact:
Re: Itemid refactoring in 1.5
seems like sefreltoabs is not yet in the legacy code, is the an oversight or just one of those things that need to be done?
aka
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
It should be in there, Louis has moved the legacy code into a system plugin.
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- pollen8
- Joomla! Explorer
- Posts: 350
- Joined: Wed Aug 17, 2005 10:32 pm
- Location: la Rochelle - France
- Contact:
- louis.landry
- Joomla! Ace
- Posts: 1380
- Joined: Wed Aug 17, 2005 11:03 pm
- Location: San Jose, California
- Contact:
Re: Itemid refactoring in 1.5
yeah yeah .... blame me :P
Joomla Platform Maintainer
A hacker does for love what others would not do for money.
A hacker does for love what others would not do for money.
- newart
- Joomla! Virtuoso
- Posts: 3177
- Joined: Fri Sep 02, 2005 10:06 am
- Location: Solar system - Earth - European Union
Re: Itemid refactoring in 1.5
Sorry Johan for posting here but my question I presume is useful for you work. The new written URL has inside small sentences like "joomla official news"... well if I use a foreign language as italian or french with accents and so on... do you think all is right? In your opinion as an expert aren't any language limit?Jinx wrote: 1. http://localhost/joomla15/index.php/web ... oomla (link to weblink)
2. http://localhost/joomla15/index.php/the ... w/faq (submenu item)
3. http://localhost/joomla15/index.php/new ... -news (link to newsfeed)
former Q&T WorkGroup Joomla member - Italian Translation Team Member
- tsimpo
- Joomla! Guru
- Posts: 527
- Joined: Thu Sep 15, 2005 5:09 am
- Location: Greece
- Contact:
Re: Itemid refactoring in 1.5
newart
I think its ok.
I am not expert but i checked urls of wikipedia and they use it and works perfect.
eg
http://uk.wikipedia.org/wiki/Головна_стаття
http://hi.wikipedia.org/wiki/मुखपृष्ठ
http://zh.wikipedia.org/wiki/首页
I think its ok.
I am not expert but i checked urls of wikipedia and they use it and works perfect.
eg
http://uk.wikipedia.org/wiki/Головна_стаття
http://hi.wikipedia.org/wiki/मुखपृष्ठ
http://zh.wikipedia.org/wiki/首页
Joomla sites. http://www.webcase.gr Υπηρεσίες Internet, websites, Joomla! dedicated services.
- newart
- Joomla! Virtuoso
- Posts: 3177
- Joined: Fri Sep 02, 2005 10:06 am
- Location: Solar system - Earth - European Union
Re: Itemid refactoring in 1.5
thank a lot for your idea, I've tried on wikipedia with a link for "Stabilità sistema" that in english stands for "Stability system", here is the link:
in this case there are an accented "a" and even "(" and ")"
http://it.wikipedia.org/wiki/Stabilit%C ... sistema%29
if the link was only Stabilità (in english stability)
for italian the link should be http://it.wikipedia.org/wiki/Visibilit%C3%A0
for english: http://it.wikipedia.org/wiki/Visibility
as you see there is a non-human readable link - a language gap among latin languages, italian, french, portuguese, romanian, spanish.
Moreover we have eg. in italian language, the year --> in italian : L'anno - we have this problem,too. Observe between the L and a, what we have...
in this case there are an accented "a" and even "(" and ")"
http://it.wikipedia.org/wiki/Stabilit%C ... sistema%29
if the link was only Stabilità (in english stability)
for italian the link should be http://it.wikipedia.org/wiki/Visibilit%C3%A0
for english: http://it.wikipedia.org/wiki/Visibility
as you see there is a non-human readable link - a language gap among latin languages, italian, french, portuguese, romanian, spanish.
Moreover we have eg. in italian language, the year --> in italian : L'anno - we have this problem,too. Observe between the L and a, what we have...
former Q&T WorkGroup Joomla member - Italian Translation Team Member
- infograf768
- Joomla! Master
- Posts: 19133
- Joined: Fri Aug 12, 2005 3:47 pm
- Location: **Translation Matters**
Re: Itemid refactoring in 1.5
You can type it this way but it looks like the real url istsimpo wrote:
http://uk.wikipedia.org/wiki/Головна_стаття
http://uk.wikipedia.org/wiki/%D0%93%D0% ... 1%82%D1%8F
once displayed.
Jean-Marie Simonet / infograf
---------------------------------
ex-Joomla Translation Coordination Team • ex-Joomla! Production Working Group
---------------------------------
ex-Joomla Translation Coordination Team • ex-Joomla! Production Working Group
- newart
- Joomla! Virtuoso
- Posts: 3177
- Joined: Fri Sep 02, 2005 10:06 am
- Location: Solar system - Earth - European Union
Re: Itemid refactoring in 1.5
well, a bit confusing... IMHO we can use an URL from this method
http://localhost/joomla15/index.php/new ... -news (link to newsfeed)
to this
3. http://localhost/joomla15/index.php/news-feeds/4/1 (link to newsfeed)
or better:
3. http://localhost/joomla15/index.php/7/4/1
can we use a universal language such as numbers? If you like to see sentences, words, a plu-in could do it. But now you see a short smart link, maybe faster to render than a long URL. I know it isn't readable, but it isn't easily forgottenable. We live now among numbers and in this case they are short and more flexible.
pls think of a change of names, titles, the URL is changed, too. For you and for the search engines!
http://localhost/joomla15/index.php/new ... -news (link to newsfeed)
to this
3. http://localhost/joomla15/index.php/news-feeds/4/1 (link to newsfeed)
or better:
3. http://localhost/joomla15/index.php/7/4/1
can we use a universal language such as numbers? If you like to see sentences, words, a plu-in could do it. But now you see a short smart link, maybe faster to render than a long URL. I know it isn't readable, but it isn't easily forgottenable. We live now among numbers and in this case they are short and more flexible.
pls think of a change of names, titles, the URL is changed, too. For you and for the search engines!
former Q&T WorkGroup Joomla member - Italian Translation Team Member
-
- Joomla! Champion
- Posts: 7018
- Joined: Wed Nov 22, 2006 3:35 pm
- Location: Nebraska
- Contact:
Re: Itemid refactoring in 1.5
Newart -
This will be one of the few times I disagree with you since I think you are very, very bright. But, WORDS not NUMBERS, please!
Thanks! ... Amy
This will be one of the few times I disagree with you since I think you are very, very bright. But, WORDS not NUMBERS, please!
Thanks! ... Amy
- infograf768
- Joomla! Master
- Posts: 19133
- Joined: Fri Aug 12, 2005 3:47 pm
- Location: **Translation Matters**
Re: Itemid refactoring in 1.5
@Newart
I guess search engines may understand the lingo.
These Russian or Chinese sites have to be ok for them.
Would'nt the problem show more when using these urls in contents or mails, etc.
We may get extraordinary long urls that would break formatting, not speaking of the easy possibility of losing some parts in the process.
Maybe one could have the choice to use Ascii for links?
I guess search engines may understand the lingo.
These Russian or Chinese sites have to be ok for them.
Would'nt the problem show more when using these urls in contents or mails, etc.
We may get extraordinary long urls that would break formatting, not speaking of the easy possibility of losing some parts in the process.
Maybe one could have the choice to use Ascii for links?
Jean-Marie Simonet / infograf
---------------------------------
ex-Joomla Translation Coordination Team • ex-Joomla! Production Working Group
---------------------------------
ex-Joomla Translation Coordination Team • ex-Joomla! Production Working Group
- newart
- Joomla! Virtuoso
- Posts: 3177
- Joined: Fri Sep 02, 2005 10:06 am
- Location: Solar system - Earth - European Union
Re: Itemid refactoring in 1.5
@AmyStephen
Thanx for what said about me. About your need for a word syntax, I understand you very well. I like to see a readable URL, me too. But the problem is a bit hidden...
For a simple comparison is like a DNS vs a domain name, numbers vs words. But the right problem is that they aren't on the same level.
The first level is logic (numbers), then human (words). So if you have an even more short URL like http://www.mysite/7/4/1 (index.php maybe you'd like to hide) I think it's easy for everyone to read. No possibility of errors, only to forget them. No problem by page not found by search engines.
But your doubt is, can I remember these URLs? Not for everyone, I presume. Well, Who wants an even more smart URL in a readable human form, can use a plug-in for doing so.
I see this URL by numbers like a readable level.
Now, if we compare the risk about a URL:
* by numbers, any risk at all;
* by words, I can remember the wrong words, I can change that URL word (search engine issues).
My post is to be intended as follows, the possibility to use "by numbers" and "by words", too. As you like. Do you agree? (Moreover I think the "construction" of a URL written by numbers is faster than to write section, title, category, title and so on...)
@Infograf768
I agree with your doubts. I hope to see expert solutions having in mind URLs like this, in french:
http://www.mysite/7:notre_site_d'actual ... Haïti-État
we have to see our URL with user's own eyes. If the URL is always the same, no changes, no % all around, well... I like very much the solution. But if not, is like a "not a bug" --> but a mistake, like a bug. And the user isn't interested if is a bug or not. He sees only that it isn't working!
Thanx for what said about me. About your need for a word syntax, I understand you very well. I like to see a readable URL, me too. But the problem is a bit hidden...
For a simple comparison is like a DNS vs a domain name, numbers vs words. But the right problem is that they aren't on the same level.
The first level is logic (numbers), then human (words). So if you have an even more short URL like http://www.mysite/7/4/1 (index.php maybe you'd like to hide) I think it's easy for everyone to read. No possibility of errors, only to forget them. No problem by page not found by search engines.
But your doubt is, can I remember these URLs? Not for everyone, I presume. Well, Who wants an even more smart URL in a readable human form, can use a plug-in for doing so.
I see this URL by numbers like a readable level.
Now, if we compare the risk about a URL:
* by numbers, any risk at all;
* by words, I can remember the wrong words, I can change that URL word (search engine issues).
My post is to be intended as follows, the possibility to use "by numbers" and "by words", too. As you like. Do you agree? (Moreover I think the "construction" of a URL written by numbers is faster than to write section, title, category, title and so on...)
@Infograf768
I agree with your doubts. I hope to see expert solutions having in mind URLs like this, in french:
http://www.mysite/7:notre_site_d'actual ... Haïti-État
we have to see our URL with user's own eyes. If the URL is always the same, no changes, no % all around, well... I like very much the solution. But if not, is like a "not a bug" --> but a mistake, like a bug. And the user isn't interested if is a bug or not. He sees only that it isn't working!
Last edited by newart on Fri Feb 23, 2007 7:07 pm, edited 1 time in total.
former Q&T WorkGroup Joomla member - Italian Translation Team Member
- markuz
- Joomla! Enthusiast
- Posts: 225
- Joined: Tue Nov 08, 2005 6:43 pm
- Location: the Netherlands
- Contact:
Re: Itemid refactoring in 1.5
Hi Johan,
What I found out is that other URL parameters are not parsed. It looks as if the parse function in components/com_foo/router.php is not used. So '/whatever/comes/here' is ignored. Are you aware of this? Is this still work in progress?
And is it possible to let JRoute::_() optionally ignore the current Itemid, so you can force to link to /component/{component_name} ? This is very useful for linking (routing) to another view without an Itemid from view with an Itemid.
So long for now... Good luck!
Greetz, Mark
Looks intuitive the /component/{component_name}/whatever/comes/here...02-Mar-2007 Johan Janssens
^ Implemented simple routing mechanism in JRouter to handle none Itemid linked URL's
What I found out is that other URL parameters are not parsed. It looks as if the parse function in components/com_foo/router.php is not used. So '/whatever/comes/here' is ignored. Are you aware of this? Is this still work in progress?
And is it possible to let JRoute::_() optionally ignore the current Itemid, so you can force to link to /component/{component_name} ? This is very useful for linking (routing) to another view without an Itemid from view with an Itemid.
So long for now... Good luck!
Greetz, Mark
- Jinx
- Joomla! Champion
- Posts: 6508
- Joined: Fri Aug 12, 2005 12:47 am
- Contact:
Re: Itemid refactoring in 1.5
Hi all,
Good news, I think we are almost done with the Itemid refactoring. Based on the feedback in this thread I have made a few changes to the implementation :
@kenmc, Brenda : I have implemented a very basic segment encoder/decoder that is capable of rewriting the slug's. A default implementation is in place that uses a '_' to seperate the id from the name. In the future we could expose this into the configuration if the need exists to give the administrator more control over the formatting of the URL segments. This change also solved a bug in PHP 4.3.9 in the parse_url function and resolves the concerns reported by Brenda.
@newart : URL's can only use ASCII characters and thus need to encode any other characters into an ASCII format. You correctly point out that this makes the URL's less readable. Instead of converting the non-ASCII characters to their respective entity formats I have implemented a function that downgrades a character to it's ASCII equivalent. For example, é will become e, or µ will be come u. This is not a 100% perfect but it is better then using entities. The segment encoder/decoder could be used to remove the text information from a segment and only keep the integer, for the moment this behavior is not yet implement. If somebody want's to have a go at it be my guest
@markuz : Problem with not parsing of default URL's has been fixed. JRoute can ignore the Itemid if you explicitly specify an option and the option doesn't match the option that is attached to the Itemid. In this case JRoute takes the option out of the URL. A good example are the URL's in the login module. Not sure if this is what you need ?
@Amy : you can now blog about Itemid refactoring, I'm putting a blog post up myself on the dev blog.
Thanks for all the feedback, I'm very happy with how this has turned out. If you find any bugs let us know so we can fix them for beta 2 release.
Johan
Good news, I think we are almost done with the Itemid refactoring. Based on the feedback in this thread I have made a few changes to the implementation :
@kenmc, Brenda : I have implemented a very basic segment encoder/decoder that is capable of rewriting the slug's. A default implementation is in place that uses a '_' to seperate the id from the name. In the future we could expose this into the configuration if the need exists to give the administrator more control over the formatting of the URL segments. This change also solved a bug in PHP 4.3.9 in the parse_url function and resolves the concerns reported by Brenda.
@newart : URL's can only use ASCII characters and thus need to encode any other characters into an ASCII format. You correctly point out that this makes the URL's less readable. Instead of converting the non-ASCII characters to their respective entity formats I have implemented a function that downgrades a character to it's ASCII equivalent. For example, é will become e, or µ will be come u. This is not a 100% perfect but it is better then using entities. The segment encoder/decoder could be used to remove the text information from a segment and only keep the integer, for the moment this behavior is not yet implement. If somebody want's to have a go at it be my guest
@markuz : Problem with not parsing of default URL's has been fixed. JRoute can ignore the Itemid if you explicitly specify an option and the option doesn't match the option that is attached to the Itemid. In this case JRoute takes the option out of the URL. A good example are the URL's in the login module. Not sure if this is what you need ?
@Amy : you can now blog about Itemid refactoring, I'm putting a blog post up myself on the dev blog.
Thanks for all the feedback, I'm very happy with how this has turned out. If you find any bugs let us know so we can fix them for beta 2 release.
Johan
Johan Janssens - Joomla Co-Founder, Lead Developer of Joomla 1.5
http://www.joomlatools.com - Joomla extensions that just work
http://www.joomlatools.com - Joomla extensions that just work
- brian
- Joomla! Master
- Posts: 12787
- Joined: Fri Aug 12, 2005 7:19 am
- Location: Leeds, UK
- Contact:
Re: Itemid refactoring in 1.5
Looking forward to reading the b log on this. I'm still trying to get my head around it all (despite playing with SVN)
"Exploited yesterday... Hacked tomorrow"
Blog http://brian.teeman.net/
Joomla Hidden Secrets http://hiddenjoomlasecrets.com/
Blog http://brian.teeman.net/
Joomla Hidden Secrets http://hiddenjoomlasecrets.com/
- markuz
- Joomla! Enthusiast
- Posts: 225
- Joined: Tue Nov 08, 2005 6:43 pm
- Location: the Netherlands
- Contact:
Re: Itemid refactoring in 1.5
Hi Johan,
The other thing is partly answered...
Since menu items usually define not only an option but also a view, I think it is logical to also ignore the Itemid in case you explicitly define another view within the same option. My router.php functions don't parse/build in the view parameter, because it can be derived from JMenu (see router.php of com_weblinks, function WeblinksParseRoute and the $item->query['view'] ).
Maybe you already considered this, though.
Kind regards, Mark
Good the parsing is fixed... thanks! I'll check out the next nightly build again.Jinx wrote: @markuz : Problem with not parsing of default URL's has been fixed. JRoute can ignore the Itemid if you explicitly specify an option and the option doesn't match the option that is attached to the Itemid. In this case JRoute takes the option out of the URL. A good example are the URL's in the login module. Not sure if this is what you need ?
The other thing is partly answered...
Since menu items usually define not only an option but also a view, I think it is logical to also ignore the Itemid in case you explicitly define another view within the same option. My router.php functions don't parse/build in the view parameter, because it can be derived from JMenu (see router.php of com_weblinks, function WeblinksParseRoute and the $item->query['view'] ).
Maybe you already considered this, though.
Kind regards, Mark
Last edited by markuz on Thu Mar 29, 2007 8:46 am, edited 1 time in total.
- newart
- Joomla! Virtuoso
- Posts: 3177
- Joined: Fri Sep 02, 2005 10:06 am
- Location: Solar system - Earth - European Union
Re: Itemid refactoring in 1.5
I like very much your decision, I think it is an intelligent balanced wise one. I hope that somebody can help you for full implementing the work. Johan, as you know I'm not a telented programmer, I can discuss (understand) about the code but I have poor natural skills by myselfJinx wrote: ...
@newart : URL's can only use ASCII characters and thus need to encode any other characters into an ASCII format. You correctly point out that this makes the URL's less readable. Instead of converting the non-ASCII characters to their respective entity formats I have implemented a function that downgrades a character to it's ASCII equivalent. For example, é will become e, or µ will be come u. This is not a 100% perfect but it is better then using entities. The segment encoder/decoder could be used to remove the text information from a segment and only keep the integer, for the moment this behavior is not yet implement. If somebody want's to have a go at it be my guest
...
former Q&T WorkGroup Joomla member - Italian Translation Team Member
-
- Joomla! Champion
- Posts: 7018
- Joined: Wed Nov 22, 2006 3:35 pm
- Location: Nebraska
- Contact:
Re: Itemid refactoring in 1.5
Thanks, Johan. You rock!