Seems like this should be easy but I can't for the life of me figure out how to add a static class to all instances of a reusable content pane. The default classes are nonspecific (pane-1, pane-2, etc) but it would seem to be helpful to have a class that's unique to the pane so when it is reused on other pages the css will automatically apply. Any ideas?
This seems to do the trick. Allows you to add all sorts of classes to all sorts of things. Nice module: https://drupal.org/project/clean_markup.
Related
I want to create an application where the user navigates through pages that are placed inside a frame element. The problem is that one page can have different layouts which basically provide the same functionality. There can be a few buttons or input controls more or less per layout, but they all should share the same code behind file.
In Windows Forms, I used to place all elements (the layout) on the same form and then hide/show the controls I required, but that's a very ugly solution and I was hoping that WPF provided something more convenient here.
I tried to create 2 Pages, deleted their respective .cs files and set their "x:Class" attribute to a custom .cs file, but that results in compiler errors (ambiguous calls to InitializeComponent() ).
So can I have multiple pages that share the same code?
You should move the logic from the code-behind class to a view model class. This pattern is known as Model-View-ViewModel and is the recommended design pattern to use when developing XAML based user interface applications.
There are plenty of online tutorials about it and this one should provide a good starting point for you: https://msdn.microsoft.com/en-us/library/hh848246.aspx.
Once you have understood the pattern and implemented your application logic in a view model class, you could then simply set the DataContext property of both pages to the same view model:
public Page1()
{
InitializeComponent();
DataContext = new ViewModel();
}
A code-behind class is simply a partial class, i.e. it is partial definition of the Page that you define in XAML and therefore you cannot "share" this one between several different pages.
Partial classes are just a way of splitting the definition of a class across several different source files: https://learn.microsoft.com/en-us/dotnet/articles/csharp/programming-guide/classes-and-structs/partial-classes-and-methods.
I'd like to split a xaml file into several files a bit like partial class : is there a way to do so ?
I want to be able to manage my project files more convenienly.
There are some possibilites, although it may not be exactly what you think about.
You may outsource ressources by means of a ResourceDictionary. This is very convenient for styles and templates. Of course you have to organize your XAML such that you could benefit of it (use ControlTemplates for instance).
Furthermore you could create UserControls that encapsulate parts of your XAML. This depends on your layout, though.
These parts can be organized in assemblies, which you refer to by references known to XAML via xmlns:??? declarations.
One technique that I have used successfully is to create a parent class that inherits UserControl and I use that as my base xaml class. This allows me to centralize functions like 'onLoad', 'onDataContextChange', etc. Between that and using resource dictionaries I've been able to keep my code much more streamlined.
I'm using Ext Js 4.1.1.
In many of the Ext JS widgets I am using, I am required to reuse data. For example, the items collection for buttongroup in top toolbar may be repeated in menu bar on the left side. For manageability, I should be able to have the array for items collection defined in a separate file (which could potentially follow the class naming convention for auto loading).
The approach I tried is that I am creating a class that has statics. Each static function returns an array that can be assigned to items collection of the widget. This works but I believe that using a class is an overkill if I can just use an array. Any suggestions?
Not sure if it will be useful to create separate objects for storing configuration for toolbars, buttons groups and etc. In the context of the extjs in almost all cases you need not only manage configuration but also behavior of a component.
The best way for me here - creation of generic/basic predefined classes, where you can state not only configuration but work around the behavior, add you'r custom events and process any unexpected results. After it you can easily reuse and extend it easily.
For instance you have a menu or a toolbar with 3 items A, B, C. For sure you need to know wherever you use it what was clicked (for instance) A, B or C. Creating a class and manages required events you can fire you own events which will tell you what was clicked and it is much easier to use in any context where this component will be used. Add post and pre processing, template methods and etc...
Creating a big file just with configuration is not readable and not extendable, will be a case whre you will need to add functionality and behavior to all such generic components and it will be not easier to do with just arrays or simple configs. Separating even just simple general components having just simple configuration (in the beginning) will bring more expressive in the code structure and readability and in the later time gives you the power to manage it.
Pure configurations can just keep the code accurateness and re-usability but what about behavior for in almost cases you need to control..
The design, maintainability and extensibility are very important points in every big web-applications and in context of extjs 4.
I'm writing a WPF application while mostly adhering to the MVVM design pattern. The application has various educational modules broken up into different categories to be accomplished by the user. The modules are organized into a hierarchical menu. My ViewModel has a class called MenuPageViewModel which exposes the information needed to render a MenuNode. Naturally, the terminal elements in the menu tree have content that I'd like to display to the user. This content can be one of many different types of modules. Currently, when the user selects a module in the menu, I can't see any way around using a large conditional block to determine what type of ViewModel I'd like to return to be displayed based on the type of the MenuItem's Content Property. For example...
if (CurrentlySelectedMenuItem.Content is Lesson)
return new LessonViewModel(CurrentlySelectedMenuItem.Content as Lesson);
if (CurrentlySelectedMenuItem.Content is SkillsCheck)
return new SkillsCheckViewModel(CurrentlySelectedMenuItem.Content as SkillsCheck);
Can someone give me a hint to a more elegant and maintainable approach? Right now, if I add a new module type, I have to remember to update this conditional block, and that just sort of annoys me.
Thanks.
If you are using Unity/Prism then using the container to resolve the object would be my first preference.
_container.Resolve(Type.GetType(strObjectType)) as BaseViewModel;
where strObjectType is a string with the type of class you want to create (eg "LessionViewModel" )
if you are not using Unity, then reflection works
Activator.CreateInstance(strObjectType) as BaseViewModel;
with both solutions you need to have the string with the class type on your menuItem.
A third option is to have a factory, but it would probably end up having a conditional situation within it or will contain the code i just listed.
I am starting my first foray into the world of Prism v4/MVVM with MEF & WPF. I have sucessfully built a shell and, using MEF, I am able to discover and initialise modules. I am however unsure as to the correct way to provide navigation to the views exposed by these modules.
For example, let's say that one of the modules exposes three views and I want to display navigation to these views on a menu control. So far, I have sucessfully exposed a view based upon a MenuItem and this MenuItem contains child MenuItem controls thus providing a command heirarchy that can be used. Great.
Thing is, this feels wrong. I am now stating within my module that navigation (and therefore the shell) MUST support the use of menu's. What if I wanted to change to using a ToolBar or even a Ribbon. I would then have to change all of my modules to expose the corresponding control types for the shell.
I have looked around and there is mention on some sites of using a "Service" to provide navigation, whereby during the initialisation of the module, navigation options are added to the service which in turn is used by the shell to display this navigation in whatever format it wants (ToolBar, TreeView, Ribbon, MenuItem etc.) - but I cannot find any examples of actually doing this.
To put all of this into perspective, I am eventually looking to be able to select views from a menu and/or other navigation control (probably a Ribbon) and then open those views on demand within a TabControl. I have already gotten as far as being able to create the views in the TabControl at module initialisation time, now I need the next step.
What I need to know is this: what would be the correct way to expose navigation options in such a way as not the insist on support of a specific control by the shell, and if a service is the way to go then how would one put this together within the Prism/MVVM patterns.
Thanks in advance for any insight you can offer.
I suppose you have a main module containing common interfaces.
You could create a simple interface like
public interface IMenuService {
void AddItem(string name, Action action);
IEnumerable<MenuItemViewModel> GetItems { get; }
}
Create 1 implementation and a single instance.
public class MenuService : IMenuService {
private readonly IList<MenuItemViewModel> items = new List<MenuItemViewModel>();
void AddItem(string name, Action action) {
items.Add(new MenuItemViewModel {
Name = name,
Action = action
});
}
IEnumerable<MenuItemViewModel> GetItems {
get { return list.AsEnumerable(); }
}
}
Within your modules, use MEF to resolve this instance and call AddItem() to register your views.
The Action property is a simple delegate to activate a view or do anything else.
Then in your shell or any view, you just need to call the GetItems property to populate your menu.
Having thought about this some more, I have come to the following conclusion that I feel affects the way that I need to deal with this...
The modules need to be partially aware of the shell layout anyway - that is, the shell exposes a number of regions and the modules need to be aware of those regions (by name as well as what is expected to be shown) in order to populate them correctly when functionality is requested (either by means of registering a view within a region or as the reaction to a user action).
Because of this, the modules need to be designed to interact with the shell to place content into the named regions and as such, I see no reason why the modules should not expose whatever type of navigation the shell supports.
Therefore, my modules (currently) expose a "RibbonView" (a RibbonTab) with the necessary icons, buttons and commands etc to expose the functionality of the module. Each "RibbonView" is registered with the "RibbonRegion" of the shell, along with hints for ordering, and this is then rendered within the shell.
If in the future I choose to update my shell to use the latest+greatest navigation control (whatever that may be in x years time) then I simply need to update each of the modules to expose the necessary items to integrate with that new navigation and, because I am loading into a new shell, I can then update my view registration accordingly.
I just hope that I am not breaking any of the principles of the composite application in doing this, but that said I have never yet found a pattern that can actually be implemented in a real scenario without some "interpretation".
I would be interested to hear if anybody has any opinions on this.
I've encountered the same situation, and I think the solution lies in differentiating between interface and implementation. For example, you can design a view in a module that performs a given function. That's all it does. As soon as you use or consume this in a specific context you've crossed over into implementation. Now, ideally the view is unaware of how it's being implemented, and certainly would have no knowledge of named Regions in the Shell. So, seating views into Regions within a module is a no-no.
To get around this, I've opted to delegate this responsibility to a third-party component, a LayoutManager. The LayoutManager sits between the Shell and Module and defines "what goes where". It is a specific implementation, and really defines the implementation. Both the Shell and the Module view remain generic.
Have a look at: http://rgramann.blogspot.com/2009/08/layout-manager-for-prism-v2.html
Which may give you some ideas around this problem.
Hope it helps.
This article uses an abstraction (IMenuItem) to represent the ViewModels for your menu choices. How you actually render these imported objects is really up to the host application. The example uses a WPF menu, but you could certainly render it any way you wanted because IMenuItem is abstract enough.
If you changed IMenuItem to INavigationItem, you've got what you want.
In that article, when the particular navigation item gets notified that it's been "run", then it usually instantiates a ViewModel for a document or "pad", and passes that to the ILayoutManager service. It has a pluggable architecture, so you can swap out the LayoutManager service for a different layout engine (the default one is a wrapper around AvalonDock).