On 10/5/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
> 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.
Sorry, yes, I meant an extra make_path method, not renaming make_uri.
<snip>
> I guess you mean that make_path would have a string return type?
>
> sub make_path { shift->make_uri(@_)->as_string }
Yes.
> > 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.
The complicated argument parsing would be for make_path, since it's
making a particular path in the context of Maypole. make_uri is more
generic.
>
> > 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.
Yes, and there's still work to do on an interface for make_path.
Peter's suggestion of plugins as a useful proving ground is sensible.
If you release Path::URI, I'll document it as a dependency of
LinkTools, and use it in make_path, and see if we can build a good
interface to it.
-------------------------------------------------------
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
