What's the difference between these code samples? Which approach is right?
<asp:Label ID="lblShorName" runat="server" Text="<%#Customer.ShorName%>" />
lblShorName.DataBind();
and
lblShorName.Text = Customer.ShorName;
There isn't much of a difference that I know of (though I'll be interested in other people's answers to correct me if I'm wrong on that). It's just a matter of coding style and preference.
Personally, I prefer the latter. I feel that it's cleaner and separates the markup from the functionality which drives the markup. But that's just me.
(I also tend to prefer not using data binding where I don't feel I need to. But, again, it's a preference of how you want to use the tooling that's provided. For example, in an ASP.NET MVC view I'm more likely to write a loop and output HTML within that loop than I am to use any kind of repeater or grid control and bind data to it. Just personal preference.)
A lot of it also comes down to where in your application you want to perform these actions. The former example keeps it on the page, whereas the latter example can be wrapped in conditionals, re-factored into another method, etc. If it's possible that the value in question isn't always going to come from Customer.ShortName then I'd go with the latter example to add that additional logic around it.
The approach depends when you want to set the label. lblShorName.Text = Customer.ShorName; Can be used in different methods, events, timers. If you want to set it only at the beginning you can use the first one.
Not much really, when you use databinding your value is set at the time of databinding, however if you set it in the code-behind you can set it any stage of the pages lifecycle.
You may have some logic behind the value too and this is more readable/maintainable in the code-behind.
Related
I am building a form for parents to enter health information for their students. Our nurses want to build it similar to what you fill out when you see a new doctor where they have categories and then conditions within the category that you would check if they apply to you. They want the number of categories and conditions to be variable so they can change them willy nilly as desired.
I need some ideas as to how to approach the UI side. My initial thought is a parent gridview with a row for each category and then inside that, a child gridview for each condition with its own checkbox. I already do a bit of work with gridviews and know how to access the nested objects so I'm not terribly worried about how to get the data back.
My question is this: Is there a better way and what suggestions would the community make that might be different or more efficient than using nested gridviews?
+1 for asking is there a better way?
What I'm about to suggest may end up being a little more complicated at first, but rest assured it will be worth it in the end.
There is a JavaScript framework named Knockout.js that is perfect for situations like these. Knockout vastly simplifies situations that where a variable amount of UI controls are needed.
http://knockoutjs.com/
Here is a tutorial on the website that has a similar situation to yours:
http://learn.knockoutjs.com/#/?tutorial=collections
I seem to keep running into these complex show/hide scenarios in ASP.NET web forms where the logic goes "if Field A equals blah, and Field B equals blahblah, then Field C is shown/hidden/validated/whatever." Before I run off and start building custom validators and custom controls so I can more easily manage it in markup or backend code, are there any libraries or simpler solutions I'm missing out there in the wild? jQuery makes the job easier, but I get the feeling I could abstract a lot of what I'm wrangling with out into a more elegant solution.
All of the controls that are dependent on each other or could trigger events are my own custom controls already, so I get the feeling I could start writing a small framework to handle it like so:
<my:DynamicShowHide runat="server">
<PrerequisiteFields>
<PrerequisiteField ControlId="FieldA" Value="blah" />
<PrerequisiteField ControlId="FieldB" Value="blahblah" />
</PrerequisiteFields>
<DependentFields>
<DependentField ControlId="FieldC" />
</DependentFields>
</my:DynamicShowHide>
...that way if the Prerequisite values were both evaluated as true, the DependentField would show, and hide if not.
It seems (and feels) like I'm overengineering but I run into insanely large and complex decision trees like this more and more often. Anyone know of a better way or an existing library that does something along these lines?
out of interest, in which particular instances do the use of decision trees most prominently arise?
For instance, I am guessing it is in most cases with dynamic data (data retrieved from a DB). And say the common usage for it would be in forms (or questionnaires) - hard to say as you have supplied examples of the usage of decsiion trees.
If these are the cases, then would it not be nice to handle all the stuff in the DB and populate the controls in the browser dynamically? You can set all the dependantUpon, and ansewrLeadsTo in the database, and the possible answers, and type of input control to generate, and it would lead to a much cleaner solution.
Granted the initial setup would be hard, but in the longterm, consider flexibility and maintenacne, and it should be okay.
I have a widget that contains about 40 controls in it. Essentially when a user makes a selection from a Dropdownlist on my main user control, what I want to do is call a webservice to get the new values for the controls in my widget. Is it efficient to have each control essentially call the webservice to get values that pertain to it’s new state Or is there a way to have the widget as a whole get the new values in a collection and then set each individual control within itself with the new values that apply, without really getting into a situation where you have too much going on and therefore loosing performance values
I understand your pain there. The latter option I think would be more efficient, but you have to provide a way to let each control pull out the relevant information that it would need. So you download the information once, then each of the 40 controls goes through a process of extracting the information only it needs.
If this is done on the client-side, it doesn't matter as much since you are passing the work off to the client, but still the latter option would be more performant IMHO. The question is how to get it to work efficiently and be easy to maintain. That's always the challenge.
HTH
I've got a person object with a name and age property that implements INotifyPropertyChanged. I want to hook this object up to an ASP.NET form so that the 'name' and 'age' properties bind to textboxes in a way that, when changes happen in either place (in the control or in the object) the other will get updated.
Do I create an intermediary class that listens to each textbox change events and the objects change events and handle the updates between them? What's the best way to do this?
I'm unclear on how to get business objects and the UI talking to each other.
I've stressed over this exact problem a lot.
The short answer is, yes, an intermediate item.
The trick is to NOT write ANY code per control. You should be able to place a GUI control on the screen (That may or may not take code), and then bind your business logic to it through a generic binding mechanism.
I have defined the bindings through XML, through properties files, and through constant arrays--there are a million ways...
You probably have to write code per TYPE of object bound (a listbox binds differently than a text control) and you may have to write validators (but specifying the parameters to the validators and which control the validators bind to should also be done in data)
Now all that said, I'd be really surprised if some data-driven auto-binding mechanism didn't already exist, Microsoft has been into that since VB first came out (although their implementations used to be pretty inflexible, I'm sure they do a better job now).
I'm very insistent about the 0 lines of code per control because my job has typically involved configuring complex devices with dozens of pages of controls. A typical client/server system will have 7(!) lines of code PER CONTROL just to transport data from the DB, to the server, to the client, to the screen and back (this is a minimum for plain ole "dumb" code with no smart binding tricks).
0LOC/control may not be a requirement for everyone, but it's a good goal.
Comment response:
I've done most of my stuff manually in Java, so I'm not sure I can be too much help with the specifics.
Searching for C# and binding gave me this which looks promising, although it may be binding straight to a database which is too much IMO, it should bind to a business object, but the concepts should be the same.
One way to create the bindings at first is to manually instantiate binding objects... (Please excuse my Java)
TextControl textCtrl1=new TextControl("Name Goes Here");
new TextBinder(textCtrl1, personObject, nameField);
In Java, that second line gets tricky. When you are binding to a particular field, you HAVE to use reflection to find the setter and getter for that field of the personObject. In C# I think it should be easier.
Anyway, the binder should add itself as a listener to the control and the object, then forward changes back and forth.
Does that help any?
Edit2:
As you noticed, the hard part is noticing when your property is updated. Luckily, that is optional. More often than not, you don't need to update the component once the object is set (I had to deal with this a few times when I had distributed UIs that could update each other).
So, if you assume your object won't change, the "Binding" has to do the following:
get the value from the property and set it in the component.
add itself as a listener to the component.
store the property/object (if you can manipulate properties, you're set here. If not, you need to store the object and property name, and use reflection)
bail and wait for an "updated" event from your component.
When you get the update from your component:
- store the value in the property.
- You may want to set an "Updated" flag or store the original so that if you iterate through all the binding components, you can tell if any updates need to be saved/enable the "ok" button.
Your object should always be pretty much up-to-date now.
As you build a form, you may want to put all your binding controls into a collection so that you can do a few other operations...
A "Save" operation could call each binding control and tell it to copy from the control to the property, that way you don't need to use a listener.
A "Reset" operation can reset all the controls to their original value.
A "Test" operation can ask each control if it's been updated.
. etc
The neat thing about doing it this way is that every "Operation" you wish to add is pretty trivial to add, but automatically affects the entire UI.
You probably also want a little object hierarchy of controls with an abstract base "bind" class, then a specific binder for each type of control (text field, number field, date, spinner, table, pulldown)--I think that's about it.
This can be very simple, but gains complexity rapidly. Try it with a text field and see what you can do. A simple text binding object should just be like 5 lines of code if you can pass "properties" around in C#...
Okay, totally separate answer. As I told you, I'm not very up-to-date with C# technologies, but from what I've heard, LINQ may do this entire job for you.
In fact, LINQ may be made to do exactly what you are trying to do. It doesn't exist in Java, so that's why I gave you the "Manual" version in the other answer.
The comment at the bottom of this page: http://msdn.microsoft.com/en-us/library/z919e8tw.aspx alludes to a better way.
I was watching a tutorial on Rails and was very impressed that you could so easily create an editing system for a class just by defining it.
Can this be done in ASP.NET?
I know there are ORMs out there, but do they come with an editing system?
To explain what I mean by an editing system, consider a class for defining people
class Person
{
string First_Name;
string Last_Name
}
And then perhaps with one bold stroke something like this:
CreateEditAbleClass(Person)
You would get the functionality below in a browser:
http://www.yart.com.au/images/orm_editor.jpg
And this functionality would extend to all the UML definitions – inheritance, association, aggregation etc. In addition, there would be a simple way of adding customisable validation and so forth.
I currently use DataGrids and a lot of manual coding to achieve these results.
You can do it with reflection. Using reflection, you can enumerate over the members of a class, and therefore create a form to edit the members.
Creating the code for rendering the web form based on the members of the class is a bit more code then I'm willing to type out here, but if you look into reflection you should be able to come up with your own solution in a couple hours.
Sure. This is off the top of my head, but I believe you could connect your class to an ObjectDataSource component which would in turn connect to a DetailsView control. So it's a hair more work, but it would be pretty trivial to have a method that created the needed items on the fly and bound them together.
This is called "Scaffolding".
It really depends on what you are using for your data layer or ORM. Entityspaces, for example, comes with a scaffolding generator.
Absolutely! Scaffolding in Ruby is known as Dynamic Data in ASP.NET. Scott Hanselman speaks to Dynamic Data here.
There's a screen cast from Scott Hunter that shows it off here. It's of note that it's pretty new (still in beta).
You can for simple sites/purposes but it quickly breaks down when you want to do something more complex. Like what happens if you don't want certain fields to be visible, what happens if you have a relationship to a subset of a certain class etc.
Having been down this path before I'm guessing you came at the issue by realizing that:
You spend alot of time creating similar forms/lists etc for similar entities.
You want to minimize this time and are considering if your forms can be automatically generated.
Basically, if you want it to be done automatically then you'll end up creating an overcomplicated system that does half of what you want and actually takes longer to implement.
If however, you want to drastically cut the amount of time doing and maintaining writing repetitive gui code then then I suggest using a declarative style form builder and table builder (like the form builder in ROR).
This lets you quickly create forms/tables without repeating yourself any more than necessary and also gives you the flexibility that you need for complex scenarios.