David Baird wrote:
I think the counterpart to parse_path() should be called make_path().
Well it doesn't make a path, it makes a URI :) In the sense of returning
a URI object, but also in the sense that the stringified form starts
with a scheme (http) then has an authority and a path and maybe a query.
So I thought it ought to have a name that emphasised that difference.
If anything, I'd suggest we ought to refactor the request parsing so
that the input method deserved to be called parse_uri, but there are way
more important things we ought to be concentrating on.
LinkTools has a make_path() (but it's poorly implemented ATM because
it doesn't use URI). make_path() should probably return a string,
rather than a URI object, because I've found a few CPAN modules out
there will choke on objects even if the object has a perfectly good
stringification behaviour. So I'd suggest adding a make_path to
Path-URI, with the same interface as make_uri (which it'll call
internally).
I wouldn't want to change the return type of make_uri, because returning
the object allows you to call other methods if you want:
[% request.make_action_uri.canonical %]
or
[% uri = request.make_action_uri ; dev_null = uri.opaque(1) ; uri %]
I guess you mean that make_path would have a string return type?
sub make_path { shift->make_uri(@_)->as_string }
We could do that. Filing bug reports on the broken CPAN modules would be
another approach :)
LinkTools::make_path takes named params, whereas Path::URI::make_uri
takes positional args. It would be nice if we could combine the two.
I'm open to suggestions for an interface. Remember that make_uri already
takes named arguments (the query args) and that there are peculiarities
of TT's handling of named args that complicate things. It also needs to
deal with the case of different numbers of path segments somehow
(without requiring the user to paste anything beyond the first two into
a string representation before calling the method). I wouldn't want to
complicate the normal case, such as:
[% request.make_uri( table, action, order = some_column ) %]
I think it's normally pretty clear from the variable names what each
argument represents.
I'd like to see this in core, because then we can document path making
and URL parsing in the same place, and emphasize the advantages of
using these methods for all path manipulation. Also, there's the
potential for make_path and parse_path to both use a shared path
template, so the whole path scheme could be changed at a single point.
Perhaps we can do that for 2.12. The templates would need changing, as
would the references scattered around the docs (the code of flox, for
example?). More than I want to take on right now.
Cheers, Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users
