ok. i understand what you're saying. heres what you can do. we continue to change the url by hash on the client but we also, when the page loads, put links that the search engine can follow.
On 12/28/06, Kevin Newman <[EMAIL PROTECTED]> wrote:
Perhaps the easiest way to think about this is stuff before the hash, is server side stuff, and after the hash is client side stuff. The client portion can be changed on the client without reloading the client app, but the stuff before the hash will cause the app to be reloaded if altered by javascript (mod_rewrite only affects the server side - it doesn't update the user's location info). More within: dorkie dork from dorktown wrote: > i see what you are saying in your words. when we go to a new state, > say foo.com/bar/ <http://foo.com/bar/> you want the url to change to > foo.com/bar/monkey <http://foo.com/bar/monkey> not foo.com/bar/#monkey > <http://foo.com/bar/#monkey> It's not that I want the url to change to that, it's that the search bots only (to my knowledge) use the stuff before the hash (#). So it's more of a necessity to have those standard urls in some kind of link structure for the bots to follow. In other words, if you want SEO compatibility in your client side app, you are required to maintain and integrate the two different URL types - one for the user, and one for the search bots (and that one is a server side app).
correct.
> correct? have a look at www.neave.tv <http://www.neave.tv>. as you > move the app the browser's location bar is updated. This site demonstrates what I've been saying - only the stuff after the hash changes (and it's using unFocus.History, which was written by yours truly :-D - *shameless*). > > are we changing topics again or are we moving to another piece of the > puzzle? > > ie, jd summarized the current topic issue as this: > > "I'd like Adobe to provide examples on how to expose user-entered text, > stored within my database and displayed and entered through a Flex SWF's > UI, so that any search engine could search for that user text and return > the address of the interface." > > and then we discussed some solutions to this. I guess this is a different discussion - we are discussing why this is so hard to do, and the specific road blocks, and then some possible solutions. I'd be happy to start another thread, but I don't watch the list as closely as I'd like, which is why I keep coming back to this old huge one. The more I think about this particular problem, the more I am starting to see which tools may be right for which jobs. If you have a lot of content in your site, then each piece of content should probably be contained in some kind of document container (like html). It's these documents that would be indexed by search engines. So maybe then the problem is that we need a standard way to get from the indexed document into the Rich app more fluidly, if not automatically? This whole problem is also difficult, because it is not solely a technical problem, nor is it entirely an architectural problem - there are also possible user experience considerations, as well as work flow issues.
Yeah. Lets keep on this thread. I agree. Part of me is trying to figure out work arounds (something better than a hack) to fix the problem and another part of me wants adobe to address it. I hear you about a standard way. I think, not knowing if Adobe is working on it or not, a way that works is made then we can base a standard off that. Judah
