Taking over project: drop

Showing posts with label drop. Show all posts

Thursday, March 22, 2012

Tags vs. code-behind

Hi guys..

I just wanted to know whether its better to use the asp tags (or drag
n drop) or write the actual code-behind for things like login, data
accesses etc. I guess its easier to use the tags but does it have any
disadvantages ?

Thanks !On Feb 27, 10:36 am, "Zeba" <coolz...@.gmail.comwrote:

Quote:

Originally Posted by

Hi guys..
>
I just wanted to know whether its better to use the asp tags (or drag
n drop) or write the actual code-behind for things like login, data
accesses etc. I guess its easier to use the tags but does it have any
disadvantages ?
>

Using code-behind you separate Business Logic and UI design

Using code-inline the script can be changed without re-deploying the
whole application.

http://www.eggheadcafe.com/articles/20030518.asp
Using code-inline the script can be changed without re-deploying the

Quote:

Originally Posted by

whole application.

Something that should be totally avoided in "true MVC" applications.
It's a bad practice.

Looking into the article, which reads "There are certain situations where a
purely inline - code implementation is justified"... I tend to disagree.

Also, the author does not give any concrete examply to substantiate the
statement.

In my view, inline code can be and must be totally avoided. The reason is
obvious - seggregation of the UI from the logic... the heart of MVC
pattern.

--
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujini-labs.com
-------------
"MasterGaurav (www.edujini-labs.com)" <gaurav.vaish.nospam@.nospam.gmail.com>
wrote in message news:esUtIHnWHHA.1180@.TK2MSFTNGP05.phx.gbl...

Quote:

Originally Posted by

Quote:

Originally Posted by

>Using code-inline the script can be changed without re-deploying the
>whole application.

>
Something that should be totally avoided in "true MVC" applications.
It's a bad practice.

I agree.

Quote:

Originally Posted by

In my view, inline code can be and must be totally avoided. The reason is
obvious - seggregation of the UI from the logic... the heart of MVC
pattern.

I would agree, apart from in one specific instance related to ASP.NET -
Global.asax, where there are sometimes justifications for in-line code...
Juan is a particular advocate of this, IIRC...
On Feb 27, 2:16 pm, "MasterGaurav \(www.edujini-labs.com\)"
<gaurav.vaish.nos...@.nospam.gmail.comwrote:

Quote:

Originally Posted by

It's a bad practice.

It depends on the need.
No disadvantage. MS is moving towards "code free" development.

You can expect to see a lot more of this in the future, so you may want to get into it now.

"Zeba" <coolzebs@.gmail.comwrote in message news:1172568997.043126.138660@.a75g2000cwd.googlegr oups.com...

Quote:

Originally Posted by

The base argument is really:

Rapid Code Development VS Good Code Development.

Unless I'm whipping up a demo that needs to be done by yesterday,
I would avoid tags 99.9% of the time.

Rapid <Good most of the time.

Good development means it is maintainable (among other things), and the
<tagsapproach is cumbersome in that regard.

"Zeba" <coolzebs@.gmail.comwrote in message
news:1172568997.043126.138660@.a75g2000cwd.googlegr oups.com...

Quote:

Originally Posted by

On Feb 27, 5:36 am, "Zeba" <coolz...@.gmail.comwrote:

Quote:

Originally Posted by

I agree with the other posters wholeheartedly. The UI should most
definitely be separated from the business logic. In my personal
experience, even for fast demos, there's no *compelling* reason to
embed the source code right in the Web page. That assumes, of course,
that you're using Visual Studio or a similar editor that's capable of
handling code-behind files. The plumbing is all handled for you, and
the development experience is virtually seamless.

However, that's my *personal* experience, and your mileage may vary.

Another consideration is whether or not you want people to see your
intellectual property. If the source code is embedded right in the
pages, it's a lot harder to protect your source code from casual
viewing. With code-behind, you can compile the business logic into one
or more DLLs and avoid deploying the .VB & .resx files altogether;
that, coupled with a decent obfuscator, helps to protect your
intellectual property.

Mike
On Feb 27, 5:36 am, "Zeba" <coolz...@.gmail.comwrote:

Quote:

Originally Posted by

I would *especially* use a code-behind for data access. You'd be
divulging details about how you connect to your data source. Big no
no.

Same goes for user authentication and authorization.

Call me paranoid. These days, a determined hacker WILL penetrate your
system if he chooses to do so, and if your code is sitting there with
the instructions for connecting to your database right in the Web
pages, you WILL live to regret it.

Be safe. Move the code into a codebehind file. Obfuscate the code
during the build. Then, prior to deployment, remove any and all source
code files (except the global.asax file). Be sure not to include any
sensitive instructions in the global.asax file. Security is
everything.

Mike

Tags vs. code-behind

Hi guys..
I just wanted to know whether its better to use the asp tags (or drag
n drop) or write the actual code-behind for things like login, data
accesses etc. I guess its easier to use the tags but does it have any
di

vantages ?
Thanks !On Feb 27, 10:36 am, "Zeba" <

