I didn't really know how to phrase the title of my questions, so my apologies in advance. I read through parts of the MEF documentation to try to find the answer to my question, but couldn't find it.
I'm using ImportMany to allow MEF to create multiple instances of a specific plugin. That plugin Imports several parts, and within calls to a specific instance, it wants these Imports to be singletons. However, what I don't want is for all instances of this plugin to use the same singleton.
For example, let's say my application ImportManys Blender appliances. Every time I ask for one, I want a different Blender. However, each Blender Imports a ControlPanel. I want each Blender to have its own ControlPanel. To make things a little more interesting, each Blender can load BlendPrograms, which are also contained within their own assemblies, and MEF takes care of this loading. A BlendProgram might need to access the ControlPanel to get the speed, but I want to ensure that it is accessing the correct ControlPanel (i.e. the one that is associated with the Blender that is associated with the program!)
This diagram might clear things up a little bit:
As the note shows, I believe that the confusion could come from an inherently-poor design. The BlendProgram shouldn't touch the ControlPanel directly, and instead perhaps the BlendProgram should get the speed via the Blender, which will then delegate the request to its ControlPanel.
If this is the case, then I assume the BlendProgram needs to have a reference to a specific Blender. In order to do this, is the right way to leverage MEF and use an ImportingConstructor for BlendProgram, i.e.
[ImportingConstructor]
public class BlendProgram : IBlendProgram
{
public BlendProgram( Blender blender) {}
}
And if this is the case, how do I know that MEF will use the intended Blender plugin?
You should break it as mentioned. Expose your control panel through your blender as you say. If you really want to keep your current design, you'll have to decorate the import with metadata and make a custom export provider that will use this metadata to determine what export it should use. If you can get rid of this extra step, do it.
Related
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 having a little bit of a hard time getting into mvvm. I'm writing a simple app, Notebook. I have one viewmodel, it's name is actually ViewModel. It has an ObservableCollection of Notes inside and methods to save and load those from Isolated Storage. My only Model is Note.cs, it implements INotifyPropertyChanged and I'm of course RaisingPropertyChanged.
I've also got two view, both of them are user controls. One to display list of notes and one to edit the one chosen from the list.
My questions are:
Where do I create an instance of my vievmodel?
How should I implement going from the page with list of notes to the page with detailed view after choosing one Note to edit? At the
moment I'm saving the index of Note in App.xaml.cs, going to the next page and setting
the DetailedView DataContext to the right Note in OnNavigatedTo, but
I don't think it's actually the perfect solution.
Where should I save my Notes? I guess Application_Closing in App.xaml.cs is the right place to do it, but I'd have to have my viewmodel as a global object there, is this the right approach?
Additional question:
I have to add possibility to group notes. I guess that class Group with dictionary (GroupName, howManyNotes) is going to be allright since I don't have to be able to for example write all notes from selected group. Do you think there's a better approach I should think about?
Thanks for respones,
Michał.
I would suggest you take a look at Calibrun.Micro which is a great framework for MVVM. You can get some sample from the CodePlex.
I have used that in a bunch of Project, and will give you flexibility in case if your project grows in size.
Google for Caliburn.Micro sample and you will find a number of sample for all technologies like WPF, Silverlight, Windows Store, Windows Mobile.
Caliburn.Micro CodePlex
Is there any tool out there (perhaps the GWT compiler itself can be used as a standalone app) for generating individual images from the *.cache.png files created during compilation?
Or, is the mapping information (for sprite geometries) available via an API?
I looked up information on the GWT repository, the documentation, here on StackOverflow, and possibly every google group on the subject, to no avail.
Motivation
My aim is to provide easy means of white-labeling a web application by instructing the GWT compiler to avoid inlining of bundled images (using <set-property name="ClientBundle.enableInlining" value="false" />), thus forcing the use of sprite images on every user agent, than building a WAR and passing it on to a graphics designer to only edit the image assets within the packed WAR (hoping to make it a little bit easier on him/she by providing such a tool).
The designer would than use the provided tool to disassemble and reassemble the sprite image, for convenient editing.
Illustration
Hmm, that's not an easy one (really, it'd much simpler to just recompile the app after the designer has done his homework), but there's no reason you couldn't do it.
First, you can ask the GWT compiler to output the generated classes to disk (using the -gen argument). You'll find there the implementation(s) for your ClientBundle, with all the ImageResource methods returning instances of ImageResourcePrototype. IIRC, you should be able to compile those classes and use them to grab the region for each sprite, and therefore extract the individual images from the bundle, and repackage them back.
I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.
What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?
edit
I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
Short answer: Yes, you have to add them.
Long answer: You can create custom code to do this, but I doubt it's worth the effort.
With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.
With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.
With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).
You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.
If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.
One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).
I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).
Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.
There are a million ways to build a house, but most people wouldn’t
consider building toilets, bathtubs, and glass windows from scratch.
Why build a toilet yourself when you can buy one for less money than
it would cost you to construct it, and when it’s unlikely you’ll
produce a better one than you can get in a shop? In the same fashion,
most software engineers try to reuse software modules. “Make or buy”
decisions encompass more than whether a module is available;
generally, reusing software modules is cheaper and leads to more
robust systems. Reusing software also means you don’t have to code the
same functionality over and over again.(wicket in action:manning)
So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.
I'm about to start a Web application that will use interactive generated 3D content. Aim is to let it run natively in the browser, i.e. no Flash is allowed, only JavaScript + HTML5.
Apart from using pure WebGL it's better to use a lib that will offer a more high level interface.
The approach of X3DOM looks great for me - and it looks like it's supposed to become native in the browser and the lib will pave the road.
But after my first impressions I'm not sure if it's lightweight enough. Apart from the 400kb JS-File it slows down Firefox.
The features I need are not many. The whole scene set up could be easily done by "hand". But I need user interaction including to figure out where the user clicks. And later I want to be able to load and insert 3D objects in a common file format.
PS: Browsers of choice are Firefox and Webkit based ones. Desktop and Mobile ones. I don't care about IE.
PPS: Yes, I know the question: WebGL Framework
X3DOM is great when you come from an X3D background (and developed by great people), but if you have no preference watsoever, Three.JS would be my pick.
I looked at most WebGL frameworks just last week, and it indeed seems almost every one of them is in the 300kB range. That's too heavy for me, too. Luckily I found lightgl.js which has everything you need to get started in 28kB, MIT license.
The main thing for me is just abstracting canvas, shader and texture initialization. But lightgl.js does also have some mouse handling and model loading etc.
i think the decision boils down to:
do you want to have a more design or programmer approach.
x3dom: its leveraging of x3d for describing the scene lends itself to a more designer approach, with just the adding of the x3dom css and js one can do this :
<X3D><Scene><Shape><Box/></Shape</Scene></X3d>
three.js: only allows for scene generation through javascript, and a lot of additional code is necessary just to set up the canvas. view the source of this simple box example: http://stemkoski.github.com/Three.js/Template.html
neither way is wrong, i prefer designing the scene and then using js when needed for any computations.