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
Related
Lets try this explanation again...
I'm new to polymer (and getting back into web dev after a relatively long absence), and I'm wondering what the recommended approach might be to more closely manage object state while employing 2 way databinding. I am currently consuming rest API (json) objects. My question is if polymer keeps a copy of the original object before initiating updates to the bound object's properties/attributes...so one might be able to easily undo the changes? While allowing 2 way databinding to work its magic is often desired, there are cases where I'd like to prevent / delay changes to the object / DOM until the user approves the changes (say via the paper-dialog component for instance). I suppose one could make a temporary copy of the object and bind fields to that version, and then only persist the changes back to the source object upon user approval. In any case, I'd be interested to hear thoughts and see an example or two of recommended approaches (especially if I am off-track with my ideas!)
I suppose one could make a temporary copy of the object and bind
fields to that version, and then only persist the changes back to the
source object upon user approval
This.
Consider that view-models are essentially different from pure data-models (sometimes called business-data). Frequently, the differences are irrelevant and one can use them interchangeably. However, be aware of scenarios where the view-model is distinct (uncommitted user edits are a good example).
The notion of a field editor that requires approval from the user is purely UI/View oriented. Whatever data is managed in that modality is purely in the domain of the view, and fetches/commits to the business-data should be discrete.
This is a really basic design question, but I can't seem to find an answer. I'll use a really simple example, but my concern is for cases where the model-level calculations, "2+2" in this example, become complex.
Let's say I'm designing an application to run in Zope or Plone; its job is to add two numbers. Dexterity lets me easily create a content type with fields addend1 and addend2, and will generate add, edit, display forms for me. I could modify the display form to also present a field named "sum," but "sum" is a result of extensive calculation in my model, and I don't want to present it in the "add" or "edit" forms because I don't need that as input, just as a result of calculation. I don't want to calculate it in my view, because it's expensive, I'd like to reuse it after initially calculating it, and I don't want my "view" to need any knowledge of how I do my calculations anyway.
So what is the proper "zca"ish approach for doing model-work that has nothing whatsoever to do with presentation of results? Do I create an interface like ISum and create an adapter that converts my content type to one including a sum, then do a view for the ISum interface? If not that, what? Searching PP4D and the Zope 3 Developers Handbook hasn't helped.
Thanks in advance for any insights.
Use events; you can register event handlers for when your content type is added, or edited, and you set the value on the object whenever these events trigger your handler.
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.
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'm currently working on a reasonably complicated data input form, based around ASP.NET Web Forms. After the form has been completed, we'd like to offer a chance for the user to review their input before actually submitting the form (as well as going back to make changes to their data if requried).
Due to the large number of fields, I wanted to use a FormView control due to it's automatic databinding ability, removing a lot of tedious code, however there doesn't seem to be a simple way to offer this functionality.
At the moment, my current approach uses an ObjectDataSource to bind all the form fields. I've created two 'modes' of operation on the data source; one mode temporarily saves the object to the user Session (allowing retrieval again later for read-only/edit modes - this facilitates the review/modification functionality), while the second mode actually does the database insertion.
While this seems reasonably robust at this point, it still feels quite dirty to me. I know I could use a Wizard/Multiview type approach, but then you lose out on the niceties of automatic databinding (I believe?). I'm sure this is a fairly common problem, so how is this typically done in a Web Form environment?
Thanks!
The project I am currently work on uses a custom wizard setup (not the asp.net 2.0 wizards). It comprises of the several steps your wizard may require, and when you go from one step to the next, the code saves the values into a final step (a read-only review). When the user gets to that last step, they can go back to the step that needs to be updated. When happy, the user submits the wizard, and the data is saved to the db. It is basically a series of panels that have their visibility toggled.
You should be able to still use the ObjectDataSource for each of the editable fields, having the panel or mutliview being visible or not shouldn't affect the binding. When you go from one panel to the next, you can update a read-only step (like I said before) while keeping the editable controls bound to the ObjectDataSource. When you go back to any steps that need to be modified, you are still bound, so when you make any changes and click submit or whatever the button is, it should use the ObjectDataSource.
Anyone else have any other ideas?