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

Reply via email to