One of the open source solutions I occasionaly use *cough* *cough* *drupal* *cough* has a mod redirect / mod rewrite htaccess file (i'm combining words). Any url that is entered into the site gets rewritten or redirected. It is a dynamic system that allows you to dynamically redirect to the content you want without hard coding paths or directories.
So you would create a dynamic page (doesn't really exist - only in the database) and then an alias to reach it. For example, www.test.com/myalias. Actually a lot of systems use this (wordpress, etc). All urls entered in to the site would be redirected to index.php. At this point you could with the super awesome power of server side code, deliver page links dynamically and content dynamically. I recently did a project with FXT and did exactly that. You pass the data as an xml model into a script tag under the body tag. Search engines pick this up. My Flex app pulled this xml in and then used it as a dataprovider for numerous controls. I've asked in the wish list for Macromedia at the time before it was Adobe to let us specify the type of extension for the published html wrapper. Right now if you click publish or run it creates a HTML page. So somewhere in the options it would be nice to choose the page extension type (php, asp, jsp, etc) of the page we are publishing. I've also investigated and requested a way to pick my template page that Flex finds and then replaces the tokens which it is looking for inside of it. This may all be possible already. I've been mostly only learning the API, mostly. Now that I've had a chance to think about it a default Adobe Page and Link Management admin site might be the solution. It would be created and deployed to bin or bin-admin with every project. Then you would upload that to the server along with the contents of your bin directory. A developer could login to it on the server. The Adobe Page Manager would use an xml file or database to create the aliases. The alias would be for different states in a Flex app. When you create an alias there would be a place where you could call the services or page associated with that state and alias. It would then wrap that content in a xml tag like in FXT for indexing. You could also pass any links back to the page. The content and links would be in the noscript / script / area of the page and not be visible to the user but it would be visible to the search bots. Because it uses a single page index.php and .htaccess mod rewrite it would redirect all traffic to the single index page (php, asp, java). That page would take that url alias, search the xml file or database and serve up the appropriate content (in the background hidden to users). I hope that makes sense. It would manage aliases, content for that alias, links for the alias and state to pass to the embedded flash swf. I can actually imagine how it would work. On 12/21/06, Kevin Newman <[EMAIL PROTECTED]> wrote:
I guess it isn't as large a problem as maybe I've been suggesting, after having talked about it in this thread. My whole problem is that I don't like urls that look like this: http//domain.com/some/path/#other/path - which in all the examples, is what you could end up with, if you try to combine a regular indexable set of html files (or a server side app or whatever), with an self updating deep link solution that uses the hash portion of the url (like all current flash based deep link systems do). At the end of the day the problem is largely cosmetic I suppose, but it's still a problem I'd like to find a solution for. :-) The optimal solution, imo, would be some way to have the pages get indexed by search engines, then kick you into the app, at the app level, rather than shoe horning the app in at the index level. Kevin N. hank williams wrote: > > > > Either way, it's reconciling the two urltypes that's the crux of the > problem as I see it. > > > Kevin, > > You keep saying this, and maybe I am missing the big picture here, but > I am not clear why it is necessary to "reconcile" these two url types, > or how they relate to each other at all. It seems to me you can use > them both, they exist for different purposes and there is no problem. > You seem to think that that is not right, and below categorize it as > "so large" a problem. What am I not understanding? > > Regards, > Hank > > > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links
