-
-
After spending the day ranting about the RTM version (well, in fact, the problems are with the future bits), it looks like there's still hope. According to Matt, there seems to be a problem with the build process. Lets wait for the correct bits. I hope that at that time I can say that it was all a misunderstanding.
-
-
Yeah, another bug, reported by a long time ago. it's still there...the original code tries to load (and to save) the profile properties through the appli function method. here's the original code:
this.load.apply(this, parameters);
Well, not sure on what's the point of writting that code. the only thing i can say is that writting this:
this.load(parameters);
works but the previous doesn't!
-
-
If you're using the client authentication services on an ASP.NET page that has a ScriptManager control, then there's nothing here for you. it's safe to move on :)
On the other hand, if you're using the client side files and you do need to integrate your page with the authentication of ASP.NET, then keep reading. In the CTP, the client side class initialized itself with the path to the service in the server side. As you know, the service is embedded in the System.Web.Extensions.dll and you can only access it if your request has a specific path. So, the problem is knowing the path to the service so that you can set your AutorizationService with the correct path.
In the current release, the authentication service only responds to the Authentication_JSON_AppService.axd name and the url must point to the top folder of your web app. For example, if you've got an html page at the top of your web folder, you only need to indicate that path. On the other hand, if you have a page inside a subfolder, you do need to make sure that you're forming the correct path. Here's an example of initializing the path property of the AuthenticationService object from a page placed inside a sub-folder of the top web folder (note the ../ used in the path):
Sys.Services.AuthenticationService.set_path( "../Authentication_JSON_AppService.axd" );
-
-
Yep, another problem with the future bits! If you try to use this class from xml-script, you'll get an error that says something like this:
Error: Sys.ArgumentTypeException: Use isDomElement with a null type for element properties
e.g., for descriptor use { name: 'foo, isDomElement: true, type: null }
Now, you can't get a more explicit error message than this one. So the real question is why the future bits have the following descriptor for DraggableListItem
Sys.Preview.UI.DraggableListItem.descriptor = {
properties: [ {name: 'data', type: Object},
{name: 'handle', type: Sys.UI.DomElement},
{name: 'dragVisualTemplate', type: Sys.Preview.UI.ITemplate} ]
}
Replacing the bold line with this makes everythign work again:
{name: 'handle', type: null, isDomElement: true},
Oh, and since you're at the previewdragdrop.js file, you should also make the following changes:
- the descriptor for the handle property of the floatingBehavior is wrong (you need to make the some changes as the one you've made to the DraggableListItem's handle property)
- the checkCanDrag method has a bug where it tests the undraggableTagNames variable. You should change the line undraggableTagNames.indexOf( tagName.toLowerCase() ) to Array.indexOf( undraggableTagNames, tagName.toLowerCase() )
I'm starting to get upset! Can anyone please tell me why you've decided to start breaking the future bits? I know that they aren't supported but if you're going to break it in purpose, then it would probably be better to just remove them! don't you runt tests? for the love of god...I've just sepnt a morning running some simple tests and fixing you code! this really shouldn't be happening, should it?
-
-
Again, another bug that has been propagated to the january future bits... the PropertyKey is being defined in the glitz file as Object.
Again: this property should be defined as string, not int. This is becoming a routine...I know I'm talking about the future bits, but this kind of errors is becoming unacceptable (specially if you think that most of them aer well known for months!)
-
-
This is one of the things that it's really difficult to understand. The ListView client control has been exposing this bug for several months now. I've put in the forums, I've sent emails to the team members during the CTPs/betas, but it seems like no one is able to solve it.
the problem: if you click over the 1st item of the listview after it has loaded, the line isn't selected! To get a selection on the 1st line, you must first select another line and only then you can select the first line. It looks like they did change the code in this version, but the bug is still there...
Well, i knew that my english wasn't good, but i never thought it was so bad that it couldn't be understood. at least now i know that...
-
-
In previous versions of the AJAX extensions platform, you could use this control to call remote services exposed by a handler or a data service. The only restriction is that the server component needs to return data in JSON format because that's the only format the control "understands".
So, if you had a web service and didn't want to build a data service, you just needed to set the serviceType property of the client control to Handler and use the correct url. I mention correct url because the handler used to process the request on the server was chosen after parsing the url of the request (for instance, in previous versions you could use something like webservicepath/js/methodname - the /js made it go through the rest handler).
Things have changed and now the Content-Type of the request is used to see if the current request should return json or soap. The problem with this is that my old code (which is based on the datasource control) stop working because the url path hack i was using was no longer valid. So,. how can i call a web service (not a data service!) from a datasource control? easy: you need to handle the invokingRequest event of the WebRequestManager object and set the Content-Type header to application/json.
Here's a small demo page that does just that:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Untitled Page</title>
</head>
<body>
<script type="text/javascript" src="../MicrosoftAjax.debug.js">
</script>
<script type="text/javascript" src="../Microsoft.Web.Resources.ScriptLibrary.PreviewScript.debug.js">
</script>
<script type="text/javascript">
Sys.Net.WebRequestManager.add_invokingRequest(
function( sender, e ){
var req = e.get_webRequest();
req.get_headers()["Content-Type"] = "application/json; charset=utf-8"
}
);
</script>
<script type="text/xml-script">
<page xmlns:script="http://schemas.microsoft.com/xml-script/2005">
<components>
<dataSource id="mySource" autoLoad="true"
serviceURL="WebService.asmx/ObtemAlunos" serviceType="Handler" />
</components>
</page>
</script>
<input type="button" value="Mostrar dados" onclick="handleInfo()" />
<script type="text/javascript">
function handleInfo() {
var source = $find("mySource");
if( source != null ) {
var tbl = source.get_data();
for( var i = 0; i < tbl.get_length(); i++ ) {
var row = tbl.getRow(i);
alert( row.getProperty("Nome") + " " + row.getProperty("Idade") );
}
}
}
</script>
</body>
</html>
-
-
Well, it seems like I have another rant: what have you done to the client files of the future bits placed in the installation folder? yep, they're there but they also contain duplicate classes and interfaces registrations. For example, Sys.Preview.IAction is registered in lines 363 and 2535.
hello...anyone home??
-
-
Another change, when compared with the RC version, is related with page methods usage. In previous versions, they were always "on", ie, adding a static method to the page and then annotating it with the WebMethod attribute is no longer enough for getting it to work.
Now you need to set the new EnablePageMethods property to true if you want to get the client side proxy generated. In my opinion, this is a good change, though I'm still not sure on why it's not documented on the migration doc (from RC to RTM)...
-
-
In previous releases, AJAX extensions extended the validation controls introduced by ASP.NET in order for them to work in the partial postback scenarios. In the final release, MS surprised everyone by announcing that they weren't needed anymore and saying that we should remove the tagMapping section from the config file. I run one or two tests which worked and assumed that they must had changed something in the internals. well, it didn't took long to start seeing several posts about validation problems with v1.0. I then found this post, by Matt Gibbs.
I'm not going to even try to understand this decision...it must be one of the worst calls I've ever seen! Saying that it was removed because the validators will be changed in the next version of ASP.NET and saying that keeping the validators in v1.0 of AJAX extensions would result in redundance must be a joke. Lets see: if you had put the controls in the final release, my apps would work just fine! When the new version of System.Web was released (with the new validators), I would only need to remove the tagMappings section from the web.config file. With the approach that was taken by MS, I now have to download a project, compile it and add the tagMappings section I've already had removed from web.config. Oh, and "tomorrow", when a new version of System.Web is out, I'll just have to delete the dll from my app and remove the tagMapping entries from the web.config file.
Pure genius, I say!