Right now I just output my value(s) like
<input type="text" class="form-control" value="#Name" id="name" placeholder="Name">
But I've seen a lot about #HTML display something?
Should I use HTML display, and if so, how and why?
The Html helper class is there to encapsulate writing a lot of html code in a single call:
- the actual field
- validation rules according to your model Field Attributes
- the validation place holder
- Value binding
additionally, allows you to change the behavior and html of all your fields in case needed, in one spot.
it is, like many other things, a tool...
use it if you wish...
for my opinion, it rule and should be used.
You can do it either way. #Html.TextBox and #Html.TextBoxFor will automatically generate the html for you, but you can do it yourself if you want.
Personally, I prefer writing my own html, but that's just me...
The # symbol allows you to access c# code within your cshtml file so you can mix html and c# code to generate a final html output. For more information, search for C# Razor syntax, here's a link for more info http://www.w3schools.com/aspnet/razor_syntax.asp and http://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx/
The benefit of using Razor syntax is the ability to access helper c# methods, global variables, view model variable object passed from the controller, view compile time errors (by default, it's off in visual studio, check http://haacked.com/archive/2011/05/09/compiling-mvc-views-in-a-build-environment.aspx/ for more info), you don't need to use javascript to populate a form or other fields dynamically ...etc
The downsides are your code needs to be compile to html so browsers can process it, a syntax error can crash your whole page, your cshtml code is not portable in case you decide to switch backend engine, ...etc
Related
I would like for a webmethod to return a string of pure html.
The html isnt anything too fancy, a table and a couple form fields populated with values from a database.
Is their an easy way to build html within html? currently I am just dynamically building up a string, but it just feels dirty.
I could make a full blown aspx page, and then just strip out the bits I dont want from the resulting page leaving the plain html behind. but that also feels dirty.
Or there is the templating option (nvelocity etc) but thats seems like overkill.
any suggestion on something more efficient.
Tx
You can build a template file like xml to write the basic of your html with {0}{1}{2}{n} to put static content in it
Manipulate this template server side as you wish. You can add a list of data into this template.
Create a literal control on your page.
Put the server side created html in to you literal control. (myLiteral.Text)
You can create a basic asp.net file and add the html template in it by adding it from the literal control.
Does anyone know if it is possible to leverage the power of JQuery on the .Net serverside?
For example I have some HTML as a String in some code behind. Is there a way to execute JQuery on it?
I'm currently doing this...
Assume this is the String...
<input id='AddressSettings_txtFirstName' name='txtFirstName'
value='#firstNameValue#' size='25' type='text' class='val_required'/>
My C# does this
strHTML = strHTML.Replace("#firstNameValue#", customerInfo.FirstName);
And this is how I bind my data to my HTML.
Now what I would like to do is instead of having to add the #firstNameValue# as a place holder and replacing it I would like to somehow execute a line of JQuery on the HTML string in my C# code.
strHTML = strHTML.ExecuteJQuery("$('#AddressSettings_txtFirstName').text('"
+ customerInfo.FirstName + "')");
What are my options here?
For all intents and purposes, the answer is "no" (while there might be some obscure way of handling this, it's not the most optimal way).
It appears you are looking for a way to manipulate the HTML that is being produced on the server-side, which is a very legitimate desire, it's just that the approach on the server side using .NET (or other) technologies is radically different than how you would approach it on the client-side.
Because the content is already rendered on the client, the way you would apprach modifying it is different. On the server, the page is built of from various parts which ultimately render the HTML to the client, using data that the client doesn't necessarily have access to (as well as resources and libraries).
It's for that reason you want to use what's available on the server to accomplish what you are doing.
Whether you are using the WebForms model or MVC model of ASP.NET, there are mechanisms that allow you to bind to data without having to write out the tag yourself.
For example, in the WebForm model, you have the TextBox class which you can set the Text property on.
In ASP.NET MVC, there is the TextBox extension method on the InputExtensions class which allows you to pass the content of the textbox and the method will render the tag for you.
May be what you want is the HTML agility pack. You can't execute JavaScript, but you can do some DOM manipulation. Give it a try http://htmlagilitypack.codeplex.com/.
Use jQuery with jsdom for Node.js. Easiest way to manipulate DOM elements using javascript on the server-side.
The DOM is a browser specific entity. Thus, not directly available as you seek. However, you can determine just what you want to manipulate, and use either .live() or calling your jQuery code to add behavioral stuff as elements get added. As for change:
<input id='AddressSettings_txtFirstName' name='txtFirstName'
value='#firstNameValue#' size='25' type='text' class='val_required'/>
$('#AddressSettings_txtFirstName').change(function(){
// do stuff here
});
will fire when it changes for instance.
EDIT: One other option is to have the client pull the data using ajax and JSON - but that is a small shift in your method of working at present.
Well this is the answer for Java.Here and Here
Provided by some guy named John Resig. (Not sure he knows what hes talking about when it comes to JQuery...wink wink)
Now what about .Net?
This technology, ItsNat, is very similar to your desires, the bad news... is Java based.
Are there any real benefits to using ASP.NET HTML Helpers over Generic HTML?
For me, I really do not see any "major" advantage. What do you think?
Update:
How flexible is it with Javascript/JQuery?
Depends what you want to do with posted data. If you'll just read form variables in controller action, then it doesn't really matter, but if you plan to use internal model binding, it may be much more tedious for you to write manual HTML.
Another plus with HTML helpers is when you want to create some more complex parts of your document like:
Html.CheckBox()
Html.ValidationMessage()
etc.
Checkbox itself creates two inputs. A checkbox and a hidden field that makes it work with checked/unchecked state properly.
HTML Helpers are useful, when you want to reuse a piece of C# code and render some HTML dynamically without creating a full blown control.
Which is better/more maintainable, using Javascript to initialize the values of the different HTML controls or writing inline <% %> tags?
The current page I am writing has many HTML controls and I'm afreaid that putting inline ASP would make it too unmaintainable.
Well... using JS to populate the controls with values will make the whole solution useless in JS-free environments. This is not what the webdev community calls unobtrussive.
As you don´t define better any better (!) I would say go for the inline rendering.
If you really have millions (I really doubt this number) of HTML Controls in your page I would say you need to get back to the drawing board and re-architect the solution.
You are going to have the same problem regardless of the method: maintainability.
I have some legacy forms that need to remember some fields between calls, so I have a lot of code that might be a little ugly, but if you stick to a standard, doesn't get too messy.
<label for="email<%=i%>">E-Mail<% if required then %> (*)<% end if %>:</label>
<input name="email<%=i%>" id="email<%=i%>" type="text" value="<%=Trim(request.form("email"&i))%>" />
The problem is that it involves a lot of copy paste when having to add a new control. You could make a function to build it and keep the code duplication to a minimum.
<%= BuildHTMLInputControl("email"&i, "text", "E-Mail", true) %>
' Response: <label for="email1">E-Mail (*):</label><input name="email1" id="email1" type="text" value="Previous Value" />
I haven't done something like this, because it hasn't been a concern yet in the small forms that I've done this.
The advantage of this is that the fields are populated onload, there is no flashing of content and you are really friendly to non-Javascript users, something that you should be.
The only difference would be that with javascript youd have a lot of document.getElementById() at the beggining (or rather end) of the document, that increases the HTML file size (which might be a concern) and could not populate the fields instantly.
If you've really got loads and loads of HTML controls in an ASP.Net page, you might have to rethink your design. Why aren't you using server controls?
However, you can always use the runtat="server" attribute on HTML elements to effectively turn them into server-side controls. You can then work with them in much the same way as ASP.Net controls. You may want to watch out for extra Viewstate being added, though.
What is better/more maintainable,
using Javascript to initialize the
values of the different HTML controls
or writing inline <% %> tags?
I wouldn't do it either way. That sounds like old-style ASP, or maybe PHP or JSP-type logic.
The ASP.NET model is to use controls on the page, and then to set the values of those controls either from code-behind or in-line code, possibly using some type of data binding. Separating the display logic from the data is much, much easier to maintain.
Off the top of my head, I don't see any reason why you couldn't structure an ASP.NET custom web control (ASCX file) to output only XML.
If you avoid using controls in the System.Web.UI namespace, and just use XML tags and sub-controls, which also render only XML, you should end up with a perfectly valid XML document being rendered.
Am I right, or is there something I'm missing?
If you want to generate an XML document and return that to the client, then it's probably easier if you create a http handler (IHttpHandler) instead of using a page and user controls.
You are missing that the control has to be within a page which would have some HTML output for a tag marking the start and finish of the control though there may be a way to override that.
Your idea could work out if your ASCX's generate pure XML, and you overwrite the Page's Render methods to replace the HTML tags that form HTML, BODY and FORM etc. elements.
The question is what you would gain with this approach over simply generating an XML document and building a class library which generates those XML fragments you wanted to generate using the ASCX's.