I currently have 5 ViewPart-s which show similar data but in various ways, using jit visualisation. I want to combine them into one class with parameters.
From my IPerspectiveFactory I'm adding these selectively, e.g. just first 2 views.
My question is, how can I instantiate the same view with different parameters(like parametrized constructor). Later I'll be adding them with secondary id..
There is no way to pass parameters to a view.
I would suggest using a base class containing most of the common view code and then a class derived from that for each of the different views.
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'm having a design problem inside my Zend app and I don't really see where I should plug this feature to have a design integrated correctly inside Zend Framework.
What I want is to displayed inside every public page of my app some stats like the count of entries in the database (like the number of users). I need to have a dedicated function to do this computation since I want to cache its result.
I've to add that part of my actions are acting as JSON REST ressources (for AJAX purposes) while others behave like common HTML dynamic pages (thus setting an object in all views object isn't perfect).
I'm thinking about the following solutions :
Adding a controller plugin that would be setting an object containing my stats values inside the Zend_Registry, this plugin would handle the cache
Adding inside my models a function enabling the computation of those stats. This would imply that the feature would be exploded over all my models (which is not really a clean design), these models will cached some values (which is not their job TMHO) and this will make these computations trigger by the view (I usually let the controller load the value inside the view)
Does anyone has any suggestions or comments about a cleaner solution ?
My criterions are :
Integration in Zend Framework design philosophy
Respect of model integrity (a cache value means an inexact value)
Avoiding of workarounds like using static ressources like Zend_Registry
I would do it this with a view helper and a cron job.
Create relevant model classes that do to the computation
Create a service class with two methods:
A method that calculates the results by using the model classes and caches them.
A method that returns the cached results.
Create a view helper that uses the service class to get the results.
Set up a cron job that uses a cli script to call method 2.1 every 15 mins or however frequently you need it.
I have a bunch of model objects that inherit from NSObject (Result). And I have a bunch of view objects that inherit from UIView (ResultView). They exist in a 1:1 relationship (one model for one view). In my controller I have an two arrays: one for Result objects and one for ResultView objects. The controller displays many of these result views and they can be added/deleted/reordered. Trying to keep 2 arrays in sync (results & resultViews) isn't working out. How should I approach this problem?
I'm considering initializing a view object with a model object (eg: an initWithResult: in my ResultView class and then retain a pointer to the Result object in the ResultView). Then I could do something like ResultView.result to access model data. Is there a better solution? This would break MVC, wouldn't it?
Unless you're trying to persist these model objects in a DB or something similar, I would put a view property on the model objects. If you don't have to create the view for any reason, then just nil it out to save on memory.
Does it break MVC? I guess. But if your model objects will always have a view associated with them, it starts to go into the blurry line area. No programming god will send you to hell for breaking the standard a little bit.
Do what's clean, optimal, and easiest for another programmer to understand when looking at your code.
Ok, if I understand your question correctly, the model objects are persistent while the views are dynamically created/deleted. You are relying implicitly on the index of the two arrays to achieve the mapping of two parts. One simple way is to add a "model object id" in your view class. Then you can easily reference to the correct model object in the view.
I'm using DataAnnotations for validation of a custom class (LINQ to SQL auto generated) using the MetadataType tag on top of the class. I'm loving DataAnnotations and it works well in simple, common scenarios. E.g.
[MetadataType(typeof(Person_Validation))]
public class Person
But what if you need to have two different sets of validation rules applied to the class in different scenarios???
My situation: Some fields are mandatory on the www public-facing site, but not mandatory on the internal admin site. But both sites have a View which "Creates New" of the same object/class.
This is where it becomes DataAnnotations HELL surfaces..
I've tried using two different ViewModels with different validation applied to each of them, two classes that inherit from Person with different validation applied to each of them. But all roads seem to conflict with DRY principals and you end up somewhere along the line having the totally respecify all properties for the underlying class structure. You don't have to do this when you just have one validation rule set. So it very quickly becomes hell and not practical for complex objects.
Is this possible using DataAnnotations and what is the best DRY architecture?
Not sure what you mean by 'virtually duplicate and manually set each and every property manually in the original underlying class'. I've never liked the idea of buddy classes, and would personally recommend different view models for Admin and Public site (with appropriate validation set on each), and then mapping between the models using AutoMapper.
UPDATE:
Regading Automapper, the basic usage is something like this:
First you have to define your mappings. This lets automapper figure out in advance how to map objects. You only need to do this once in the application, so a good place to do this in an ASP.NET app is in Application_Start() in Global.asax. For each pair of classes you want to map between, call: Mapper.CreateMap<SourceType, DestinationType>();
Then, in your application code to do the map you just use:
var destinationObject = Mapper.Map<SourceType, DestinationType>(sourceOjbect);
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.