why displaying-expressions don't work in server/user/custom controls ASP.NET-CodePudding

I know for a fact that we can't use

So, asp.net controls simple never did allow such server side expressions.

but, they DO ALLOW binding expressions!

So, in place of "=", you can replace with a #.

So, lets try this:

        <h4> <%# MyCompany() %></h4>
        <br />

        <asp:TextBox ID="TextBox1" runat="server"                
            Text='<%# MyCompany%>'    >

        </asp:TextBox>

With a "#", then the page will need to fire/trigger databind().

So, trigger a databind() then, say like this:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

    Page.DataBind()

End Sub

Public Function MyCompany() As String

    ' return current comany name from settings
    Return My.Settings.CompanyName

End Function

Now, when run, we get this:

So, it not 100% clear why server side expressions were never allowed in standard asp.net controls - but they are not. However, you can swap out the server side expression with a databind() expression, and quite such you can then use those expressions just about everywhere.

It is a design and architecture issue. Simple put, any server side control can be setup, changed, and modified by code behind. So, why have two roads, two ways of doing the same thing?

And you get a lot more control - I find tossing around all those server side expressions intermixed inside of the markup? Messy, hard to change, and not all that great anyway. I suspect that if all the standard asp.net controls allowed this, the world would be suffering in more poverty and confusing for the last 20 years, and so, I think they made a great decision.

but, you can using databinding expressions if you want in most cases. You just have to then go:

 me.SomeControl.DataBind()     (vb.net)

 this.SomeControl.DataBind();  (c#)

or, all expressions on the page with this:

 Page.DataBind()

but, be careful - that last one will trigger DataBind() for all controls.

so, if you have existing gridview, dropdown boxes and trigger a page wide databind?

Then all of the data bound controls also will re-trigger a databind. In most cases, that means your say gridView will go blank!!

(unless you add a databind event).

I mean, in place of the above expressions, or say the kluge databind() idea?

You could have this markup:

        <h4 id="myHeading" runat="server"></h4>
        <br />

        <asp:TextBox ID="TextBox1" runat="server"  >
        </asp:TextBox>

So, we now have free and easy use of the above controls in code behind, and on page load can do this:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

    myHeading.InnerText = MyCompany()
    TextBox1.Text = MyCompany()

End Sub

And this brings up another issue. Why set a text box to some expression, and then the user can't edit that text box - it will always revert back to the expression?

But, worse yet?

MOST server side controls have what we call automatic view state. That means a text box, check box etc?

They automatic retain the setting or value of the control. So, if you type some text into a text box, and hit a button - on post back, and page return from server? The control STILL keeps it settings. So, having view state for a control, and then ALSO having some server side expression does not make ANY sense, since now two places on the page (control view state) and a server side expression has to be re-run EACH and every time the page renders.

So, there is a performance issue here also. Server side controls already have a bunch of bits and parts to RETAIN their values, and now we suggesting to introduce expressions that will over-ride the setting in the text box for example.

So, there are 100's of reasons in favor of not needing nor allowing server side expressions in the markup.

Last but not least?

Server side controls DO NOT always render the markup REMOTE CLOSE to what the control is on the page.

In other words, after the asp.net processor is done with that control, your final output HTML is often VAST different - so much so, that the expression would not make sense.

Take a simple text box, drop into form, and look at the FINAL rendering. For text box above, we see/find this:

<input name="TextBox1" type="text" 
   value="The Turtle Creek Company" 
 id="TextBox1">

Note how there is NOT EVEN Text=some expression!!!! - So, how can the system now start to set Text="some" expression when the control render does NOT even have a expression anymore!!!

And lets make the text box mutli-line, like this:

        <asp:TextBox ID="TextBox1" runat="server" 
            TextMode="MultiLine" Height="142px" Width="488px" >
        </asp:TextBox>

But, say you wanted to set/change TextMode in above? But, Text mode is due to .net pre processing of that server control into HTML.

And you now get this when run:

But, looking at markup, the Text box is now this:

 <textarea name="TextBox1" rows="2" cols="20" 
    id="TextBox1" style="height:142px;width:488px;">The Turtle Creek Company
 </textarea>

Note how we NOT EVEN using a input HTML type anymore!!!!

In other words, the values, the attributes, the settings for a server side control? When the markup is generated, then we don't even have the SAME attributes that existed before we started!!!

You think even a simple textbox above is a great example? Now try a GridView, ListView etc. The attributes, the settings? They are not EVEN remote close to the final markup.

So, those in-line expressions? They ONLY ever make sense for plain jane markup, since such expressions for server side controls make LITTLE sense, since the markup generated is not EVEN REMOTE close to the markup you placed in the page.

so, with a server side control, and the markup NOT being standard markup?

Then how can you have such <%= > expressions then? They don't make sense!!!

And in your user control? You are MOST free to have use those <%= > expressions in the CUSTOM markup for that control.

But, you suggesting that the expressions should work at the markup level in teh page. But that server control markup does not really even exist anymore. As I show above, that simple text box is NOT REMOTE close to a simple HTML input box, and even just change of textmode causes a VAST different rendering of the control.

So, in-line expressions? They are for markup - not for server side controls, and they don't make a whole lot of sense for server side controls, since EVEN the attributes of the control like Text may not exist in the final HTML it spits out. How and where do you shove this:

 Text='<%= MyCompany() %>

Where will above go into the final control, when the final control does not even HAVE a Text property anymore?????

So server side controls are just that - magic controls who's final actual output has VERY LITTLE relationship to the original markup.

So, with non server controls, such expressions make sense, since the markup you type, and the expressions you type are NOT being vast re-processed from that server side control into some complex set of REAL AND VALID markup that is spit out to the page.

So, with plane jane markup, then simple substitution of <%= > to some value is easy.

With a server side control? The attributes in question set to such expressions may well not even exist in the final output.

So, while you can't use such expressions in the markup that defines the user control?

You sure as the heck are 100% free to such such expressions in the markup you define for that user control.

So, if you want to use server expressions in the markup that your custom control generates? You are free to use as such. But the original user control in the markup will be removed, processed to html, and the original settings may well not even exist anymore in the final HTML OUTPUT.

Even the above text box shows this. The simple text box with one tiny change to TextMode=Multiline now does NOT EVEN output a input html tag, but now uses a text area - all now with 100% different attributes.