Jonathan,
I just looked at the helper.
I see what your saying.
I had thought it uses the __str__ or __repr__ to output the URL.
I do think it would have been a useful thing to do so I am going to do
as you suggested before.
Thanks.
On 1/12/12 11:08 AM, Jonathan Lundell wrote:
On Jan 12, 2012, at 8:05 AM, David wrote:
I dont see how adding access functions would cause an entire re-write;
Seems like we would just need to add "get" functions to the class;
I think the way it works now is great; but it should also offer the ability to
check app, func, contoller, scheme, and so on.
Clearly the helper knows about all this stuff and that how it is able to
construct the final url string
There is no URL class; it's a bare function that returns a string.
On 1/12/12 10:59 AM, Jonathan Lundell wrote:
On Jan 12, 2012, at 7:11 AM, David wrote:
I think it would be a worthwhile feature to be able to get information from a
URL helper object.
For example,
If we create a tuple of URL objects, and we want to loop through them, we may
want to be able to extract things like vars and args that were set when the
object was created.
ie:
urls =
(URL('default','action',args=['arg1','arg2']),URL('default','action',args=['arg1','arg2']))
now I want to do something like
for url in urls:
print url.function
This obviuosly does not work.
It's an interesting idea, but URL just returns a string, and aside from being a
fairly big rewrite, it's likely that it would break existing code that relies
on it being a string.
You could create your own object that takes the same arguments as URL and
stores them as attributes, and whose __str__ and __repr__ functions are the
actual call to URL().