z...@.gmail.com> wrote:
> Hi guys..
> I just wanted to know whether its better to use the asp tags (or drag
> n drop) or write the actual code-behind for things like login, data
> accesses etc. I guess its easier to use the tags but does it have any
> di

vantages ?
>
Using code-behind you separate Business Logic and UI design
Using code-inline the script can be changed without re-deploying the
whole application.
http://www.eggheadcafe.com/articles/20030518.asp
> Using code-inline the script can be changed without re-deploying the
> whole application.
Something that should be totally avoided in "true MVC" applications.
It's a bad practice.
Looking into the article, which reads "There are certain situations where a
purely inline - code implementation is justified"... I tend to disagree.
Also, the author does not give any concrete examply to substantiate the
statement.
In my view, inline code can be and must be totally avoided. The reason is
obvious - seggregation of the UI from the logic... the heart of MVC
pattern.
Happy Hacking,
Gaurav Vaish | www.mastergaurav.com
www.edujini-labs.com
http://eduzine.edujini-labs.com
---
"MasterGaurav (www.edujini-labs.com)" <gaurav.vaish.nospam@.nospam.gmail.com>
wrote in message news:esUtIHnWHHA.1180@.TK2MSFTNGP05.phx.gbl...

> Something that should be totally avoided in "true MVC" applications.
> It's a bad practice.
I agree.

> In my view, inline code can be and must be totally avoided. The reason is
> obvious - seggregation of the UI from the logic... the heart of MVC
> pattern.
I would agree, apart from in one specific instance related to ASP.NET -
Global.asax, where there are sometimes justifications for in-line code...
Juan is a particular advocate of this, IIRC...
On Feb 27, 2:16 pm, "MasterGaurav \(www.edujini-labs.com\)"
<gaurav.vaish.nos...@.nospam.gmail.com> wrote:

> It's a bad practice.
It depends on the need.
No di

vantage. MS is moving towards "code free" development.
You can expect to see a lot more of this in the future, so you may want to g
et into it now.
"Zeba" <

zebs@.gmail.com> wrote in message news:1172568997.043126.138660@.a75g2000cwd.goog
legroups.com...
> Hi guys..
> I just wanted to know whether its better to use the asp tags (or drag
> n drop) or write the actual code-behind for things like login, data
> accesses etc. I guess its easier to use the tags but does it have any
> di

vantages ?
> Thanks !
>
The base argument is really:
Rapid Code Development VS Good Code Development.
Unless I'm whipping up a demo that needs to be done by yesterday,
I would avoid tags 99.9% of the time.
Rapid <> Good most of the time.
Good development means it is maintainable (among other things), and the
<tags> approach is cumbersome in that regard.
"Zeba" <

zebs@.gmail.com> wrote in message
news:1172568997.043126.138660@.a75g2000cwd.googlegroups.com...
> Hi guys..
> I just wanted to know whether its better to use the asp tags (or drag
> n drop) or write the actual code-behind for things like login, data
> accesses etc. I guess its easier to use the tags but does it have any
> di

vantages ?
> Thanks !
>
On Feb 27, 5:36 am, "Zeba" <

vantages ?
> Thanks !
I agree with the other posters wholeheartedly. The UI should most
definitely be separated from the business logic. In my personal
experience, even for fast demos, there's no *compelling* reason to
embed the source code right in the Web page. That assumes, of course,
that you're using Visual Studio or a similar editor that's capable of
handling code-behind files. The plumbing is all handled for you, and
the development experience is virtually seamless.
However, that's my *personal* experience, and your mileage may vary.
Another consideration is whether or not you want people to see your
intellectual property. If the source code is embedded right in the
pages, it's a lot harder to protect your source code from casual
viewing. With code-behind, you can compile the business logic into one
or more DLLs and avoid deploying the .VB & .resx files altogether;
that, coupled with a decent obfuscator, helps to protect your
intellectual property.
Mike
On Feb 27, 5:36 am, "Zeba" <

vantages ?
> Thanks !
I would *especially* use a code-behind for data access. You'd be
divulging details about how you connect to your data source. Big no
no.
Same goes for user authentication and authorization.
Call me paranoid. These days, a determined hacker WILL penetrate your
system if he chooses to do so, and if your code is sitting there with
the instructions for connecting to your database right in the Web
pages, you WILL live to regret it.
Be safe. Move the code into a codebehind file. Obfuscate the code
during the build. Then, prior to deployment, remove any and all source
code files (except the global.asax file). Be sure not to include any
sensitive instructions in the global.asax file. Security is
everything.
Mike

Taking a value from one window to another

I want to be able to allow a user to select a word from a list of words, but instead of using a drop down list, I want the user to click a button - which opens a new window containing the list of words, double click on the word (or words) selected, and the value of the word that was double clicked is automatically transferred to a text box in the previous (calling) window. Is this possible in ASP.NET?Passing data back to a parent window is entirely possible via lowly javascript - with or without ASP.NET server technology, but the user interaction method you have decided upon would be a little more unstable across browsers.
window.opener.document.getElementById('textbox1').value = "something";

taking text from a drop down list and want to insert into a database


