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().
>
