How to put into practice the 'code-behind' strategy 2

[c0deM0nK424]

does this mean i have more than one ' .aspx ' page ?

i have a repeater with an 'onItemCommand='UpdateTable' event, and its corresponding script sits at the top of the page enclosed in its respective <script></script> tags.

I think my webconfig holds the connection details, in terms of its path - cos straight after the script are the connection details for sqldatasource with a simple 'select everything from table' query too.

then comes a form, runat server and inside this form sits my repeater with its asp:buttons and commandnames, 3 buttons - one for inserting, updating and deleting. when these buttons are fired, the text entered into the search fields will be inserted/updated from the database, unless the delete button of a particular row is clicked in which case that row vanishes from the database and obviously doesn't appaer on the repeater.

the script itself is a series of nested 'if args.commandname = 'insert' , 'update' , 'delete' statments

and obviously inside each of these if statements sits the appropriate sql database query to insert, update or delete records from my chosen table.

And thats all there is to it.



NOW...i got stick for not following the 'code behind' style of p'ming, however, I read somewhere that on programs that are basic and built by 1 programmer, where database isnt comlpex but simple, code-behind is not necessary and inline code is fine. Is it the END of mankind as we know it if I simply stick to inline coding (like the way ive described how ive implemented a simple repeater to add,delete and update records in a table of a sql db) and use this practice for the rest of my pages I create ?

I wanted to then add paging facility to this default.aspx page...haha, as if the code on that page isn't MESSY enough( not messy just a lot to look at) and i began wondering if i ought to learn asap, 'code-behind' techniques.

Do i need to be a professional asp coder to utilise code-behind ? am i being foolish to add more scripts to this page to faciliate paging , surely this would mean tampering with my beautiful 'working code' ? lol

ive made like, 3 backups of this working code in Visual web studio - and wish to copy them onto my other machine which has MX Dreamweaver where i can perhaps, manipulate the size appearance of the repeater and not have it take up the ENTIRE screen.

btw, the table is populated with 150+ records, housing basic data (name, category) and tahts all. but its 150 records and im thinking 'paging would be nicer here'.

any tips, any advice - any you wish to offer - i am willing to listen and act upon it. Not all my site will use repeaters, the good old reliable DataGrid will come into the scene soon, which has built in editing/updating/sorting AND paging ! v.nice

if you're still reading this and you were polite and kind enough to give me this much of your time - i thank you deeply from the bottom of my heart.

i read something on 'class files/objects' , which make code-behind work. How the hell do i achieve that ?

please get back to me folks and tell me, in a nutshell, the best way to go abouts adopting a code-behind approach.

 

[jmeckley]

when using a "code behind" approach you get 3 files
form.aspx
form.aspx.cs (or vb depending on the language)
form.aspx.designer.cs (or vb... generated by VS, don't edit)

form.aspx has a page declaration which tells the compiler (or the webforms engine, can't remember which) what class is associated with the markup.

form.aspx.cs and forms.aspx.designer.cs define 1 object across 2 files. the designer file is what associates the markup to the class. form.aspx.cs is where you put the code you want to write.

this is the default action when you added a webform to the website project.

I would also caution you about the "joy" for gridviews. Inline editing can become clunkly. your "simple" gridview page become very complex very quickly with insert, edit, deletes. it also becomes very difficult to add business logic because you have to inject that into the page as well.

finally, stay away from datasource controls. they are the worst idea ever. 1. you cannot debug. 2. you cannot test. 3. you cannot add logic to them. at a minimum code up the ado.net objects in the code behind. Best case. use a data access framework to write your queries for you. I love NHibernate. there are others as well ActiveRecord, LLBL, MS Data Access Block.

if you are brand new to web development I would recommend you stay clear of webforms altogether and use an MVC framework like MS MVC or Castle Monorail. The issues with webforms is numerous, google "problems with webforms" or "MVC and webforms" for more information.

if you are not concerned about code design, automation and testability. Or cannot code with drag/drop wizards then webfroms is a great choice for application design. other wise webforms makes writing html more complicated than it needs to be.

Jason Meckley
Programmer
Specialty Bakers, Inc.