Inline Matthew said the following on 12/09/2009 03:56 PM: > @Peter: thanks for the feedback, here are my answers to your comments: > > 1. I replaced "&" with "&" and get the following error which is > probably why I had "&" from when the app was first built. > ERROR > Exception occurred parsing base config file 'C:\Inetpub\wwwroot\project > \configs\mach-ii.xml' for module ''. > Type: Expression || Message: An error occured while Parsing an XML > document. || Detail: The entity name must immediately follow the '&' > in the entity reference. || Original Template: C:\Inetpub\wwwroot > \MachII_1-8-0_RC1\MachII\framework\AppFactory.cfc at line 133 > Well, you'll need to use an XML entity to use the "&" character in XML. I guess & works ok. > 2. I did have the urlParseSES property set to true. I don't want > "index.cfm" in my URLs because I want my URLs to appear as if it was a > flat website i.e. /folder/folder/page.htm. I guess you could argue > that /index.cfm/ is the 1st folder however I just don't like having it > there, plus I feel it degrades SEO because the spider would see > content as being an extra folder deep in the app so less relevant. > > 3. I don't have a urlBase property set. But I have run into the > problem you speak of with parameters being piled up on each other. Now > I always use absolute urls i.e. "/..." > Yep, you'll need "/" in there. UrlBase shouldn't ever be set to "" unless you want relative URLs. > As mentioned above I have found a fix so don't waste your time > investigating for my benefit however I'm happy to keep digging if you > think this is a bug or upgrade querk. > Probably not a buglet -- just a side effect of configuration and URL rewriting. We can't change how browsers handle URLs and not all combinations of URL delimiters will work.
Thanks for letting us know about the configuration issues. .Peter > Cheers > Matthew > > On Dec 10, 3:19 am, "Peter J. Farrell" <[email protected]> wrote: > >> Matthew, >> >> Thanks for the information. I have a few thoughts for you. >> >> * I wouldn't encode the & in urlDelimiters. Mach-II takes care of >> UrlEncoding all build URLs for you. Since the 2nd parameter has more >> than one character -- I'm pretty sure this could be problem decoding any >> SES urls. I bet if you set the property to "/|&|=" things would clear up. >> >> * Did you have urlParseSES property set to true/false? If you are >> willing to have index.cfm in the URL, Mach-II will do the path_info >> parsing for you when urlParseSES is set to true. There is no need to >> use ISAPIRewrite in that case. >> >> * What was the value of the urlBase property? If you have a relative >> path (one that doesn't start with "/"), SES URLs will become all mucked >> up. It's not a Mach-II problem, but how browsers pass information to >> the webserver. You'll end up with URLs like >> index.cfm/event/home/index.cfm/event/aboutUs/ etc. where the browser >> starts pilling up parameters on the old URLs. >> >> Let me know how things work out. >> >> Best, >> .Peter >> >> Matthew said the following on 12/09/2009 01:40 AM: >> >> >>> Hi guys >>> >>> SHORT VERSION: >>> I don't think 1.8 RC1 supports the following property which may be a >>> bug or a bad way to construct urls (but accommodated by 1.6); >>> <property name="urlDelimiters" value="/|&|=" /> >>> This translates to something like "/index.cfm/event=..." >>> >>> LONG VERSION: >>> >>> I'm experimenting with upgrading from 1.6 to 1.8 RC1. I ran into a >>> problem where after many hours of investigation I found that my app >>> (in 1.8) was returning the default event instead of the event which it >>> should have been. After much digging around in the MachII code base >>> (and not realising that I could have saved a lot of time if I knew >>> about logging) I found that perhaps the way I was ReWriting urls was >>> guilty. However it did work in version 1.6 so I thought I'd throw it >>> out in case it is a bug. >>> >>> Before I get to showing my URLs I just wanted to point you to the line >>> of code in 1.8 RC1 which after many hours of digging is where I found >>> to be the issue causing the default event to be returned because my >>> event in the CGI.PATH_INFO was being ignored (it appears if I'd have >>> enabled logging I'd have found it much sooner - I've learned for next >>> time). The line of code is /framework/RequestManager.cfc line 412-414. >>> I've given up trying to interpret this error on line 413 "Could not >>> find a configured url route with the url alias of '#names[1]#'. Routes >>> can only be announced from the browser url using url alias. Route >>> names are only used when referencing routes from within the framework >>> such as BuildRouteUrl(). Cleaned path_info='#arguments.pathInfo#'". >>> >>> Now to my urls. As mentioned above I setup MachII to accept urls as: >>> <property name="urlDelimiters" value="/|&|=" /> >>> This was to accommodate my urls which were Isapi ReWritten as" / >>> index.cfm/event=...". Note the ".cfm/" instead of ".cfm?" >>> >>> To solve the problem I have removed the <property name="urlDelimiters" >>> value="/|&|=" /> and reverted back to good old correct urls i.e. "/ >>> index.cfm?event...". After doing some reading I believe that urls >>> written the way I was doing them is invalid anyway which is why I am >>> not flagging this as a bug. >>> >>> Right: enough time wasted, back to what I was doing. >>> >>> By the way: thanks MachII team for a great framework! >>> >>> Cheers >>> Matthew >>> > > -- You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
