I want to pass data to views, and I've two options in my mind (if you know a better approach, please mention).
I am using Zend_Based ORM system, and coded in a way that if I add a new field in database, its automatically available within the model.
1st: I convert the model's data into array and pass the array to the view. This way I will have all the data available within the view, but model's function/operations will not be available. And incase I need specific functionality, i will be coding view helpers while there are chances that the same functionality is already coded within model. e.g. a getting a date in specific format.
2nd: Or I pass the complete model object to the view, this way I will have all the model's functions available, but view will be able to access model's save function which is a bad thing. I can add some more functionality within model to make it read-only, but it will be extra work.
any suggestions which approach is better.
According to the MVC principle it's perfectly fine to let the View allow access to the Model. So, pass the complete Model to the View.
By the way, passing arrays around will copy your data (by value), while passing objects around will not (by reference). (Assuming PHP5). Large arrays might affect your performance.
Related
I am using inheritance currently in EF and feel like it is causing more issues than it is helping, especially with binding an aggregation of tables to a datagrid. I have given a screen of part of the model. What I am trying to do is bind FREQUENCY to a datagrid, and have the grid fields be based on the type of FREQ_POOL(which is a base class). So for instance, if I want a POOL_IA datagrid, then it would have those fields, as well as the few fields in FREQUENCY. I was using inheritance because it made since from an OO perspective. The alternative is to just have lots of 0..1 relationships that show the ability for FREQ_POOL to have an extension, but then I have no constraint in place saying that FREQ_POOL can only be ONE type. What is a better design to accomplish this and make data binding easier? Thank you for any guidance.
One approach may be creating a data grid that gets the data from FREQ_POOL and then put all the variables of POOL_IA (or the all the properties of derived class using reflection) and FREQUENCY .
If you really don't need using objects while binding your data grid and able to use DataSet the another approach may be getting all the properties and the values of entry with Context.Entry method on the fly and put it into DataSet dynamically.
I have recently added some fields for auditing purposes to existing models in an MVC 4/ Entity project. I don't need these fields to be displayed on the edit page. However, they are required fields on the model.
As it stands, the edit page still works, but on the controller side, the ModelState.IsValid check fails because the required fields that are actually set on the item are not output to the view and therefore not re-submitted when the edit page is submitted.
Is there an easy, built in way to rectify this, or if not, which of the following is best practice for this scenario? Are there more options?
1) Set up hidden fields on the view to hold the information (Not a fan of this option, passes data around too much)
2) in the controller, on submit, first load the model by ID, then set each individual parameter based on the fields present on the view (Seems like extra unnecessary work)
3) Create a constructor for the model that takes itself as a parameter and pulls any non-default values and returns a new object. Basically a merge. (Best I think, still a lot of extra work)
4) ???
Best practice is to not use your domain model inside the views. Create a view model class that contains only the id and the fields you want in the view. Pass this model to your view. Change the parameter type of the form submit action to match your new view model. This will then pass the model validation without using hidden fields. In your action method, you can then retrieve the object from the database using the id property of the view model class and update fields as required.
Hope that makes sense.
I prefer to do the 2nd option as long as I can get the existing object with a single query or db call. This lets me to keep my view clean(no hidden fields for all those other properties) and use the existing update method which updates the domain model.
Look into your code. If the update method is making updates in lot of other places(many other tables) which is really not needed, then you could possibly write a short version of the update method which updates only the relevant parts ( ex: UpdateContactDetails).
I think that I am using too much conditionals and calculations in the TT templates.
I am displaying a result set of items from DBIc. For each item I need to calculate things using the retrieved values, and the template doesn't seems to be the right place.
But in Catalyst it is a thick object that comes from DBIc.
So how can I move logic to the model? Must I run a whole loop for all items and change the object somehow?
Regards:
Migue,
First, you're on the right track by wanting to properly separate concerns. You'll thank yourself if you're the maintainer 6-12 months down the road.
IMHO, your Catalyst controllers should be as thin as possible with the business logic in the various models. This makes it easier to test because you don't have the overhead of Catalyst to deal with. I've been thinking about model separation quite a bit myself. There are two schools of thought I've come across:
1) Make your DBIx::Class Result classes have the business logic. This approach is convenient and simple.
2) Make a standalone Model which is instantiated by the Controller, and which has a DBIx::Class schema object. The model would use the DBIC schema to query the database, and then use the resulting data in its own business logic methods. This approach might be better if you have a lot of business logic since you separate DB access from business logic.
Personally, I've historically used approach #1 but I'm leaning towards #2 for larger apps.
Two possibilities.
Create a method in corresponding schema class.
(if 1 is not possible) Pass a callback to template that would have this object as argument.
You could
create a resultset that retrieves the data from the database and then calculates the needed values
if possible calculate the needed values within the database and then only retrieve the data needed for output
I personally would prefer the second one.
I hope that helps.
How do I retain the values after switching to another view and returning back to the same view?
Is there a way to retain the array even after the view disappears?
My Array shows the values in console first time, but second time when it returns from other view the array shows (null)
EDIT:
I am using this array to use it into my core-plot.
This array contains the plot points for the core-plot
Generally speaking you have a few options to maintain data persistence between views. In no particular order:
Pass the array back and forth between the views. This involves creating a property on each view and setting it. You can use properties directly but you might have an easier time using NSNotifications to pass the data around.
Store the data in Core Data, loading lazily as needed. This is the most powerful option and may be a bit much. Core Data is not the correct way to "pass data between views", but often may be what you need. As an added bonus, your data stays saved across app launches.
Store the data in your delegate. This is similar to using NSNotofications. All of your objects can access the delegate more easily than passing references to each other all over the place.
Store the array in NSUserDefaults, assuming your data is compatible. This is similar to Core Data in that it offers persistence, but is much more "lightweight" and less powerful. Note that some objects are incompatible with NSUserDefaults.
Edit:
For storing an array of points, I would serialize it into either Core Data or NSUserDefaults, depending on how the user interacts with the data and how much data there actually is. If the points change often and there are many of them, look into Core Data. Although, you can do just fine with an array in NSUserDefaults. You just end up doing more array manipulation.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.