I am working on MVC3. not sure whether its the right question but it keeps on bothering me always.
I have a generic model used by multiple views. If i make any changes to the model variables for example name change it does not reflect in any of the views nor does it throw any compile time errors. The errors are thrown only at run time.
This can cause a serious issue if model changes are not checked for in each view manually.
Is there any way to overcome this manual changes in the view?
There are two things that can help. The first is T4MVC, although this is really more about making your helpers more compile-time safe. This won't, by itself help. If you also follow these instructions then it will also compile your views and catch most of these errors.
Be aware, however, compiling views can significantly slow the build process.
nope... that is something you must be aware of, when "fixing" your model.
as the model gets evaluated at runtime, just like ViewBag and ViewData, you will have to update changes manually.
i guess you could update the changes with a nice "Search and Replace" though
Related
I am new in MVC , I am trying to view data without using model, and passing datatable to view, I am able to achive this but when searched for this thing many people saying it not good prctice.
So I would like to know reason behind this. if anyone knows please share.
there are a number of reasons for this, the most obvious being that in MVC good practice is to send to the view the data it needs, preferably already formatted, and nothing more. Datatables will contain more information then the view needs and the data won't be in the right format for the view.
When your data changes, your view will need to change to accommodate that and that's never a good thing. You're better off dealing with such changes in one place, in the back-end. Multiple views might use that code, so you're killing multiple birds with one stone if you apply proper separation of concerns.
Also, if you prepare your view-models in the back-end, you can test your code and will catch bugs quickly and early in your development process which, when done right, leads to better quality code. You can then hook up a proper CI/CD pipeline and automate all this, thus making your life a lot easier.
If you have a bunch of razor code on the front-end, errors there will not be visible until you look at the view directly which is never a good thing. You may not catch certain types of issues until you manually test each view.
I am using delphi xe2 (fully updated) and Express QuantumGridSuite 13.2.2 . I've much columns on grid and i set RepositoryItem for some columns. EditREpository component is on another form. Some times that columns repositoryItem property is clearing randomly. I think that something is triggering that but i couldn't found what is this about and how is that do?
Tnks for your helps.
This problem of component values becoming "lost" at design time is a known phenomenon, even with EMBA's own components. Usually, it manifests itself when forms are first opened in the IDE.
In my experience, ymmv, it nearly always happens with a property of some component of form A which references a component on form B, and it seems to happen more frequently if form A is opened in the IDE before form B.
Anyway, there are things you can do to try and identify the problem and at least one work-around you can use until you do. But, before you start, the very first thing to do, if you haven't already, is to ask Devex whether they know about the problem. No disrespect to the readership here but they are more likely to know, and it may turn out that you've missed a maintenance update that fixed it.
When I've had it happen with components I've written myself, usually it has been caused by some error in my coding of the component's initialization and/or property setters. In my own components' cases, I've always been lucky in that although at first the behaviour seems random, in fact there has turned to be a specific sequence of actions in the IDE that triggers it. If you can identify a reproducible sequence of actions, you're 90% of the way to getting the problem fixed.
The best place to start is to make a reference back-up of your code in its pre-problem state. Then try out various sequences of actions in the IDE, rolling back to your reference in between, until you find one that provokes the problem. If this sounds tedious, it is, but you may get lucky and spot a pattern early on. If you don't, then keep reminding yourself that the problem only seems random because you haven't spotted the pattern yet.
However, I have the impression (though no proof) that another misbehaving component can disturb the setting of the properties of the component which is losing the value. So, one thing to look at is what other components are on the same form as your affected one. Not all have the same pedigree as the Quantum Grid and its siblings from Devex.
Things I've found effective to isolate the problem with components I've written myself are:
Removing all the other components from the form.
Seeing if I can find reproducible sequences of actions (e.g. what order forms are opened in) that trigger the problem.
Editing the DFM so that the affected component appears last in it. Ditto, first.
Running the IDE in another instance of itself. The main initial reason to do this see if you, or rather the debugger, can unmask a normally-silent exception occurring in some design-time component code that may be involved on the loss of the property value.
Devex's Quantum Grid is widely used (I do myself), has a long lineage and their code is usually top quality. Although I don't imagine it's perfect, I would start by assuming that the problem is caused by something else.
As you may have noticed, one of the most troublesome things about this problem is that if the component is on a rarely-used form, often the first you hear of it is when a user reports it.
Anyway, with all that said, if you can come up with a reproducible test case involving only Devex components and the standard ones, that can be submitted to them for investigation, I'm sure it won't take them long to find and fix the problem. And I'm sure they will fix it if it's in their own code (I wish the same were true of EMBA themselves).
However, without a reproducible test case, I think the best you can hope to do is to add explicit code to your form's creation to set the component value at run-time, e.g. when the form is first created. With my own problem components, once or twice I've found that careful tracing into the code I've added to do this has led me to the cause of the problem.
When I make changes to controller methods, models/view models, I get the prompt to propagate the changes throughout the code base. This is working as intended for C# code. But my views are not updated too, so I end up having to chase down everything manually, which can be a pill with a lot of partials.
Is there something I can do to ease this process (other than not making changes)? I do have Resharper.
The answer is no.
That is normal functioning. The Views must be modified manually.
One thing that will help is to use ReSharper's Find Code Issues. It will point out all views that aren't compiling properly, so at least you will know what Views to look in.
This is a question being asked out of curiosity, not because there's a problem I've encountered that I can't solve.
In MVC3 (and probably earlier versions, too) I frequently encounter problems using #Html.Hidden and #Html.HiddenFor, all of which derive from the "behind the scenes" caching that the helper methods utilize. For those not familiar with it, re-executing a partial view that uses those helpers will grab values from a cache, even if you supply new values to the method call. I'm not too clear on just when that happens, but I know it does, and have seen it documented as an issue to be aware of online.
I'm wondering what the value of this caching is. At least in the way I use hidden fields, the values are different on every view execution. Given that usage pattern, the caching gets in the way more frequently than it helps.
In what kinds of scenarios does the caching add value?
What I need is a way inside a Factory.define block to know if the factory has been called using create or build, either explicitly or simply using the default strategy.
I have a factory that has to manually adjust associations that the original author of the code took so far off the rails that normal creation barfs and normal build can be managed. I don't want to adjust those associations in the build case, but I have to in the create case.
I've been looking to see if there is something analogous to 'current_strategy' but I haven't seen anything yet. I know I can distinguish using after_create vs. after_build, but the original author made it so that the act of saving the object without doing the adjustments causes massive unhappiness--save exceptions and garbage in the database.
I currently have no mandate to fix the "models" he wrote and the existing rspec tests use the differentiation to do the right thing at any time. In every case the prior test author(s) have opted to simply never use create, which means setting up most of the test data is an arcane and lengthy process.
Any help would be deeply appreciated--I'm still exercising my GoogleFu but would love to be short circuited...
Oh, this is in Rails 2 (/cry)
thanks!
This sounds like a very strange problem indeed, but since you say that you're cleaning up someone else's code, I'll assume there's no easy way out of this.
I wouldn't approach this from the factory side. The factory shouldn't care because the model (not the factory) is supposed to be the gatekeeper of validity in terms of object structure and associations.
I would write specs that separately create and build objects, and test their associations to make sure they are correct (according to what you want the new behavior to ultimately be). Then, get those specs to pass by refactoring the models to do what you actually need them to do. This is how you clean up legacy code, and alter its behavior - write tests that will pass when the new functionality is correct, and refactor until they pass, making incremental changes with each test/refactoring.
When your new specs are passing, you're well on your way. If the previous author put in specs of their own that verify the previous behavior, then you'll have to work on figuring out which, if any, of those tests are currently valid (many of them may be, since they represent the requirements that the app currently fulfils), and removing ones that aren't.