I've got a wizard control that databound controls on each step. I can't databind them all at once because they are dependent on the previous step. So, essentially what I've got at each step is a save to the database of the previous step, and an initialization of the current step.
Are there any recommendations as to how best to organize my code? It works, but it's not very readable, and extremely brittle.
EDIT: I should add that I've seen most of the wizard control tutorials out there, but none of them seem to address what I'm trying to do. In particular, the need to save and retrieve data between steps, and how to keep it from retrieving that same data again if the step is revisited.
What you've done sounds reasonable.. Can you be more specific about the problem you are having?
One thing about the wizard control, as your workflow gets more and more complex I think the coupling between your workflow state and the wizard SelectedViewIndex becomes problematic. For this reason I eventually separate them. I will usually use a state/statemachine pattern, where the current workflow state is used to determine the appropriate wizard view index (but not vice-versa).
If you're looking for examples on how to implement a state machine, I have a test app out there that walks through dialogs like a wizard control, except using javascript. Check out http://main(dot)test.wishpot.com/WaveDataCollection.Frank/, after you get to the page CollectSamples.aspx, go ahead and view source, then start reviewing at the GotoState function.
State machines are plumbed a bit different in C#, the main difference being the state object is an abstract class with a fixed number of event handlers, which each state inheriting from that class implementing each handler (some perhaps throwing an exception). With javascript we don't need the abstract state class... Also, doing this serverside, you're going to need to be able to map from a state ID stored in your database to a state class.
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.
From either a high-level perspective, or a low level and very specific one, what is the best way to constantly poll a database for updates?
I would like to create a "live" application which, using ajax, displays the most current data. I have partial views which Ajax.ActionLink the correct data in, but only OnClick of that generated link.
Is using a trigger and some sort of application code the best way to do this? For example, a trigger on all tables, which sets some field as "changes have been made since last read"?
Or is it better to use a function to poll the database on an interval to check for changes (I for-see this possibly being taxing with all the constant chatter to the DB)?
Or is a combination of these 2 approaches best? Or is there something I am leaving out completely?
SignalR was designed to solve exactly this problem.
Is there a list somewhere that lays out all of the types of changes that can be made to an existing workflow service that would prevent existing instances of the original workflow from being re-loaded? For example, I recently made a small change to a custom activity (changed a condition in an "if" statement) and all existing workflow instances still load as normal. Now, in the past, I had removed a property on an object that the workflow uses, and when I tried to re-load a persisted workflow instance, it blew up on me.
Does such a list exist? Thanks!
As far as I am aware there isn't a list like that. You really should consider all changes as breaking. If you test thoroughly you will find a few exceptions but these will be mostly changing a single VB expression.
There is no such a list.
As far as I am concerned, you can change VB expressions always editing the .xamlx in a text editor. I say that, because in my case, sometimes the graphical editor (VS2010) changed the ids of the activities without introducing new activities (be carefull with this).
You can also change the whole internal code (not the inputs/outputs parameters) in code activities (.xaml). Because of that, it would be a good idea to put all the "high changeable" logic into code activities in order to be able to modify this logic avoiding problems with existing WF instances.
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?