This question would apply to a typical CRUD page allowing the user to ADD, and/or EDIT a specific record.
Question about WebForms DetailsView control (and possibly FormView and GridView) -- Do we really need to specify BOTH the Edit-template AND the Insert-template which are essentially the same?
If not, which template should be designed/specified?
Your answer and comments are welcome.
Thanks...J.
In my experience you don't have to specify either template. In fact the only time I even use templates is if I want to customize certain attributes that you can only do via a template. I typically use templates when I want to have RequiredFieldValidators. Otherwise I don't use them at all. But you certainly can have neither, either or both.
That being said, I do usually have Item, Insert and Edit templates when I do need the extra flexibility of templates. Seems more complete to me.
Related
Lets say you are developing an web app that requires that you are able to Add/Edit items. The item form contains several input control. Would you separate the add/edit pages or use the page for add/edit and control via querystring (i.e. ItemAddEdit.aspx?isEdit=1)
The advantage I see in separating is that it is easier for the (non-technical) user to type the page and to determine whether it is add or edit. Also, when there would be specific changes to each page (if ever), it would be easier to change.
For the single page, well, you reuse code which eliminates some duplicate code and avoid possible problems.
And no, I can't use routing.
This is generally something which could be a subjective thing, because there's as many ways of doing things as there are coders, and a lot of it can be depending on how your system is set up generally.
But, if I were to recommend, I'd say the way you should do it if working with asp.net web-forms is to make two web pages (add/ edit) and then you use a user-control on those to group up the shared logic between the two pages. After all - that's why we have user controls.
In this way you can have both of your situations, by keeping logic in one file/class, but still have two entry points.
This would also mirror more how MVC does it, which could be considered a plus.
That being said - if your administration functionality is behind login etc, there's nothing to hinder for actually doing it in one and separate with the query string approach, and then just load the data if editing or display "empty"/base data when creating.
You shouldn't have the user type the addresses anyway, but click through the links to follow your flow, so the query string should be a minimal issue.
But for the sake of keeping your functionality clean and divided, I'd personally recommend going for two page / usercontrol approach.
I am using C# asp.net. I want to implement a commenting system which is similar to facebook commenting system look & feel. Please give your inputs.
When it comes to storing,retrieving and displaying comments yes asp.net controls come into use.
Other things being done, to accept a comment and display existing ones for that object (may be post) I would do:
1: Retrieve the comments for that object from database. (easiest way is to use SqlDataSource and set Select, Insert and Delete commands)
2: Use ListView control to display the retrieved data . Remember ListView should be customized to fit you need
Other databound controls are also usable. With these rich controls this task should be easy. Play with the templates these controls offer you and you can achieve almost any database related task.
Design and styling are sufficiently supported and still CSS + can be easily integrated.
Can some one please tell me if I should use user controls in my project as much as I can? Ff so why and if not why not?
It's an interesting question; but think of it this way.
You've just written a table, listing all of your users. You show this on the List Users page of your website.
On the "Find User" page, you might want to be able to show a list of users. Do you rewrite the same HTML, code, javascript, CSS as before? Or do you reuse the control, this time adding the ability to filter by a user name or other attributes?
Essentially, user controls are there to package up reusable bits of your website. Rather than repeating the same code everywhere, you can package it up in a user control, and simply add it to any page you want just by adding the appropriate tag.
Also, you have just made ONE control in your project responsible for dealing with some functionality - all of the logic for it is in one place and separated from other code. This is an important concept too, as it stops all of your code being jumbled together. In the users example, you can interact with a list of users through an interface, rather than mixing it with other code that might do different things. This is called SRP and can be a good thing.
As a practical example, we have a control that shows a list of our products. We can reuse the same control on the Find screen, the Admin screen, the "Products Like this" screen, and on the "Products you have chosen" screen. This code contains a lot of logic that is all in one place so it can be maintained easily, and it can be reused very simply too.
User Controls can be a very good thing. So you should use them when you feel like you can package up a group of existing controls, HTML etc. It makes them reusable, and much easier to maintain.
There is also the concept of custom controls - these are usually reimplementations of existing controls - you might have an ExtendedTextBox, for example, that validates the text as someone types it.
You can read more about both kinds of controls here
User controls are good for the same reasons that subroutines/functions/methods are good: code (and markup) re-use.
Like subroutines, controls can be a problem if they do things like modify global state, make lots of DB or other off-box calls that aren't always needed, introduce unavoidable synchronous blocking, etc. They can also add an unnecessary layer of complexity if they are never re-used.
I would use the controls that the VS IDE Toolbox provides as much as possible. I would only roll my own control if something that the environment supplied, didn't quite do what I wanted it to do.
I am creating a form that needs to have 30 or more fields either disabled or set to be read only. They need to be marked as such if the based on the value of a drop-down box.
This is something that I can do using conditional formating that I know, what I want to know is there a way to either add conditional formatting to multiple controls at once or a rule that I can set that will accomplish the same thing?
One requirement is that I can't use programming code to do this. I realize it would probably be far easier to do that way but that is a requirement given to me by my manager.
EDIT: Forgot to add this there are fields that still need to be edited when the other fields are read only.
One feature in InfoPath 2010 (can't remember if it was in 2007) that reduces the pain of this sort of repetitive work is the ability to copy-and-paste rules. With this you can create your read-only rule once and then just paste it onto each of the 30 controls that need it.
You could put it all in a section but your only option for sections is hide/show (not disable or read only). Otherwise you have to setup all the fields against that one dropdown. Huge pain but at least you only have to do it once.
An alternative, which is just about as much work, is to setup two views. One that is readonly and one that is normal. When the user changes the dropdown just flip the view. This method has a bunch of display nuances but does work.
I find the repetition of sets of controls for each of the EditItemTemplate, InsertItemTemplate, and ItemTemplate templates of a FormView to be tedious and risky, in terms duplicating layout and code etc. I would much rather create a xxxDetails user control, and use this in each template, cutting layout and code location down to one location.
However, this introduces several complexities for data binding scenarios. Are there any extablished patterns or practice guides for using user controls in these scenarios?
Microsoft just added really great support for this in ASP.NET 4.0. It is called DynamicData. They added methods on all data controls called EnableDynamicData(type). There are default templates included in ASP.NET, but you can make your own.
To use built custom templates, just add a DynamicData/Templates directory in your folder. Inside it you can add type views insert and edit templates for all of your data types. The default templates have validators built in so they are a great starting point!
Here is a sample I put together for using custom controls in DynamicData templates. I used a slider for editing integers, and CurrencyInput for money etc...
If you can go with using ASP.NET 4.0 I would highly recommend doing this. Also, even if you can't, you still might want to use the pre-built templates as guidance.