On Thu, 2001-11-15 at 18:37, Sascha Matzke wrote: > > As far as the fix, you can't really do this entirely in the > > ServletFactory, because you don't know which kind of ServletFactory to > > call until you've parsed the URL to find what name matches to what > > resource (which may or may not be a file). Extensions in the URL, for > > all their ugliness, do make the framework's job easier :) > > Sure I could handle this in a ServletFactory alone. Imagine an > ActionServletFactory which is registered in the application for > a certain extension (e.g. *.do oder *.yaa oder whatever you like). > > Now if you call something like http://..../blah/something_to.do or > http://..../blash/blubbs/something_to.do the ActionServletFactory > would get the job, could provide an instance of a ActionServlet - which > would know how to map something_to to the matching action.
Right, but that leaves the extension in the URL, which is something Webware intentionally does not do. And, like I said, it makes the framework easier -- but I still think it's worth it not to use them. You're idea is also, in some ways, turning URL mapping around -- the very last part of the URL (the extension) is the root for the entire URL, because it is the first thing that is looked at when determining the relationship between the URL and a resource on the server. So the URL: http://.../blah/something_to.do is almost equivalent to: http://.../do/blah/something_to Which, to me, feels backwards -- it's like having a set of cgi-bin directories or something. Expedient, sure, but not at all flexible, and it creates unstable URLs. Tim Berners-Lee wrote a good document about URL design, which I can't find at the moment. It talks about why extensions aren't a good idea for the URL. If someone remembers this and has a link, I'd be curious to look at it again. It also had some ideas about making namespaces related to date of publishing (again to increase stability), an idea which I haven't been able to come to terms with (i.e., I don't like the idea, yet I don't know of a good alternative). Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
