[Mono-dev] (no subject)

Robert Jordan robertj at gmx.net
Thu Jul 27 09:04:47 EDT 2006


Andrew Skiba wrote:
> Hi Robert,
> 
> According to the code of the current ResolveUrl, it always returns an
> absolute path. However on dotnet, Page.ResolveUrl("aaa.jpg") returns
> "aaa.jpg".

Under .NET 1.1?

> So why we need ResolveClientUrl on 1.1, if ResolveUrl should
> return relative paths as well? I still don't understand, why .Net has 2
> different functions?

IIRC, ResolveClientUrl is always relative, while ResolveUrl is,
in all cases I've seen, absolute.

If I run this under MS.NET 1.1:

<%@ Page %>
<html>
<body>
<%= ResolveUrl ("test.gif") %> <br />
<%= ResolveUrl ("dir/test.gif") %> <br />
</body>
</html>


I get

/app/test.gif
/app/dir/test.gif


/app is the application prefix.

Robert


> 
> Andrew.
> 
>> -----Original Message-----
>> From: mono-devel-list-bounces at lists.ximian.com 
>> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf 
>> Of Robert Jordan
>> Sent: Thursday, July 27, 2006 13:48
>> To: mono-devel-list at lists.ximian.com
>> Subject: Re: [Mono-dev] (no subject)
>>
>> Hi Andrew,
>>
>> ResolveClientUrl is implemented here, together with a bugfix 
>> for ResolveUrl:
>>
>> http://bugzilla.ximian.com/show_bug.cgi?id=77539
>>
>> Robert
>>
>> Andrew Skiba wrote:
>>> Hi, Gonzalo. 
>>>
>>> Following our IRC conversation, I made some investigation. 
>> On 2.0 when 
>>> I tried to render <asp:table> with BackImageUrl="~/c:\aaa.jpg" I've 
>>> got the following exception stacktrace:
>>>
>>> [HttpException (0x80004005): '~/c:\aaa.jpg' is not a valid virtual 
>>> path.]
>>>    System.Web.Util.UrlPath.CheckValidVirtualPath(String path) +210
>>>    System.Web.Util.UrlPath.Combine(String appPath, String basepath, 
>>> String relative) +154
>>>    System.Web.UI.Control.ResolveClientUrl(String relativeUrl) +377
>>>  
>>>
>> System.Web.UI.WebControls.TableStyle.FillStyleAttributes(CssStyleColle
>>> ct ion attributes, IUrlResolutionService urlResolver) +51
>>>    
>>> System.Web.UI.WebControls.Style.AddAttributesToRender(HtmlTextWriter
>>> writer, WebControl owner) +204
>>>  
>>>
>> System.Web.UI.WebControls.TableStyle.AddAttributesToRender(HtmlTextWri
>>> te
>>> r writer, WebControl owner) +27
>>>  
>>>
>> System.Web.UI.WebControls.WebControl.AddAttributesToRender(HtmlTextWri
>>> te
>>> r writer) +378
>>>    
>>> System.Web.UI.WebControls.Table.AddAttributesToRender(HtmlTextWriter
>>> writer) +38
>>>    
>> System.Web.UI.WebControls.WebControl.RenderBeginTag(HtmlTextWriter
>>> writer) +17
>>>    System.Web.UI.WebControls.Table.RenderBeginTag(HtmlTextWriter 
>>> writer)
>>> +16
>>>    
>> System.Web.UI.WebControls.WebControl.Render(HtmlTextWriter writer)
>>> +17
>>>
>>> On dotnet 1.1 I could not cause such exception no matter what URL I 
>>> gave to BackImageUrl. Except that, I saw, that on dotnet
>>> ResolveUrl("aaa.jpg") returns "aaa.jpg". So our Control.ResolveUrl 
>>> should be fixed, because now it always returns an absolute path, 
>>> including the application name. After that fix, on 1.1 ResolveUrl 
>>> should be sufficient for TableStyle.AddAttributesToRender.
>>>
>>> On 2.0 I decided to make a minimal patch to fix my test, because I 
>>> don't want to make big changes right now.
>>>
>>> If I had more time, I would do some refactoring, to make our call 
>>> stack look similar to dotnet. There is lots of code 
>> duplication in our 
>>> code in Style.WriteStyleAttributes, Style.FillStyleAttributes, 
>>> TableStyle.FillStyleAttributes and TableStyle.AddAttributesToRender.
>>>
>>> Also, I decided not to try and find what ResolveClientUrl does. Its 
>>> difference from ResolveUrl is undocumented, and can change. 
>> So I see 
>>> no value in copying .Net behaviour, until clients will come 
>> with real 
>>> testcases. I implemented the bare minimum to make my test pass.
>>>
>>> I attach the minimal patch for your review.
>>>
>>> Thank you.
>>> Andrew.
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>




More information about the Mono-devel-list mailing list