Hi Carlin,
Thanks for taking a crack at this -- I think doing such a rework would
definitely help us. Some comments inline...
Carlin Rogers wrote:
Hi All,
One area of the NetUI Page Flow code that I'd like to rework is
the URLRewriterService. It's been pointed out that one area for
improvement would be to use a mutable URI object rather than a
string to avoid some performance cost with the parsing and string
manipulation for URL rewriting.
The framework could also be extended to allow for chaining of
registered URLRewriters. I'm open to thoughts about chaining
and some specific requirements you'd like to add.
Given that some URL rewriters would want to be involved at specific
points in the chain, I think we should offer the ability to:
- add a URLRewriter to the end of the chain
- add a URLRewriter to the beginning of the chain
- iterate through the chain
- add a URLRewriter either before or after a specific one in the chain
Also the template URL rewriting could also be reworked some to
utilize the mutable URI as well. In fact, maybe we could work
the code towards using the mutable URI rather than a String to
build up the URLs used throughout.
I think this is true -- ultimately we'd be in the best shape if there
was *no* String parsing/processing in cases where we build URLs from
scratch, and only a single act of parsing when we're processing a
user-defined URI.
The work could be done in a phased approach starting with just
implementing the mutable URI and reworking the URLRewriter
and URLRewriterService. Then we could go on to further use
of the mutable URI.
I agree -- I'm most curious to see how this will work in the existing
URL rewriter layer.
Below are some initial high level thoughts for reimplementing the URL
rewriting support in beehive. I've listed some of the requirements
that I know of currently. I've provided some ideas about the methods
for the Mutable URI object to be implemented and how to handle the
parsing. Some of these methods may not need to be implemented and
there are definitely other possibilities for handling the
query and parameters.
Let me know if there's some reuse or extension from other mutable
URI implementations you think would be best.
Thanks,
Carlin
--------------------
Requirements...
- The URLRewriterService implementation should use a mutable URL
object as a parameter to the rewriteURL() method so that a registered
URLRewriter can access components of the URL without parsing. This
includes parameters of the query. I.E. This method should take a
URL object rather than a String object as a parameter.
- Do we also want the rewriteURL() method to return a mutable
URL object so that consumers can now access parameters of the
query without parsing? Is this what is required to allow a
form tag to write out the parameters as hidden inputs?
I think that the best thing to do would be to return the URL (URI)
object. It gives us the most flexibility, and yes, in the case where
we're taking query parameters from the URI and converting them to form
elements, we'll want an object rather than a string.
- The URLRewriter implementation should be able to add parameters
into a Map (or something) implying a need for a mutable URL/URI.
- Support URLRewriter chaining in the framework.
--------------------
Minor changes for URLRewriterService and URLRewriter classes...
Change the rewriteURL() method URL object rather than a String
object as a parameter. Do we also want it to return a URL object
rather than a String after rewriting?
I think so, and I also think that the interface could be cleaned up to
use enums rather than Strings for specifying the type of URL being
rewritten.
--------------------
Mutable Uri class...
The member data would comprise of these URI syntactic components,
<scheme>:<userinfo>@<host>:<port><path>?<queryString>#<fragment>,
where we would keep track of the query string as a HashMap of
name value pairs.
Some sort of ordered map, probably -- LinkedHashMap maybe. I think we
should keep the parameters in the same order they were provided.
One option for parsing an incoming URI String would be to use the
java.net.URI class rather than implement the parsing ourselves.
We would still need to parse the parameters from the query
string. Do we want to keep the parameters of the query string in
legal format using escaped octets or as decoded strings and
encode them at a later time? I guess we could just do the encoding
at the end.
I *think* it would be OK to do all the encoding at the end, so we
could simply provide an encode method on the MutableURI (notice my
capitalization preference :) ) and thus avoid the whole distinction
between 'raw' and encoded pieces of the URI. As to using
java.net.URI, seems like that would make sense unless the performance
is too terrible.
Constructors
MutableUri()
MutableUri(String uri)
MutableUri(String scheme, String userinfo, String host, int port,
String path, String queryString, String fragment)
MutableUri(java.net.URI uri) - need this?
MutableUri(java.net.URL url) - need this?
I think it's fine to provide both of the above.
Public Member Functions
String getScheme()
void setScheme(String scheme)
String getUserInfo()
void setUserInfo(String userInfo)
String getHost()
void setHost(String host)
String getPort()
void setPort(String port)
String getPath()
void setPath(String path)
String getQueryString()
void setParameter(String key, String value)
void setParameter(String key, String[] value)
String[] getParameterValues(String key)
String getParameter(String key) - need this?
void removeParameter(String key) - need this?
boolean containsParameter(String key) - need this?
Set getParameterNames() - need this?
- return a Set, List, Iterator, Enumeration, or String[]?
Since we're on 1.5, I'd be in favor of a Set<String>.
String getFragment()
void setFragment(String)
boolean isAbsolute() - or isRelative()
boolean equals()
MutableUri clone()
String encode()
- reserved chars are converted into their %hex version
String decode(String) - need this helper function?
String toString()
Other classes to note...
org.apache.xml.utils.URI in Xalan-J
http://xml.apache.org/xalan-j/apidocs/org/apache/xml/utils/URI.html
org.apache.xerces.utils.URI in xerces
http://xml.apache.org/xerces-j/apiDocs/org/apache/xerces/utils/URI.html
Does anyone know of any other URI implementations?
Again, thanks, this is a good start and would be a great thing for us
to do.
Rich
