Hello everyone --
Was lucky enough to be able to attend a conference this past week concerning .NET, and specifically, ASP.NET. Came away with quite a bit, and wanted to share.
I'd first like to start off by saying that ASP classic is dead. ;-) Forget it. This new stuff is so much better, it's just ridiculous to still code ASP classic.
Ok, so I tried to after each session, bang out a simplistic example of everything so that I could take it back to work and share with employees. I have included two projects as zip files that have these files in them. They are anything but exhaustive, but they do touch on many of the things that I found most interesting, including among other things, compiling and using a separate assembly (the new approach to COM) outside of your current project, the bare bones beginning to setting up a hierarchical namespace to organize these assemblies, basic examples on data access and databinding, global storage of connection info (and how to modify web.config and machine.config) and other values, user controls, and so on and so forth...
web project:
assembly(component) project:
The cmi.zip file includes two classes... the first converts string data into its ASCII equivalent for HTML storage (w/o the need to worry about special chars and such), which I find useful many times. The second just takes a string argument, and converts it to it's .NET constant equivalent for aligning text programatically in user controls. You'll see where it's used in the examples where I consume the user controls, which is under the graph subdir of the project.
They're both very simplistic.
And here are some random notes that I put into a .txt file during the week. Just things that I thought might be helpful to someone trying to get a handle on the technology, and how to use it effectively:
Most of the notes I put in here are specifically addressed in the test web project that I posted in the .zip file, so if you look at all the files, you'll find working examples of most of it.
One other thought that just hit me is the fact that the dataset has a .writeXML method that will serialize the data in a dataset into a well-formed xml document. It also has a reverse .readXML that expects a well formed document.
This can facilitate what used to be referred to as 'rds' (remote data services), or storing of data on a user's machine so that they can browse real data offline. The key here is to write the xml with an option (you can find all the overloaded methods in the .net documentation) with the 'diffgram' option. This will store metadata about the dataset, as well, and keep track of what's been updated and such, so that uploading the data back to the data store is pretty easy. I have some examples on how to do this, as well, and if anyone is interested, I can post them. The examples came from Dino Esposito (Cutting Edge column editor for MSDN mag), and they're pretty good, although you can also go to msdn online to find much of the same type of stuff from his column, complete with code.
On top of rds, you can really use this to store data on your server as well, which could be used effectively to make your site more scaleable, relying less on the data store behind the scenes, and instead using file I/O to present data to a user (file I/O has also been vastly improved in .NET -- especially for xml docs). A pseudo-caching strategy. Depending on the application, it could be very useful.
I hope you guys/gals find this information useful. Comments on how I might improve stuff here is not only welcomed, but requested...
paul
ps. You may have to modify the references section of the test project, as there's no telling where you might put these files... the reference in question will be to 'cmi'. Just remove it and re-add it to point to wherever you save the cmi project. You might also want to just axe any reference you see to 'webControls'. This was my first stab at writing a globally available web control, and to date, I have not gotten it working properly. Just kill it, and everything should compile ok.
Was lucky enough to be able to attend a conference this past week concerning .NET, and specifically, ASP.NET. Came away with quite a bit, and wanted to share.
I'd first like to start off by saying that ASP classic is dead. ;-) Forget it. This new stuff is so much better, it's just ridiculous to still code ASP classic.
Ok, so I tried to after each session, bang out a simplistic example of everything so that I could take it back to work and share with employees. I have included two projects as zip files that have these files in them. They are anything but exhaustive, but they do touch on many of the things that I found most interesting, including among other things, compiling and using a separate assembly (the new approach to COM) outside of your current project, the bare bones beginning to setting up a hierarchical namespace to organize these assemblies, basic examples on data access and databinding, global storage of connection info (and how to modify web.config and machine.config) and other values, user controls, and so on and so forth...
web project:
assembly(component) project:
The cmi.zip file includes two classes... the first converts string data into its ASCII equivalent for HTML storage (w/o the need to worry about special chars and such), which I find useful many times. The second just takes a string argument, and converts it to it's .NET constant equivalent for aligning text programatically in user controls. You'll see where it's used in the examples where I consume the user controls, which is under the graph subdir of the project.
They're both very simplistic.
And here are some random notes that I put into a .txt file during the week. Just things that I thought might be helpful to someone trying to get a handle on the technology, and how to use it effectively:
Most of the notes I put in here are specifically addressed in the test web project that I posted in the .zip file, so if you look at all the files, you'll find working examples of most of it.
One other thought that just hit me is the fact that the dataset has a .writeXML method that will serialize the data in a dataset into a well-formed xml document. It also has a reverse .readXML that expects a well formed document.
This can facilitate what used to be referred to as 'rds' (remote data services), or storing of data on a user's machine so that they can browse real data offline. The key here is to write the xml with an option (you can find all the overloaded methods in the .net documentation) with the 'diffgram' option. This will store metadata about the dataset, as well, and keep track of what's been updated and such, so that uploading the data back to the data store is pretty easy. I have some examples on how to do this, as well, and if anyone is interested, I can post them. The examples came from Dino Esposito (Cutting Edge column editor for MSDN mag), and they're pretty good, although you can also go to msdn online to find much of the same type of stuff from his column, complete with code.
On top of rds, you can really use this to store data on your server as well, which could be used effectively to make your site more scaleable, relying less on the data store behind the scenes, and instead using file I/O to present data to a user (file I/O has also been vastly improved in .NET -- especially for xml docs). A pseudo-caching strategy. Depending on the application, it could be very useful.
I hope you guys/gals find this information useful. Comments on how I might improve stuff here is not only welcomed, but requested...
paul
ps. You may have to modify the references section of the test project, as there's no telling where you might put these files... the reference in question will be to 'cmi'. Just remove it and re-add it to point to wherever you save the cmi project. You might also want to just axe any reference you see to 'webControls'. This was my first stab at writing a globally available web control, and to date, I have not gotten it working properly. Just kill it, and everything should compile ok.