Contents tagged with ASP.NET
-
Teaser - upcoming forum software / message board AtlasForums
Here's a quick screen grab from an upcoming forum project I'm working on: AtlasForums. As I progress with this, I'll post more and more details as I get closer to launch.
-
ViewState, CheckBox, ControlState...errr...
J. Michael Palermo writes about the CheckBox in ASP.NET maintaining its state regardless of the EnableViewState attribute to False in ASP.NET 2.0.
Hang on - isn't that the same in ASP.NET 1.0 and 1.1? Oh yes.
All web controls that implement the IPostBackDataHandler maintain their basic 'value-state' (for lack of a better description) using the HTTP POST form collection. Irrespective of setting the EnableViewState property for the web control to False.
Nothing has changed in ASP.NET 2.0 as far as that is concerned. The CheckBox control along with TextBox and other controls that implement the IPostBackDataHandler interface, still maintain their basic value-state using their respective HTTP POST values. ControlState has nothing to do with this.
ControlState is a way to allow more fine-grained control over individual portions or behavioural elements of a web control, which under the bonnet actually still uses the ViewState statebag. Fritz Onion's article outlines this nicely and in more detail. -
ASP.NET 1.1 server control for <link> - enabling relative URL paths using tilde "~"
Here's a simple - but useful Link webcontrol class that supports the "~" tilde syntax for relative paths for the href attribute of the <link> element.
[DefaultProperty("Text"),ToolboxData("<{0}:Link runat=server Href=\"\" Rel=\"Stylesheet\" Type=\"text/css\"></{0}:Link>")]
public class Link : System.Web.UI.WebControls.WebControl
{
private string _href;
public string Href
{
get { return _href; }
set { _href = value; }
}
protected override void Render(HtmlTextWriter output)
{
output.WriteBeginTag("link");
output.WriteAttribute("href",base.ResolveUrl(this.Href));
foreach (string key in this.Attributes.Keys)
{
output.WriteAttribute(key,this.Attributes[key]);
}
output.Write(HtmlTextWriter.TagRightChar);
output.WriteEndTag("link");
}
}
You can then simply drop it in the <head> section of your page (provided you've used the Register directive to register the assembly):
The reason I had to roll my own is that when you add runat="server" for the <link> element, it turns into a HtmlGenericControl instance on the server, which is obviously used for numerous HTML elements, and as such no specific path resolve mechanism is applied to any of its attributes, since the attributes are different per HTML element.
Hope it helps someone out. -
PayPal API: what a nightmare!!!
I've been trying to get up and running with the PayPal API, see www.paypal.com/developer.What a complete nuisance that is!
The test accounts you create (on the sandbox, http://www.sandbox.paypal.com) actually need to be verified, before you can request an API cerificate. I finally managed to complete 2 out of the 3 verification steps but setting up the bank funding just fails:
I can add a US bank account, and according to the documentation (PP_Sandbox_UserGuide , page 22), you will see the 'Continue' button after adding an account which will take you to the overview page. Well, there is no 'Continue' button, and no 'Confirm Bank Account' link in the Activate Account box either, which means I cannot complete that step, and can't request an API cert. to start using the API.
I have tried to add a UK bank account, using the sortcode prodived in the same user guide, but it always fails saying that it's an incorrect sort code and incorrect 8 digit account number.
Why the bloody heck is their documentation inconsistent with the behaviour of the sandbox? And why on earth do people have to jump through so many hoops to use their API?
Have you used the PayPal API? Any thoughts on this? -
Public available data - FREE screenscraping or pay for API
Been working on a semi-commercial pet project of mine, for which I need a data feed.
A decent enough subset of this data feed is publicly available from this content provider's main website. However, the full dataset (though I won't need all that) is available through an HTTP GET XML API... For a flat fee of over 500 dollars per year.
What would you do? 1) Roll it yourself in about 20 lines of .NET code (using HttpWebRequest & Regex's) and scrape it; 2) Pay for the API...?
Needless to say, I went for 1)...even for just the fun. -
Possible Bug : HttpPost and class name conflicts
A colleague and friend of mine run into some very odd web service behaviour on ASP.NET 1.1. Anyone who can shed some light on this, please leave a comment. I have pasted his exact text describing the problem below.
--
Included below is a minimal web-service implementation to recreate a problem
I've encountered in a web service that has methods returning classes with the
same local name (but in different namespaces).
If only the SoapHttp protocol is enabled in the web.config, everything works
as expected - with the different "Something" classes being serialized in to
different XML namespaces as defined by the ResponseNamespace property of the
SoapDocumentMethod attributes.
However - if HttpPost or HttpPostLocalhost are enabled (the latter being
enabled by default), and I browse to the asmx file in IE, I get this error :
Types NsProblem.B.Something and NsProblem.A.Something both use the XML type
name, Something, from namespace http://example/NsProblem/. Use XML attributes
to specify a unique XML name and/or namespace for the type.
If I un-comment both of the "XmlRoot" elements I get this error
The XML element named 'Something' from namespace 'http://example/NsProblem/'
references distinct types NsProblem.A.Something and NsProblem.B.Something.
Use XML attributes to specify another XML name or namespace for the element
or types.
Now for the really strange bit : leave one XmlRoot attribute commented, and
the other not, and it works!
When it is working, the example responses (on whatever.asmx?op=GetArrayA)
don't appear to tbe any difference!
(aside: I also tried setting the responses to be different using Xml
Serialization attributes, i.e. putting [return: XmlElement(... )] on the
methods, but like the SoapDocumentMethod attribute this only seemed to change
the response for the Soap method - making no difference to the HTTP POST
response)
Various workarounds are available
- disable (remove) "HttpPost" and "HttpPostLocalhost" in web.config
- Rename the classes (making the namespaces redundant)
but I would prefer to be able to keep the class names as they are, and keep
the HttpPostLocalhost enabled for testing / debugging purposes - and I
anticipate needing to support 3 or more classes with the same local-name
across different namespaces.
---- Minimal test case ----
<%@ WebService Language="c#" Class="NsProblem.XmlTestSvc" %>
using System;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
namespace NsProblem.A
{
// [XmlRoot(Namespace="AAAA")]
public class Something { }
}
namespace NsProblem.B
{
// [XmlRoot(Namespace="BBBB")]
public class Something { }
}
namespace NsProblem
{
[WebService(Description="Conflicting name problem example",
Namespace="http://example/NsProblem/")]
public class XmlTestSvc : System.Web.Services.WebService
{
[WebMethod]
[SoapDocumentMethod(ResponseNamespace="http://example/NsProblem/A")]
public NsProblem.A.Something[] GetArrayA() { return null; }
[WebMethod]
[SoapDocumentMethod(ResponseNamespace="http://example/NsProblem/B")]
public NsProblem.B.Something[] GetArrayB() { return null; }
}
}
-
Recruiter talk - ar5e and elbow
Came across an interesting job description for an ASP.NET developer which shows that most, if not all recruitment agencies don't have any clue what they are talking about:
"My Client has an urgent requirement for an .aspx savvy ASP.Net Developer to help out with a surge of work/projects. The successful Candidate will be able to demonstrate substantial development experience in ASP.Net & .aspx."
Hmm. So, looks like you could have ASP.NET developers who are not .aspx savvy eh? They might be just .ascx savvy. Or maybe only .asax savvy.
Anyone else out there who has come across some other hilarious job descriptions recently?
-
Tiny suggestion for IE7 - <Enter> in address bar should result in HTTP GET refresh
A little gripe I have with IE when doing ASP.NET development is that when you've tested a page (with some PostBack), fix or add something and recompile, you'd usually want to refresh your page without re-posting, so not performing the postback. When pressing Enter in the address bar, nothing happens. The expected behaviour would be for the browser to perform a HTTP GET request for the current URL in the address bar. Pressing F5 obviously performs a re-post. Maybe the Cancel button on that dialog asking to re-post should perform a HTTP GET?
And yes, I know this already exists in FireFox.
What do you think? Surely I'm not the only one who finds this a pain in the backside... -
Save Wimdows and my letter to Bill Gates
Looks like MS legal is on a mad crusade. If I don't just hand over my domain names Wimdows.net and Wimdows.com, legal action will follow.
Read all about it here: www.savewimdows.com
And find my open letter to Bill Gates here.
Why can't they just leave me alone!?! -
Xml Serialization and the XmlArray and XmlArrayItem control attributes
We all know -or should know- that when using XML Serialization either over SOAP or manually, we can control the serialized output with so called control attributes.