Some Atlas feedback

re: Some Atlas feedback

Bertrand Le Roy — Mon, 20 Feb 2006 23:53:00 GMT

Maestro, we ARE providing better OO support for JavaScript (namespaces, interfaces, enumerations, etc.) and we ARE using JSON on the wire (there are JSON.serialize and deserialize methods client and server side) so I'm not sure what you're referring to.
Also, the bug you're talking about seems to be coming from most browsers only allowing for 2 simultaneous connections to the same domain but it could also be the batching code that we have in place that will become optional in future releases. But without more details, it's hard to tell.

re: Some Atlas feedback

Maestro — Mon, 20 Feb 2006 23:47:00 GMT

I would like to see better javscript library support for those of us who are willing to brave the big bad world of javascript. (perhaps even explore the use of prototypes for code organization??? the current javascript code looks aesthetically like shit, as I'm sure you know) Also I would like to see JSON added to Atlas (or something JSON-like) utilizing full .NET attribute support etc. Also there are some timing bugs in the XMLHTTP wrapper code that occasionally delay the execution of synchronous calls till after queued asynchronous calls instead of right away. Give us lightweight optional tools like JSON, not heavyhanded all-encompassing "solutions". Otherwise, looks good.

re: Some Atlas feedback

Bertrand Le Roy — Wed, 08 Feb 2006 18:28:00 GMT

Steve: Sure, I see your point here. Typically, an Atlas aware server-side control will generate xml-script instead of all the JavaScript that's needed today, like in your validator example, which should be much cleaner. But in essence, the solution is not that different: you have a js file that contains the definition of your client-side behaviors, html and something that glues the two together. In ASP.NET 2.0 you had ad-hoc JS functions in the js file, and javascript code to do the glue. In Atlas, you'll have classes in the js file and xml-script to glue. It will be much easier to generate the glue from the server-side than when you had to come up with hacky JS like I described in my last comment.
I'll try to write more posts on the client-side framework as it can be used by page developers.
For the menu control, you can already prevent the postback by using NavigateUrl with the javascript: protocol. It's not an ideal solution but it gets the job done and it's fairly simple. An Atlas Menu control would be best here, but we don't have that yet.
C# developers who want a richer web experience without the JS are a primary audience for us. Rest assured that will show in the final designs for Atlas.
(and I think we're back on topic now, thanks).

re: Some Atlas feedback

Steve — Wed, 08 Feb 2006 12:37:00 GMT

The issue was concentrated around this topic and did get off topic, my apologies.

The main question and details I was looking for was about this:

"Yes, Atlas is much more than just Ajax: it's a complete client-side framework and not just a communication infrastructure. "

My example was really about the integration between writing javascript and accessing the controls on a page. It's in this whole setup that I would like to learn more about how Atlas will help on this.

My example was sideswiped by conversations on 'clientid' when actually that is the point of my question: it's these type constructs when working in javascript that I hope Atlas addresses.

I'd like to see more talk and conversation about this client-side framework and less about the communication infrastructure. I think the closest I've seen is on Nikhil's talk on behaviors. It seems more oriented toward 'control developers' than page developers.

This is not a complex sample, but I was working with the ASP.NET Menu control yesterday and I noticed that when you select a menu item that the page does a postback. The page also has a submit button. I'd like to be able to have the menu not do a postback but still be able to pass me the selected value before submitting. Unlike last time with validators, don't get caught up in the details - because what I'm asking is - will Atlas be the approach to take for this type of senario? Or do I need to, ie, attach attributes to the menu items and store values in hidden fields?

I'd like for Altas to make it a rich experience in the UI without all the javascript - mostly because I'm more of a C# developer who is asked many times to provide a richer interface that requires javascript. With Atlas I see a solution.

Again, sorry to go off topic, but I think it's really on topic because it shows the 'work arounds' required to do something as simple as accessing a control id through a DOM.

re: Some Atlas feedback

Bertrand Le Roy — Tue, 07 Feb 2006 18:30:00 GMT

Steve: Server-side, when you want to use FindControl to find controls that are in any kind of naming container, don't call Page.FindControl, use the container's version of FindControl. So in your second scenario, you'd get the master page from the previous page and then find the control from there. Same thing for a panel or any container control.
For your validator control, the way most people do this is by creating their own validator class and adding it a property for the second control's id. At pre-render time, the new validator control will have to register a startup script that initializes a small javascript structure that the validator's js file can find from its own id and then lookup.
To be clearer, the validator generates something like ClientID + "_secondControlID = \"" + FindControl(SecondControlID).ClientID + "\";"
The validator script evals its own id + "_secondControlID", and the result is your second control's client id, which can then be obtained using getElementById.
The FindControl here may be replaced with something that looks up the naming container chain so that it works inside repeaters and other containers.

But here's something I'd like to ask you: this is completely off topic and is polluting the comments thread. Furthermore, I see that you've posted similar questions on Nikhil's blog on a post where it is equally off-topic. Next time, please contact me directly through the contact page of this blog or ask your question on the relevant forum on http://www.asp.net.

re: Some Atlas feedback

Steve — Tue, 07 Feb 2006 17:24:00 GMT

I have discovered the problem:

Master pages.

When I use regular pages, the clientid's work fine.

When I use master pages - ie. a cross page post it changes or rather creates it's own id.

TextBox txtName = PreviousPage.FindControl("txtName") as TextBox;
TextBox txtName2 = PreviousPage.FindControl("ctl00$ContentPlaceHolder1$txtName") as TextBox;

The top example fails, the second works with a master page.

re: Some Atlas feedback

Steve — Tue, 07 Feb 2006 16:57:00 GMT

Here is another issue - when you use anything in ContentPlaceHolder:

it doesn't use the id of, ie' TextBox1 - it uses ctl00$ContentPlaceHolder1$TextBox1 as the client id - which you would have to use this second name in the .js file and hope it doesn't change.

I'm encountering this with the previouspage cross post:

TextBox txtName = PreviousPage.FindControl("txtName") as TextBox;
TextBox txtName2 = PreviousPage.FindControl("ctl00$ContentPlaceHolder1$txtName") as TextBox;

The first one above doesn't work - I have to use the ASP.NET generated id instead.

re: Some Atlas feedback

Steve — Tue, 07 Feb 2006 01:28:00 GMT

Betrand, I'm sorry but you can't get the clientid in your javascript, it's dynamically created at runtime.

Maybe your misunderstanding my post, but everyone knows this issue where ASP.NET generates id's at runtime that are not the same as the id you set, especially when the control is 'inside' another structure.

As far as the validator, it only gives you the control itself, but if you want to check the value of a different control to against that control , you can't pass get a handle on it. The only reason again that I would want to do this is because you can't access the generated clientid.

I know the <%= control.clientid %> - but this does not work unless you put the javascript in the aspx page, which I don't - it's in a separate .js file.

Again, I don't want the client id on the server side, I want the id of the control in the javascript code.

ie. I have a radiobuttonlist and a textbox. Based on whether a valid is selected in the radiobuttonlist determines if the textbox is required. ie. selected value 3 in the radiobuttonlist requires text in textbox. Therefore, my validator needs to know both the radiobuttonlist clientid and the textbox clientid in the javascript. But, instead of id's of 'TextBox1' and 'RadioList1' it's something like 'ctr01_TextBox1' and 'ctr02_RadioList1". (This really poses an issue if you add a new control because it can change this dynamic id).

Surely you understand this?

re: Some Atlas feedback

Bertrand Le Roy — Mon, 06 Feb 2006 07:09:00 GMT

As I've said before, you can get the client Id server-side using ClientID, but you don't even need to do that. The client-side custom validation function has a signature that enables you to get a reference to the element and arguments: function(sender, args). The arguments have a Value property and an IsValid property. Please read that article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWebUIWebControlsCustomValidatorClassTopic.asp

re: Some Atlas feedback

Steve — Sun, 05 Feb 2006 04:24:00 GMT

ClientID?

Yes, in my .js file I try to get the id - but the ID is not the Id of the control as I put in the page.

ie.

I get some ctl01_<name of control>

This 'ctl01' is not my id and there is no way to know that id from my .js file.

I don't put script in my pages since I can't easily debug my scripts.

Also - I can't pass the id when I use a customvalidator - there is no place for parameters, all you can you do is specify the client side function.

How do I under how this new framework works for javascript? All I've seen is typical javascript with calls to web services with JSON.