I am using RadListBox and RadDateTimePicker in a traditional C# ASP.Net 3.5 web application, and I have labels like this:
<asp:Label ID="lblStartDate" runat="server" Text="Start Date" AssociatedControlID="dtpStartDate" />
<telerik:RadDateTimePicker ID="dtpStartDate" runat="server">
</telerik:RadDateTimePicker>
The label doesn't connect to the date picker with a for attribute because the picker is a complex control and it can't work out which element to target. Telerik propose a JavaScript solution to this, but that seems unwieldy to me and also depends on client side scripting.
Is there a better way which will provide a reasonable level of accessibility? Either wrapping the Telerik solution somehow or an altogether alternative approach?
Yep, the Telerik picker is a composite control as well and similar javascript to attach the label to the date input should do the trick. To reference the input field, use the get_dateInput() property from the client API of the picker.
Related
Situation: I have been creating webpages in HTML5/CSS3 & Javascript using Sublime 2 text editor for a year, however a college course now requires me to use Asp.Net and Visual Studio 2010. I do not use the designer because I am proficient at doing things by hand, however I find that writing asp: inside every element is time consuming and causes syntax errors when applied to some HTML 5 tags and not others.
Example HTML 5: <button id="btn" type="submit" value="Button"/>
Example Asp.net: <asp:Button ID="Button1" runat="server" Text="Button" />
Question: Can the asp: portion be omitted without effecting anything or is it required for IIS or the C# back-end functionality? What about runat="server" can that be omitted?
Google has come up dry regarding my inquiry, so any help is appreciated.
you simply cannot remove either of the two
but hear me out why, because I have a feeling you are not familiar with ASP and therefor are mistaking the meaning of the asp: and the runat="server" syntax.
first: runat="server"
this property on an element, tells the the compiler that this is actually a server side control
so a <button/> is not the same as an <button runat="server"/>
the first one is pure html, while the second one is a control, which can be bound to on the server side. .Net will give it a clientID (not to be mistaken by the ID you have to give it yourself).
second: asp:
this is a prefix, on certain elements, that tells the compiler these are ASP controls (the default controls given by the ASP.net framework). These include Buttons, TextBoxes, DropDownLists, ...
do not mistake 1 of these with a html element.
an <asp:Button id="myAspButton" runat="server"/>
is not the same as a <button id="myHtmlButton"/>
the first, is a server side control, which can be bound to (see it's runat="server" attribute), and this control renders to the browser as a <input type="submit"/> for example.
you could alter the rendering of the asp.net button class to make it return something entirely differnt if you wish.
and you are also not limited to using asp.net classes.
you can create your own controls, and put them in a custom created library
you could give those your own prefix.
if I created such a custom control, I could register a prefix for it in the web.config file,
and thus I could create a custom button extending from the original one (but with a default label in front...
<myc:CustomButton ID="myButton" Text="myButton" Label="myLabel" runat="server"/>
which could render into:
<label>myLabel</label>
<button ID="*******">myButton</button>
the asterisks are symbolizing the Unique ID it will get from the .net framework
if you want to know more on custom controls, or extending default controls
here is a step by step explanation to create custom controls, or extend from a TextBox control.
it also shows how you add a custom prefix for your controls (in the this case 'cc')
you can find more info here
The runat="server" part is required to tell .NET that it will have to render a button there (which will contain .NET specific ID for processing upon POST). Not too familiar with web forms (I started with MVC), but I would assume that the asp: part is to help distinguish between server controls and standard HTML markup.
Why not try removing it and if it breaks something, then you know it's needed. For instance if the button doesn't show up after removing it, then obviously the .NET markup parser needs it to be there in order to know that it is a place holder for a server control.
the website I'm currently developing can display dynamically-built forms.
A form is composed of fields, which are created directly by the users and can be displayed as one of multiple types that we support (text box, list box, tickbox, radiobuttonlist etc.). The rendering logic uses a repeater that iterates over a collection of all the fields defined by the user.
Inside the repeater (directly in the aspx page), one instance of each of the types we support is defined.
<asp:Repeater ID="fieldRepeater" runat="server">
<ItemTemplate>
<asp:TextBox ID="textBox" runat="server" />
<asp:DropDownList ID="dropDownList" runat="server" />
<asp:CheckBox ID="checkBox" runat="server" />
<asp:RadioButtonList ID="radioButtonList" runat="server" />
[...]
</ItemTemplate>
</asp:Repeater>
During the loading, we figure out which control is required and actively hide all the other ones.
Being still new to the web based development world, this approach seems very odd to me. My guts would prefer keeping the UI clean and instanciate exactly the controls that are required in CodeBehind and not start "playing" with visibility... but the current approach has some obvious benefits as well.
Is it really how one would do it in a web app?
Are there some best practices here?
Thanks!
I have no idea what the best practice is here, but I have done something similar before in a previous project and tried both approaches. Both will work.
Creating the controls in code-behind can be fiddly, especially if you are having to deal with post-backs. The controls have to be created in OnInit, as otherwise they won't get the posted form values and viewstate populated. This will cause complications if any of the control creation is based on the values of other controls, as you won't known the values without manually delving into the posted form values.
The only practical disadvantage with your current approach that I can think of is that all four controls (TextBox, DropDownList etc.) have to be instantiated and processed server-side by ASP.Net, which is a bit of a waste of resources. But it's probably not too significant; maybe do some profiling to see. I do agree that it seems a bit odd though, it doesn't feel very "clean".
As you said you're new to web development, then I would recommend continuing with your current approach of including all the controls and hiding the irrelevant ones. I just found it simpler when I did, even though it may not seem as nice.
Good luck!
I'm using markdownsharp with my asp.net forms website.
I want to use MarkItUp as my editor and have found a straight forward article on how to integrate with MVC which seems straight forward enough: http://rsolberg.com/2010/09/asp-net-mvc-markitup-rich-text-editor/
However, how do I do this with a forms website?
How do I get the MarkItDown Textarea on a postback and get the preview to work as well?
Place the Javascript and CSS file links in the head portion of the page just as you would with MVC. Then in your form, place a TextArea control. Set the rows and columns as needed.
<asp:TextBox ID="txtEditor" runat="server" TextMode="MultiLine" Columns="40" Rows="5" Text="" />
Then use JQuery to enable to functionality.
$(document).ready(function() {
$('<%=txtEditor.ClientID%>').markItUp(mySettings); });
Then on PostBack the contents of the editor will be available in the Text property of the TextBox control.
txtEditor.Text
This is not the only way to do this, you could also use a HTML TextArea control with a runat="server" attribute. Use whatever your personal preference is.
Is it possible to set a specific ID on an ASP.NET server control? Everytime I assign an ID and run the web form the ID changes.
For Example:
<asp:TextBox ID="txtName" runat="server"></asp:TextBox>
Gets translated into this:
<input id="ct100_ContentPlaceHolder1_txtName" type="text" />
I think this is do to me using master pages, but if so how can I be sure a control will have a certain ID(for javascript purposes). I placed the auto-generated id in my javascript and it is working, but I would prefer to have used the id's that I originally assigned them. Is this possible?
(This is for version:ASP.NET 3.5)
Starting with .NET 4 you have greater control about how the client-side IDs look like (see this post for details).
To force a specific client-side ID, you have to set the ClientIDMode to static. The following will render an <input> element with id="txtName":
<asp:TextBox ID="txtName" ClientIDMode="static" runat="server"></asp:TextBox>
Although if you do this, you have to ensure that you don't have two controls with identical client-side IDs. Check the article linked above for other options.
This is the way web controls ID's are in .NET prior to version 4.0. Version 4.0 introduces client IDs, which you can read about here.
You can use somthing like this in your JS:
var something = '<%= txtName.ClientID %>';
You can use the Control.ClientID property in your codebehind to get the actual id after it's been added to the control tree.
Super annoying choice made by the asp.net webforms people.
I have been searching around to find the best option of doing this.
Basically, I want to do two way databinding of multiple controls (textbox, dropdownlist, checkbox, etc) to a single instance of custom class/entity, ie: Person.
It seems, the (only?) way to do this is using an like so:
<asp:FormView ID="FormView1" runat="server" DataKeyNames="OrderID"
DataSourceID="SqlDataSource1" DefaultMode="Edit">
<EditItemTemplate>
OrderID:
<asp:Label ID="OrderIDLabel1" runat="server" Text='<%# Eval("OrderID") %>' />
<br />
CustomerID:
<asp:DropDownList ID="CustomerIDDropDownList" runat="server"
DataValueField='CustomerID' DataSourceID="CustomerDataSource"
DataTextField="CompanyName"
SelectedValue='<%# Bind("CustomerID") %>'
/>
EmployeeID:
<asp:TextBox ID="EmployeeIDTextBox" runat="server"
Text='<%# Bind("EmployeeID") %>' />
<br />
Some issues:
- This is limited to using an ObjectDataSource control (ie: can't just use an instance of the desired class in the code behind)
- Forces you to define a second (likely identical layout) read only template....would be nice to have some some mechanism that could intelligently render a read-only view derived from the edit template.
- The binding declaration Text='<%# Bind("EmployeeID") %>' is loosely typed, so vulnerable to spelling errors
- etc
So my first question I guess is, is an asp:FormView the only way in ASP.Net to do declarative databinding of a single entity?
Secondly, how feasible would it be to hand roll some sort of a two way binding mechanism? I guess it would have to be reflection based, but I could live with that. Anyone recommendations on how one would declare the binding relationships in the aspx page? Would the proper way be like:
Text='<%# MySuperDuperBind("EmployeeID") %>'
And then somewhere (where?) my MySuperDuperBind implementation will get called as the page is rendered....how this is done is a bit beyond me though. And if I want to render in readonly, I can call a secondary function that will remove the editable UI control from the form and replace it with the corresponding read only version (ie: a Textbox is replaced with a Label).
Another alternative route is getting away from webforms and going to a client side templating solution such as this very nice looking solution:
http://weblogs.asp.net/dwahlin/archive/2009/05/03/using-jquery-with-client-side-data-binding-templates.aspx
However, I have no clue how to write the asp.net webservices properly in order to retrieve and save data in this type of an architecture.
Ideas?
is an asp:FormView the only way in
ASP.Net to do declarative databinding
of a single entity?
There's also DetailsView but it has the same issues.
I've mostly given up on 2-way databinding. It's great for prototyping and gets me 80-90% of the way to a complete solution but the last 10-20% is a nightmare. Binding any non-trivial object always seems to involve so many event handlers to customize behavior that it feels like spaghetti code to me.
I usually have two methods:
MapEntityToView(entity)
MapViewToEntity(entity)
that I call to display the entity and to populate from the page, respectively. It can be tedious to write but I don't have to wrestle with data binding issues.
I do use 1-way binding extensively for read only pages and displaying items in list controls.