I think a CoolUrlTag would still be usefull, just so that we can have CoolUrl's used throughout the site, I used a shopping cart written in PHP that had these kind of Urls and there was a config option to use CoolUrls or regular Urls, it worked pretty well.



Jérôme BERNARD wrote:

Selon Francisco Hernandez <[EMAIL PROTECTED]>:


does the CoolUriDispatcher handle passing arrays like when using multiple checkboxes or multiple selected select tags?


Nope.
It splits the URL on '/' delimiters. It then decides whether the token is the
name of the action to execute, the parameter name or the parameter value.


also whats going to happen if you have a textfield that its value is "03/17/1990"


This will clearly fail! I am wondering though if the CoolURIServletDispatcher
should be used with such a kind of parameter values. For example if you would
like to display articles published on 03/17/1990, you should instead stick to
this kind of URL: http://myhost.com/1990/03/17 . Why? Simply because one would
expect http://myhost.com/1990/03 to display the articles from this months and so
on...


also I think a CoolUrlTag would make sense to have aswell to write out the Urls just like <ww:url> does now but in the new Cool format


As I said, I am not sure this is really needed. After all, Cool URIs are meant
to be at least URIs that would stay and not change when the site
organization/content/technology change. So why would you like to dynamically
build those URLs? I mean what would you expect the CoolUrlTag to do that you
can't do with the <ww:url> one?

Jérôme.


Jérôme BERNARD wrote:

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

Reply via email to