I don't mind where it goes. I can remove the CoolUriServletDispatcher if you want.
Should we setup a WebWork2-extensions project on java.net ? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Cannon-Brookes > Sent: Friday, 3 October 2003 11:51 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Advanced URL mapping? > > > Can I just say that all of this advanced "cool" URL mapping > shouldn't be in WebWork core? It's an extension or addition, > that should be shipped separately? > > (Or more likely just written up in a Wiki document for those > who want to use > it?) > > M > > On 3/10/03 12:22 AM, "Cameron Braid" ([EMAIL PROTECTED]) > penned the > words: > > > I have used cocoon before and they provide a cool url mapping > > techinque using matchers. > > > > I will have a think about how we can integrate something like that. > > > > For example, > > > > Syntax aside, I would like to be able to specify a match > pattern of : > > > > "/action/year/month/day" > > > > to parse /article/2003/10/02 > > and get a map {action=article,year=2003,month=10,day=02} > > > > Since we are trying to achive a permalink style URL, why are the > > parameter names required in the URL ? > > > > Also, for your original idea > > > > /article/id/10 would probably be better written as > /article/10 with a > > matcher /(action)/(id) > > > > This type of pattern will also allow for action namespaces > > > > "/namespace/action/id" > > > > Then /customer/sale/10 -> namespace=customer, action=sale, > id=10 Then > > /admin/vendor/sale/10 -> namespace=/admin/vendor, action=sale, id=10 > > > > Before we implement these ideas, what other types of URL's > do we want > > to try and map ? > > > > Cameron > > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > On Behalf > >> Of Jérôme BERNARD > >> Sent: Thursday, 2 October 2003 7:21 PM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [OS-webwork] Advanced URL mapping? > >> > >> > >> Hi Cameron, > >> > >> The more I think about the CoolURIServletDispatcher, the > more I think > >> it is too much limited. For example I changed the > abbreviation syntax > >> from: http://myhost.com/article/paramValue1 to > >> http://myhost.com/article/articleID/paramValue1 instead of > >> http://myhost.com/article/article/paramValue1 . > >> > >> Why? > >> > >> Simply because most of the time your action are written that way: > >> > >> public class LoadArticleAction extends ActionSupport { > >> long articleID; > >> Article article; > >> // getter & setter for the above members > >> // other methods omitted... > >> } > >> > >> If you use a parameter named "article" (by using the same > parameter > >> name as the one from the action) then you will need to use weird > >> method names in order to retreive the real object linked > to this id. > >> > >> Anyway, I think we should write a custom ServletDispatcher > that reads > >> advanced mapping configuration from another xml file (or perhaps > >> extends webwork.xml?). > >> > >> This file could allow to use the sheme explained above but > also deal > >> with URL including dates (like http://myhost.com/2003/10/02). > >> > >> What do you think about this? > >> > >> Jérôme. > >> > >> Selon Cameron Braid <[EMAIL PROTECTED]>: > >> > >>> I have madea patch to the servlet dispatcher to allow for > >>> extensability > >>> : > >>> > >>> the methods that can be overriden are > >>> > >>> protected void sendError(HttpServletRequest request, > >>> HttpServletResponse response, int code, Exception e) > protected Map > >>> getParameterMap(HttpServletRequest request) protected Map > >>> getSessionMap(HttpServletRequest request) protected Map > >>> getApplicationMap() protected String > >> getActionName(HttpServletRequest > >>> request) protected String getNameSpace(HttpServletRequest request) > >>> > >>> this will allow for the core logic in the service method to > >> be re-used > >>> from custom servlet based dispatchers, allowing a custom URL and > >>> parameter mapping scheme to be implemented. > >>> > >>> > >>> Pat / Jason / Others : do we want to include the > >>> CoolUriServletDispatcher in the core ? > >>> > >>> If so, I will modify it to extend the new ServletDispatcher. > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] > >>>> > [mailto:[EMAIL PROTECTED] On Behalf > >>>> Of Jerome BERNARD > >>>> Sent: Tuesday, 30 September 2003 4:06 AM > >>>> To: [EMAIL PROTECTED] > >>>> Subject: Re: [OS-webwork] Advanced URL mapping? > >>>> > >>>> > >>>> Hum... I should have a closer look at IDEA then :-) Jérôme. > >>>> > >>>> Cameron Braid wrote: > >>>> > >>>>> What IDE do you use ? > >>>>> > >>>>> Eclispe can automatically create delegator calls for you, > >>>> which makes > >>>>> tasks like that a piece of cake. > >>>>> > >>>>> Cam > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: [EMAIL PROTECTED] > >>>>>> [mailto:[EMAIL PROTECTED] On > >>>>>> Behalf Of Jerome BERNARD > >>>>>> Sent: Monday, 29 September 2003 7:26 PM > >>>>>> To: [EMAIL PROTECTED] > >>>>>> Subject: Re: [OS-webwork] Advanced URL mapping? > >>>>>> > >>>>>> > >>>>>> Cameron Braid wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Cool idea :) > >>>>>>> > >>>>>>> Though, for the implementaion, wouldn't you have been better > >>>>>>> > >>>>>>> > >>>>>> to use the > >>>>>> > >>>>>> > >>>>>>> wrapper pattern, rather than dynamic proxies :) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> Sure. I thought about it, but it's quite painful: you have to > >>>>>> override so many methods :-( > >>>>>> > >>>>>> I'll do it tomorrow and update the attachment in the > JIRA issue. > >>>>>> > >>>>>> Jérôme. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Cam > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: [EMAIL PROTECTED] > >>>>>>>> [mailto:[EMAIL PROTECTED] On > >>>>>>>> Behalf Of Jérôme BERNARD > >>>>>>>> Sent: Tuesday, 30 September 2003 1:30 AM > >>>>>>>> To: [EMAIL PROTECTED] > >>>>>>>> Subject: RE: [OS-webwork] Advanced URL mapping? > >>>>>>>> > >>>>>>>> > >>>>>>>> I have created a new issue in JIRA > >>>>>>>> > (http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-326 > >>>>>>>> ) and submitted a new servlet that extends > >> ServletDispatcher and > >>>>>>>> provides such a functionality. I also provided a way > >> to shorten > >>>>>>>> even more the URL by assuming that if the first > >> parameter name > >>>>>>>> is not specified then it is supposed to be the name of the > >>>>>>>> action. > >>>>>>>> > >>>>>>>> This allows to replace the following URL > >>>>>>>> http://myhost.com/article/article/123 > >>>>>>>> with this URL http://myhost.com/article/123. > >>>>>>>> > >>>>>>>> Any code review welcomed! :-p > >>>>>>>> > >>>>>>>> Jérôme. > >>>>>>>> > >>>>>>>> Robert Douglass <[EMAIL PROTECTED]>: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> I think this is the relevant code, from > >>>>>>>>> org.apache.turbine.util.parser.DefaultParameterParser. As I > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> understand > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> it, Turbine folks avoid URLs like foo/bar?id=1812 > in favor of > >>>>>>>>> foo/bar/id/1812. I've never used this, and I can't remember > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> right off > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> exactly how the servlet container knows which part is the > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> path info, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> but essentially, they assume that the path info follows > >>>> the pattern > >>>>>>>>> name_1/value_1/...name_n/value_n. The advantage is > >>>> supposed to be > >>>>>>>>> search-engine friendly URLs from completely dynamic > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> applications. This > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> gets touted by the Turbine community as a great feature > >>>> (and it may > >>>>>>>>> be). I'd love to have this available, but as you can see > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> below, it is > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> easy enough to implement that anyone can do it as soon > >>>> as they want > >>>>>>>>> it. I don't really need it at the moment, so I'll let > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> someone else do > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> it. > >>>>>>>>> > >>>>>>>>> -Robert > >>>>>>>>> > >>>>>>>>> // Also cache any pathinfo variables that are passed > >> around as > >>>>>>>>> // if they are query string data. > >>>>>>>>> try > >>>>>>>>> { > >>>>>>>>> StringTokenizer st = > >>>>>>>>> new > >>>>>>>>> > >>>>>>>>> > >>>>>> StringTokenizer(request.getPathInfo(), "/"); > >>>>>> > >>>>>> > >>>>>>>>> boolean isNameTok = true; > >>>>>>>>> String pathPart = null; > >>>>>>>>> while (st.hasMoreTokens()) > >>>>>>>>> { > >>>>>>>>> if (isNameTok) > >>>>>>>>> { > >>>>>>>>> tmp = > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> java.net.URLDecoder.decode(st.nextToken()); > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> isNameTok = false; > >>>>>>>>> } > >>>>>>>>> else > >>>>>>>>> { > >>>>>>>>> pathPart = > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> java.net.URLDecoder.decode(st.nextToken()); > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> if (tmp.length() > 0) > >>>>>>>>> { > >>>>>>>>> add(convert(tmp), pathPart); //R.D. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> this add > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> the params to their internal param implementation, > see below* > >>>>>>>>> } > >>>>>>>>> isNameTok = true; > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>> } > >>>>>>>>> catch (Exception e) > >>>>>>>>> { > >>>>>>>>> // If anything goes wrong above, don't > >> worry about it. > >>>>>>>>> // Chances are that the path info was wrong > >>>> anyways and > >>>>>>>>> // things that depend on it being right will > >>>> fail later > >>>>>>>>> // and should be caught later. > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> * from super-class BaseValueParser > >>>>>>>>> /** > >>>>>>>>> * Random access storage for parameter data. The keys > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> must always be > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> * Strings. The values will be arrays of Strings. > >>>>>>>>> */ > >>>>>>>>> private Map parameters = new HashMap(); > >>>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: [EMAIL PROTECTED] > >>>>>>>>> [mailto:[EMAIL PROTECTED] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Behalf Of > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Jerome BERNARD > >>>>>>>>> Sent: Sunday, September 28, 2003 9:51 PM > >>>>>>>>> To: [EMAIL PROTECTED] > >>>>>>>>> Subject: Re: [OS-webwork] Advanced URL mapping? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Could you give some insights about the way Turbine > >>>> handle URLs? Any > >>>>>>>>> pointers? > >>>>>>>>> > >>>>>>>>> Jérôme. > >>>>>>>>> > >>>>>>>>> > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------- > >>>> This sf.net email is sponsored by:ThinkGeek > >>>> Welcome to geek heaven. > >>>> http://thinkgeek.com/sf > >>>> _______________________________________________ > >>>> Opensymphony-webwork mailing list > >>>> [EMAIL PROTECTED] > >>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>>> > >>> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> This sf.net email is sponsored by:ThinkGeek > >>> Welcome to geek heaven. > >>> http://thinkgeek.com/sf > >>> _______________________________________________ > >>> Opensymphony-webwork mailing list > >>> [EMAIL PROTECTED] > >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >>> > >> > >> > >> > >> > >> ------------------------------------------------------- > >> This sf.net email is sponsored by:ThinkGeek > >> Welcome to geek heaven. > >> http://thinkgeek.com/sf > >> _______________________________________________ > >> Opensymphony-webwork mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > >> > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
