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