Well, I know there is lots of questions about usercontrol performance, my question is perhaps different.
I would like to generate my webpage dynamically and unfortunately creating a code for that is a pain when the code contains lots of DIVs, IMGs and other controls.
Usercontrols has a advantage becuase they are created by markup code and It's easy to add getters/setters. That means I can easily edit my code and also control the content.
These usercontrols only contain HTML code with few controls like Label or Textbox. That's all.
I would like to ask, if my approach is ok. What's your opinion about that ?
Thank you
Here is a great article describing some pros and cons on using WebForms versus something like MVC. I've used both and like MVC #tonsupontons better.
http://www.codeproject.com/Articles/528117/WebForms-vs-MVC
Your question is somewhat of a religious debate however so I don't think there's a good answer. If it works and isn't bloated full of view state nonsense and you don't do things like Unit Testing then WebForms and UserControls work fine and you should not really notice a performance hit one way or another. <= My opinion I think though, with some exposure to MVC, you might find it much easier to do what you're doing
Is there anyway to let users write their own aspx templates with my defined dynamic variables? Note that I don't want to use Web Forms (so there are no tags like <asp:button> etc).
In addition, I'd need a security solution so users can't change the system or do dangerous things like this.
Thanks.
Personally I would avoid using the ASPX engine for this. I would probably use either a really simple custom formatting solution (such as just a text file with %%VAR_NAME%% allowed for dynamic values), or I would look at a templating language such as Markdown (used by StackOverflow and others). BBCode is another option in a similar vein.
Allowing people to create ASPX templated pages on the fly seems like to much of a security issue to me. It would be hard to make sure you have closed all the possible attack vectors once they have direct access to the ASP.NET engine.
Since you didn't specify, I'm just guessing at your needs, so depending on the exact problem this may or may not be your best bet. If you include more details about the problem you are solving it would be easier to make suggestions.
I'm interested to hear from other developers their opinion on an approach that I typically take. I have a web application, asp.net 2.0, c#.
What I usually do to write out drop downs, tables, input controls, etc. is in the code behind use StringBuilder and write out something like sb.Append("
I don't find myself using to many .net controls as I typically write out the html in the code behind. When I want to use jQuery or call JavaScript I just put that function call in my sb.Append tag like sb.Append("td...onblur='fnCallJS()'.
I've gotten pretty comfortable with this approach. For data access I use EntitySpaces.
I'm just kind of curious if this sort of approach is horribly wrong, ok depending on the context, good, time to learn 3.0, etc. I'm interested in learning and was just looking for some input.
Edit
After reading the comments here it sounds like I should take a look at MVC. I've not done that yet. The only hesitancy in doing so is that the existing project is just that, existing. There is a lot of code already done the way I explained and it is hard to imagine what would be involved in changing it, advantages of doing so, and just learning what that would take.
The other thing I'm taking away from the comments is that my code behind should really not include much of the sb.Append code, whereas now it is filled with it in numerous functions. To me it is not messy but that is because I know what each function does and can look at it and see, oh that writes out x, y, and z.
It's not uncommon for me to just have a div on the .aspx part and then build up the .innerHtml of that with the StringBuilder in the code behind.
Thanks again for the comments. I'm thinking as I'm reading them.
I typically write out the html in the code behind.
That part is a little odd, and not something I recommend for webforms. If you want to do that, consider an asp.net mvc project instead.
In webforms, you really want the meat of your html to live with the markup rather than the code. The two should remain separate. You also don't want a huge stringbuilder that encompasses your entire page. This will force you to keep the entire page in memory twice (once for the stringbuilder bytes and once for the built string at the end) rather than writing the page to the response stream as it's built. That means more memory per request, which can really kill scalability.
To those ends, I would abstract distinct portions of your stringbuilder code into custom/user controls that you can use in the aspx markup. These controls can use a stringbuilder to create their output. This means you only need to keep enough html markup in memory to render one control at a time. It also allows you to more easily re-use common markup across pages or even sites.
There are times when you need to generate some HTML in your code behind, but in general, you want to leave the HTML where it belongs, and that's seperated from your code. The VS IDE is a pretty good HTML editor. Use it.
I'm going to go out on a limb and guess you may have come from a "Classic" ASP (vbScript) or PHP background.
My back ground is "Classic ASP" and my first attempts at the Webforms Model were pretty much the same as yours, once I started usnig them and understanding them I've never looked back. There is a disctinct learning curve though in understanding how the page life cycle interacts with the various WebForm controls.
Look up the various threads on ASP.net WebForms vs MCV to see which suits your projects needs the best. MVC Isn't a magic cure-all but in many respects may be more familiar if you're from a "Classic ASP" or PHP backgound.
From a practical perspective, assuming you're sticking with WebForms, if there is the possibility of other developers becoming involved in the project you aim towards using more of the inbuilt controls where you can as that is more than likely what they will be familiar with. Stating the obvious, the more you use the controls the more you will become familiar with what they can and can't do and before to long you will find yourself writing your own controls to fill the gaps or finding existing 3rd party controls.
A big problem you have with that it can get pretty messy... having to escape all the " or messing with carriage returns. Sure YOU can program around that, but what if you want to copy/paste code? sounds like a nightmare and WAY more work than it's worth.
It sounds like you should be writing a custom control and using HtmlTextWriter to write the markup.
Or perhaps more appropriate would be a user control, with markup in the aspx page and anything else in the code behind.
If you're using this approach, you should migrate your development efforts to ASP.Net MVC. Whereas ASP.Net actively tries to abstract the HTML, CSS, JavaScript, etc. away by using web controls, ASP.Net MVC is built around a paradigm of directly controlling the markup itself (though that may arguably be the least of the differences between the two - you should definitely read up on it to at least know the alternatives, even if you stick with ASP.Net in the long run).
Otherwise, what you're doing works if done properly (though you'll be fighting the framework the whole way), though I'd recommend using a StringWriter instead. It uses a StringBuilder internally so the performance characteristics are the same between the two, but the semantics are more consistent with the rest of the .Net framework (e.g., Write vs. Append).
I think this approach kind of defeats the purpose of what webforms was trying to accomplish (separating markup and code).
I know this thread is kind of old and has been answered really well, I just thought I would "append" (pun intended) my answer since I am working with code that was mentioned in the question.
ALL the markup is in the C# classes and they created a StringBuilder object to append all the html and JavaScript strings. This has made it very difficult to read the code and see what's going on, and what if they want to change the markup/design of the front-end? Now, I've got a heck of job on my hands having to go in and refactor all that markup in the classes, when it would be so much easier to change the .aspx pages and connect the data model to those pages.
In my humble opinion, I can't find a good reason to put any markup in your classes/code behind. They are for logic only. Plus, it makes it difficult to test and debug Javascript. That's my two cents. K.
What are bloating controls?
Can anyone please explain it?
It's a term which can be used to describe a variety of things, e.g. it is commonly used by critics of ASP.NET WebForms where, if you are making heavy use of pre-built WebControls you have little control of the generated HTML, which in many cases appears 'bloated' (large) and 'unclean', 'messy', etc.
I'm not sure 'bloating' is exactly what you mean. Some controls could be called 'bloated'.
In that case it means that some controls offer a great deal of functionality which in most cases is not required. Grid controls tend to be fairly bloated because they expose functionality for sorting, filtering, binding, templating etc.. but it's unlikely that you'll use all of this in a single implementation of the grid so you're taking up much more memory than you actually need which could potentially cause performance issues.
Hope this helps.
I guess people are referring to the fact that some GUI controls are very big and thus a bit hard to understand / use.
I'd like to use ListView to display grouped data from my db. Because of the way the query is structured, each logical group might have 1 or 2 records associated with it. Is there anyway to use GroupTemplate, while overridding the GroupItemCount behavior? Ideally, I'd like it to behave the way SQL does- assign a column ID, and let it watch for a change in value.
Ok here it is, nicely documented
It would be nice to build this kind of functionality directly into the control so you can simply specify this "watch" field using markup.
Again, this is the reason why I switched to the ListView, to try to avoid lengthy workarounds like this where you have to manually inject your own HTML. I bet they will eventually add this feature in and then claim how super amazing .Net 4.0 is.
All the time, more and more, I find more reasons to steer clear of inflexible .Net and use one of the more "direct" HTML manipulation platforms (PHP + CodeIgnitor). If you are absolutely fluent with CSS and HTML and know them backwards, you will find .Net uber frustrating every single time, because you just "can't quite get in there" and do what you need to do quickly without searching for workarounds all the time.
Summary: ASP.Net still isn't there yet.