My question is about concept (I need some recommendation how to implement it right).
I've use MVC pattern when I build the UI,currently this UI serve two plug-in since the UI they should use are identical. so both plugin call to this UI and this is working fine.Now there is third(and four :)) plugins which should use some of the UI control and logic so instead of build new UI for this plugin's I want to provide some mechanism to enable to the user to decide which control he want to draw in the screen. so currently I need to break the view to sections but my question is what it the best way to do that ?
(from design and concept aspects)
The view is build from 6 controls that all the plugin must by default use two from them and the rest are optional . for example new plugin can use the mandatory two and provide in addition two more control.
Hard to answer without knowing the language and platform.
Each of your 6 controls you will have a view and controller. Each view/controller needs a reference to a model that exposes the data and methods appropriate for the view to display and the controller to call. So the question is how to connect up each plugin to the subset of the 6 possible controls.
In your case I would create 6 interfaces that expose the data and methods relevant to each of the 6 controls. Each plugin implements just the interfaces that are possible for that plugin. In addition it would expose a standard interface that all plugins implement. This standard interface would provide a list of the mandatory interfaces it requires shown, as well as the list of optional interfaces it allows to be shown.
Your master view then takes a plugin and asks for the list of mandatory interfaces. It creates those child controls and passed the relevant plugin interface to each of the child controls. It then looks at the optional ones are creates just two of them for display and hooks them up.
Hard to be more precise without more details.
You can try to use MVVM(Model,View,ViewModel) pattern, it's more convenient for shearing code, you can search in google 'MVVM', there are tons of articles about that.
Related
I am working on a silverlight project and I am using MEF to download xap file of other silverlight project and use its pages and functions in my main Project.
I can do the same thing using referencing dll of that project into my main project.
So I want to know what is the difference between using MEF to reusing components and Simply Adding Reference to the DLL of another project in current project? I mean that we also add reference to the project we import in our current project. Then how it is different from conventional form of component use?
Thanks,
First, we need to separate MEF and PRISM (since you used it in your tags).
MEF is primarily used to provide inversion of control (IoC). It makes it easy to manage dependencies your viewmodels and other classes to separate concerns and improve testability (amongst other benefits).
PRISM however is primarily designed for the following scenario: You don't know, what view goes into a specific container at compile time, and want ViewA for CustomerA, ViewB for CustomerB and so on. PRISM helps you to losely couple your regions and views in a way, so that the application can decide at runtime, what view will be displayed. Another scenario, is that administrators get one view, other users another etc. PRISM also has other features (like the event aggregator), but I'd say the former is the most important one.
Now, I'd say MEF is never a bad thing to use for a bigger project. But I'd only use PRISM, if you really need the functionality it provides, since it can be very limiting. If you don't, simply add the references as you explained and let MEF know about those assemblies with the AssemblyCatalog.
So for MEF, I'd suggest you learn about Depdendency Injection and IoC. I found this blogpost by Martin Fowler quite good. As for PRISM, get familiar with what it does, and decide if you really need it.
Hope this helps.
Let me complement Lue's answer on the difference between MEF and referencing dlls a bit:
The two things are orthogonal activities, meaning that if you reference a dll directly you might still want to use MEF to detect the types in it - and vice versa you might grab a specific type in a dll you dynamically loaded directly (without MEF).
MEF basically finds types in dlls according to certain criteria and has a bit of convenience stuff in it to automatically populate properties and collections with such types. It can be used to make a system more decoupled and thus more maintainable. For example, a video editing software may look for all types implementing a certain interface in all known dlls to use as filters. Whether you include the filters directly as a dll or let the user download them on demand: In both cases your application becomes slightly cleaner by using MEF, since there is no hard-coded list of filters anywhere. Still, in the presence of dynamic library loading MEF is especially useful.
Let's say that I'm building a social networking web site. Should I put the whole web site under SocialNetworking module should almost each page have its own module like ProfileModule, MessagingModule, and GalleryModule?
Or it is somethink differen like AvatarModule, UserToUserConnectionModule like FriendshipModule, PrivacyModule?
Modules are not containers of different "pages" of a website.
A module can literally be anything, but in most cases it provides "features" (services, listeners, events, classes, generally logic) for your application.
Don't separate modules thinking at them as separate URLs in your web application: instead, think of them about containers of reusable code.
As a rule of thumb, a Zend Framework 2 Module can be separated from the other functionality on your application if it provides logic that you may want to reuse in another project.
As you can see, it's all about producing reusable and decoupled portions of your application.
Just to add something to the good answer of #Ocramius, the examples you've given can ALL be modules.
You can have a "BlogModule". This module would handle BlogPosts. Then you could have an additional "CategoriesModule" that adds the option to give each BlogPost a Category. Then you could write another Module "MediaModule" that adds the functionality to attach Media to your BlogPosts
We write a lot of intrasite modules and are noticing that they really deviate now in SF 4+ from the content-based ones. So, on that note, I have some questions:
How do you get the EXACT look and feel of the standard modules for the edit/create form? For example, how do you eliminate the menu above, center the form, etc, as in, say, the Events module?
How do you add an actions menu dropdown to a radgrid, same as you'd see in the grids for standard modules?
How do you incorporate Sitefinity fields into the usercontrols? For example sf:ImageField throws script errors when added to a control? Also, is there documentation on each of these fields and how to configure?
---finally---
If we really want that standardization, do we have to go with another module type?
4.Is there a module type that will allow us to access non-sitefinity data (ie separaate db
but also provide us with exactly the same functionality and UI experience as the content-
based modules?
intra site modules are simply custom user controls (ascx) placed into backend pages to add your custom functionality to the backend. To copy the look and feel of the rest of the site, I literally copy and paste the HTML into the control.
I did a webinar on this a while back, including code to recreate the backend editor. It appears to still be valid, and is available here: http://www.sitefinity.com/blogs/joshmorales/posts/josh-morales-blog/2011/06/30/sitefinity_intra-site_module_webinar_notes
the centered view is a bit different, and I don't have that html, but you could potentially do the same (copy it from another native page). I don't always get it 100% accurate (my controls are usually laid out different from what Sitefinity does) but I get close enough so that it doesn't break the user experience.
The actions menu could be recreated with javascript, but if you are looking for NATIVE integration that does all this for you, indeed you would be looking at inheriting or much better yet: simply using the module builder, which lets you build custom types that automatically install themselves into Sitefinity as if they were regular modules.
Fields are definitely designed to run inside the context of native sitefinity module definitions (the classes that make up the UI using the Sitefinity context). This doesn't mean you can't include Sitefinity content in your modules; it simply means if you do you'll have to implement the integration yourself using the API.
On your last question, the only way to use external data but still keep the "Sitefinity Content" UI is to inherit from Content, then create a custom provider that reads from your database and translates it into the Sitefinity content type. It is certainly possible, but is quite a big project.
Unless you are in full need of this tight integration, I recommend simply going intra-site, linking to Sitefinity content types,taxonomy, etc through the API and manage it separately.
I hope this was helpful!
I'm looking into porting an existing enterprise app to iPad. One of the key requirements is that there is a basic functioning app that needs to be highly customizable/extensible. Also, the people working on the customizations and extensions are not part of the product team and do not have access to the base product's code (only interfaces, docs and the binaries). To achieve this, the current application uses a component based architecture where well defined components are used to compose the UI. For a given customer any of these components can be either extended and used instead of the out of the box ones or simply swapped with a new component that adheres to the interface.
Are there libraries in cocoa-touch that support a component model architecture ? (composing the app through a registry/configuration that can easily edited by others than the team developers)
Sebi
Perhaps you can create a root view controller and inject polymorphic children with: https://github.com/jasperblues/Typhoon
Is it possible to use RoutedCommands such as ApplicationCommand.Copy, ApplicationCommand.Paste, etc in Silverlight 4 beta version ?
No, RoutedCommands are not supported in Silverlight although the primitive ICommand is. Silverlight 3 had ICommand but never used it anywhere. Silverlight 4 adds support to button controls to have an ICommand associated.
However, the full featured routed commands are not supported. They were not particularly useful in WPF anyway because they placed the burden of handling the command logic on the UI control that handled them. As it turns out, it is far more useful to have an ICommand exposed from the ViewModel.
Check out http://www.codeplex.com/compositewpf for the Prism project which includes some very useful classes such as DelegateCommand.
Having said that, commands like Cut/Copy/Paste are different from most commands because they are a generic command that usually applies directly to the control upon which it's executed. This is much different from a Save command for example which has a very specific meaning to the application behind the UI. For these clipboard related commands I'd say it's fine to break from the traditional separation patterns and write some UI-specific code in the code behind and use FocusManager.GetFocusedElement() to figure out which control you need to operate on.