<%@dotnet.itags.org. Page Language="VB" Debug="true" %>
<%@dotnet.itags.org. import Namespace="System.Data" %>
<%@dotnet.itags.org. import Namespace="System.Data.OleDb" %>
<script runat="server"
 dim Conn as new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Documents and Settings\admin\Desktop\Reminder\dbReminder.mdb") Sub btnSet_Click(obj as Object, e as EventArgs)
 dim objTrans as OleDbTransaction
 dim objCmd as OleDbcommand = new OleDbcommand ("INSERT INTO tblReminder (mobile, station, reminder, time) VALUES (@dotnet.itags.org.MOBILE, @dotnet.itags.org.STATION, @dotnet.itags.org.REMINDER, @dotnet.itags.org.TIME)", Conn)
 dim objParam as OleDbParameter
 objParam = objCmd.Parameters.Add("@dotnet.itags.org.MOBILE", oleDbType.char)
 objParam.Direction = ParameterDirection.Input
 objParam.Value = lblUser.Text
 objParam = objCmd.Parameters.Add("@dotnet.itags.org.STATION", oleDbType.char)
 objParam.Direction = ParameterDirection.Input
 objParam.Value = lblStation.Text
 objParam = objCmd.Parameters.Add("@dotnet.itags.org.REMINDER", oleDbType.Char)
 objParam.Direction = ParameterDirection.Input
 objParam.Value = DDLFields.SelectedItem.Text
 objParam = objCmd.Parameters.Add("@dotnet.itags.org.TIME", oleDbType.char)
 objParam.Direction = ParameterDirection.Input
 objParam.Value = tbTime.Text
 Conn.Open()
 objTrans = Conn.BeginTransaction()
 objCmd.Transaction = objTrans
 try
 objCmd.executeNonQuery
 objTrans.commit()
 catch ex as OleDbException
 objTrans.RollBack()
 lblError.Text = "Error inserting reminder into database"
 end try
 objcmd.Connection.Close()
 End sub
 Private Sub Page_Load(sender As Object, e As System.EventArgs)
 If Not Page.IsPostBack Then
 dim Conn as new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Documents and Settings\admin\Desktop\Reminder\dbReminder.mdb")
 dim objTrans as OleDbTransaction
 dim objCmd as OleDbcommand = New OleDbCommand("SELECT time + ' ' + programme as fieldone FROM tblRTE ", Conn)
 Conn.Open()
 DDLFields.DataSource = objCmd.ExecuteReader()
 DDLFields.DataTextField = "fieldone"
 DDLFields.DataValueField = "fieldone"
 DDLFields.DataBind()
 Conn.Close()
 End If
 If Not Request.Cookies("rm_user") Is Nothing Then
 lblUser.Text = Request.Cookies("rm_user").Value
 end if
 End Sub
</script>

This is the code im using to take the information from the form and enter it into the database.
But it displays my error message every time...
Is it correct?
The part im not sure about is this:

objParam = objCmd.Parameters.Add("@dotnet.itags.org.REMINDER", oleDbType.Char)
objParam.Direction = ParameterDirection.Input
objParam.Value = DDLFields.SelectedItem.Text

Is this the correct way of taking the selected items text from the ddl?

Thanks.Your code looks good, however your SQL looks dodgy. Thisthread in the DevShed forum should help.
I do somthing similar on a page. I think your problem is that the code for the DDL is in the on postback block. When the page is posted back ( user chose something and clicked button to do save) the ddl is not populated.
Try taking the DDL code out of the is postback IF block...


Private Sub Page_Load(sender As Object, e As System.EventArgs) If Not Page.IsPostBack Then
 End If
 dim Conn as new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Documents and Settings\admin\Desktop\Reminder\dbReminder.mdb")
 dim objTrans as OleDbTransaction
 dim objCmd as OleDbcommand = New OleDbCommand("SELECT time + ' ' + programme as fieldone FROM tblRTE ", Conn)
 Conn.Open()
 DDLFields.DataSource = objCmd.ExecuteReader()
 DDLFields.DataTextField = "fieldone"
 DDLFields.DataValueField = "fieldone"
 DDLFields.DataBind()
 Conn.Close()
 If Not Request.Cookies("rm_user") Is Nothing Then
 lblUser.Text = Request.Cookies("rm_user").Value
 end if
 End Sub

also, I don't think you need the transaction stuff. Transactions are used for multiple DB actions. not a single action. The try block should suffice. If the single DB action fails ( your insert) there are no other actions to rollback.
Hope that helps
> I think your problem is that the code for the DDL is in the on postback block. When the
> page is posted back ( user chose something and clicked button to do save) the ddl is not
> populated. Try taking the DDL code out of the is postback IF block...

This is not the problem. The DDL is repopulated via ViewState on PostBack.

I do agree about the Transaction.

One thing that would help solve this is for emmettd to post the error message.
I talking about the error message in my code.

its "Error inserting reminder into database"

its in the code, in the btnSet_click, near the end.
change this line and let us know what you get

lblError.Text =ex.tostring()

Thursday, March 22, 2012

Tags vs. code-behind

Tags vs. code-behind

Taking a value from one window to another

taking text from a drop down list and want to insert into a database

Taking over project

Blog Archive

About Me