I have a windows form with a label on it. I want to set the labels value at runtime depending on which assembly is inside a directory. I am not sure which code goes where:
UI Form has a label.
2 class libraries that implement an interface.
Should I have another class that does the MEF composition work and do I need to call that in the constructor of the UI Form.
If I need to call it at the forms constructor and I have many forms, does this mean I have to call it in very form.
I am using MEF for the first time in a WPF application I'm developing and what you describe above is about how I managed my MEF modules.
Below is a summary of what I have done:
Create a separate class for MEF composition. I named mine Modules. This class should do all of the MEF composition. You can either do the composition when the object is created or make a method for it. (Modules.DoComposition())
I create an instance of this Modules class in the constructor of my main UI window. Composition will be done at this time. (Create in the ViewModel if you are using MVVM design pattern.)
I pass a reference to my Modules object in the constructor of any additional form that needs access to it. That way all forms will have access to your Modules object without needing to do composition again.
Related
I've been tasked with developing a custom quiz module that functions exactly like the core quiz module but with some UI modifications. The issue is that our users still need to use the core quiz module as well.
Is there a way to create a new activity that inherits all of the quiz module?
Or alternatively, is there a way to conditionally override the quiz renderer based on a custom quiz setting that can be changed in the core quiz settings?
Thanks ahead of time.
You cannot extend the whole module, however, what you can do is copy quiz module in your custom folder and make all classes extend mod/quiz classes. Rename all requires too to point to your module. Don't forget to put dependency in version.php file
I have a UI application which contains a dialog allowing to edit/create an entity. However create/edit classes share much code. What's the best names you can suggest for the base class?
What is the correct way to open a modal dialog in WPF using the latest version of the MVVM Light framework. I also want to be able to pass values to the ViewModel of the window used as the modal dialog.
I cannot find any samples on the MVVM Light site.
You should use the DialogService which abstracts the visual representation of the view so that you can do "Show" within the view model (and later possibly/hopefully) mock it for testing.
More info on the DialogService here.
-edit- I was wrong, as Alan Rutter (OP) points out the IDialogService is only for simple message boxes. I don't think MVVM light will help you much here but you can build a similar service (e.g. ICustomDialogService?). Custom dialogs can register as available with the service, and then the interface provides calls that will allow you to invoke a specific dialog by name (String or Enum perhaps) and pass any parameters you want.
Dialogs can register with the service in a few different ways - can happen for the type in static constructors (that you somehow have to force) or more explicitly through attributes in assemblies. Possibly even using class attributes. It depends on your startup sequence and general infrastructure.
I am new to this and still trying to get a feel for the best way to do things with MVVM. I can't find an answer with Google.
For convenience, I have created extensions on multiple custom classes, e.g.,
public static AppointmentLabel ToLabel(this textblockPatient tbp)
{
return tbp.appointmentlabel;
}
In my MVVM model, I have placed these extensions in the Model as they seem to convert one source of information into another. However, some of the custom classes are UserControls and live in the View. Doing it this way would require the Model to "know" something about the View, as the above textblockPatient is a UserControl.
How is this done within a MVVM pattern? Are extensions considered to be an exception to the pattern?
Thanks for any help.
In my opinion this is not a mvvm related thing. I would suggest that you put your extension classes near to the classes they extend. By doing it so you reach some level of cohesion. Sometimes it make sense to put the extensions in a seperate project. For example if you know you want need that extensions all the time and you want to have a small codebase or faster compile time.
I'm building a Zend-based Web app that will permit third-party extensions.
Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.
Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.
Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.
I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."
Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.
From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).
So two questions:
What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).
What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.
I'd implement the Visitor Pattern for this.
Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.
Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).
As for how to register it, check out the Zend_Application framework for defining resource plugins.