prismlibrary / prism Goto Github PK
View Code? Open in Web Editor NEWPrism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications..
License: Other
Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications..
License: Other
This is being split from Issue #15
Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.
If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.
I know this would be a heavy shift but it might be helpful for futur extensions.
I think that RegionManager currently does to much things at once and violates the SOLID principles. I see especially the Interface Segregation and Single Responsibility Principles are currently violated because it is, for example, quite easy to add your views directly into the views collection of a region and short-circuit the whole navigation concept. Another example is the complex way to use the navigation journal if you want to have a "navigation back" beahvior. A cleaner way would it be to create a NavigationService like we have in the WinRT version. Instead of using the RegionManager or access the NavigationJournal directly, you can just call these methods on the INavigationService interface.
To summarize the advantages of this change:
to standardize on tab size and reduce line ending whitespace.
It'd be very helpful for some of us who'd like to contribute to know the features that we'd like to add/fix/remove in the next version. May be discuss them as well (like #8) before we actually start implementing new features.
When calling the Navigate method I prefer to pass in a strongly typed Type.
Passing in Type.Name could work but that would be kinda silly going from Type to String back to Type.
So everyone can contribute, it will be great if we could have a roadmap, backlog and tasks (probably after build). We could use https://trello.com/ for visibility.
When Prism was in Microsoft's hands they used two XmlnsDefinitions:
XmlnsDefinition("http://www.codeplex.com/CompositeWPF", "namespace") -- original
XmlnsDefinition("http://www.codeplex.com/prism", "namespace") - this was meant to replace the original
Now, we should come up with a new schema that is not tied to the codeplex name.
We do have a domain "http://PrismLibrary.com", that has yet to have a site created. So should we use this now?
XmlnsDefinition("http://prismlibrary.com/", "namespace")
XmlnsDefinition("http://www.prismlibrary.com/", "namespace") -- notice the addition of "www"
Other ideas?
Next week I will start a new project. Should I use Prism 5 and migrate the project if Prism 6 is released or it is possible to start the project with Prism 6?
I went ahead and had a first stab at it:
https://github.com/arbsmith/Prism/tree/master/Source/Windows/Prism.Windows.Store.Unity
Are there some technical reasons for not already having it?
When using MEF the VML it is falling back to the default Reflection code in the ViewModelLocationProvider instead of using the MEF to instantiate the view model class. To follow the pattern of the other DI bootstrappers, the MEFBootstrapper should override the ConfigureViewModelLocator() and also call this method in the MEFBootstrapper.Run() override.
Since the ViewModelLocator was moved into the primary Prism assembly, we need to set the default type resolver for the ViewModelLocator in the Prism.Wpf.Mef bootstrapper.
note: this has already been done in the Prism.Wpf.Unity bootstrapper
I'd like to create an overlay on top of the root Frame. Typically, I would do this by creating a UserControl with a Grid, inside of which I could overlay a control on top of the Frame. The following chunk of Prism for Windows Store application code, in MvvmAppBase makes this a difficult task:
protected async Task<Frame> InitializeFrameAsync(IActivatedEventArgs args)
{
var rootFrame = Window.Current.Content as Frame;
// Do not repeat app initialization when the Window already has content,
// just ensure that the window is active
if (rootFrame == null)
{
// Create a Frame to act as the navigation context and navigate to the first page
rootFrame = new Frame();
What I would rather see is something like this:
protected virtual Frame GetFrame()
{
var rootFrame = Window.Current.Content as Frame;
// Do not repeat app initialization when the Window already has content,
// just ensure that the window is active
if (rootFrame == null)
{
// Create a Frame to act as the navigation context and navigate to the first page
rootFrame = new Frame();
}
return rootFrame;
}
protected async Task<Frame> InitializeFrameAsync(IActivatedEventArgs args)
{
var rootFrame = this.GetFrame(IActivatedEventArgs args);
This way, I could still get the base implementation of the Frame logic of InitializeFrameAsync, but I'm able to override the creation of the Frame. While we're at it, let's make InitializeFrameAsync virtual.
When using the current Prism for Windows Store Apps package 'as-is' to create a Windows 10 UWP app, you'll get a TypeLoadException on SettingsPane in the WP emulators. To fix this, the conditional compilation checks have to be replaced by Api Contract checking (and SDK extensions for Windows Desktop and Mobile have to be added to the UWP project).
if (ApiInformation.IsTypePresent("Windows.UI.ApplicationSettings.SettingsPane"))
{
SettingsPane.GetForCurrentView().CommandsRequested += OnCommandsRequested;
}
if (ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons"))
{
HardwareButtons.BackPressed += OnHardwareButtonsBackPressed;
}
Prism 4 had Silverlight support that was dropped with Prism 5.
It will be not very hard to restore its support. We need for it:
If there is any chance that it will be accepted, I'll prepare PR for review.
While having a go at adding support for Autofac (issue #16), I ran into BootstrapperFixtureBase which has a //todo to move to a shared DLL. Together with this class, all mocks for these tests can be shared as well.
The discussion on #10 inspired me to open a new issue about the naming/structure of projects and see if I am off on my own island in this regard (yet again smile).
The whole new platform thing is, well, new, so I think we're all learning along here.
I am wondering if it makes more sense to categorize assemblies/namespaces along by technology/concern then platform, resulting in the following pattern:
..
Example: Prism.Unity.Windows
The other implied suggestion here is to use "Windows" in place of Wpf, as (I feel, personally) it is a stronger brand name, and then can also be extended in the case of Windows 10/Universal/One:
Prism.Mef.Windows.Universal or
Prism.Mef.Windows.One
(This is assuming that "Windows One" -- or "All-in-One" as I believe I have seen -- is the new API name being announced at //build.)
Part of the reasoning behind this suggestion is that I feel this is consistent with Xamarin's approach (which I personally will be adopting, as well):
Xamarin.Forms.Platform.
(We would remove "Platform" to make it more succinct).
So in total:
Prism (PCL)
Prism.Windows (WPF Components)
Prism.Forms (Xamarin.Forms Components)
Prism.Unity (PCL)
Prism.Unity.Windows (Unity WPF Components)
Prism.Unity.Windows.One (Unity Windows 10 Components)
Prism.Unity.Forms (Unity Xamarin.Forms Components)
Prism.Mef (PCL)
Prism.Mef.Windows (MEF WPF components)
Prism.Mef.Windows.One (MEF Windows 10 Components)
Prism.Mef.Forms (MEF Xamarin.Forms Components)
The obvious intention/benefit for this design is that:
. - For components with extensibility points.
.. - For implementations/extensions of extensibility points.
Just another thought that's been kicking around my head and had to get it out. :) Thanks for any consideration as always.
This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.
The current implementation of Prism for Windows Runtime doesn't allow you to cleanly cancel navigation, while it is supported by the OS. The FrameNavigationService implementation hooks onto the Frame.Navigating event:
_frame.Navigating += frame_Navigating;
The full eventhandler has NavigatingCancelEventArgs as parameter, which enables cancelling the navigation. However, this is not forwarded to the viewmodel.
departingViewModel.OnNavigatedFrom(viewModelState, suspending);
As an extra: OnNavigatedFrom should be named OnNavigatingFrom, as cancellation can still happen.
VML currently just blindly appends "ViewModel" to the type name of the View when using the default View to ViewModel type resolution. With the most common convention for naming Views in MVVM in WPF being to have "View" at the end of the type name, this results in the default convention picking XYZViewViewModel for XYZView, which is just wrong.
We need to make the default type name resolution inspect the View type name, and if it ends in View, only append "Model". If not, append "ViewModel" the way it does now.
The default convention will remain easily overridable through the SetDefaultViewTypeToViewModelTypeResolver method.
I know in this issue we talked about organization:
https://github.com/PrismLibrary/Prism.Wpf/issues/1
Things look really good right now with how the solution is organized. My only concern now is that the core Prism library has client/presentation components in it. That is, the Commands and Mvvm namespace, as well as IActiveAware.
The original ask/intention for this separation (found here) was meant to be designed so that Prism can be used in any application boundary, not just for applications dealing with presentation.
For instance, one can (and I, for one, am intending to) use Prism for server-side applications. That is, eventing, logging, and yes even modularity are all ubiquitous and can be utilized in any application, regardless of where it exists.
My ask here is that the Prism team (at the very least) consider making a Prism.Client (or Prism.Presentation or...?) assembly with client-specific components within it. That way, when we're using the core Prism in another non-presentation application, we're not scratching our heads wondering what a DelegateCommand is doing there (like we did in 4.1, which is why that issue was created in the first place. :) ).
If this makes sense, my ask would also be that the team considers flattening out the namespaces so that all of the components lie at the root level of this assembly (since there would only be about 9 classes in total). Unless of course there are going to be many more classes added to those namespaces, then disregard.
All of this is open to discussion, of course. Just wanting to get it out there so it doesn't fester in my head. :)
I like the three view model types in Prism for WinRT. Unfortunately in WPF we only have BindableBase. Even ViewModelBase is not really needed in WPF, I guess that ValidateableBindableBase would be an appreciated extension.
I've got a view that's navigated to and each time it is assigned a new viewmodel as datacontext.
The view contains an InteractionRequestTrigger with its SourceObject bound to a property on the viewmodel. Problem is, the binding is not updated when a new DataContext is assigned, resulting in the SourceObject pointing to an old and probably disposed viewmodel and most importantly, the InteractionRequest.Raised property is null, so nothing happens when I want to trigger the InteractionRequest from the current viewmodel.
We will be looking at creating project template for Prism for WPF. We need to start getting ideas about what kind of project and item templates to make.
Here are some ideas for Project Template:
Stubbed out starter application
Stubbed Module
Item Templates:
UserControl with ViewModelLocator.AutowireViewModel set to true
UserControl with ViewModel and the ViewModelLocator.AutowireViewModel set to true
XAML Module Catalog
App.config Module Catalog
Not sure about the names of these templates. Also, I would love to hear other ideas of templates we should support.
For example, should we provide a base Module class, or a base ViewModel class in our project templates?
This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.
In Windows 8.1 API the BackStack property was added to the Frame control. The current implementation of Prism for Windows Runtime doesn't expose any way to remove pages from the backstack.
I know that everything is very fluid at the moment, but I just want to voice my concern with Forms Navigation. I know that you are mimicking the internal navigation code, and that is where I am taking exception (not your implementation). Getting navigation right is very difficult, so I cannot fault them. Much. :) For starters, I would like to see the "animated" boolean that is passed around handled a little bit better. That is something that should be kept track of in the view if possible.
I am not sure if this can even be encapsulated/addressed in Prism's implementation, but I just wanted to voice it now as it is something I am going to bring up on Xamarin's forums once I get my WPF renderer completed.
I stumbled across this when trying to fit my MEF samples to the Prism 6.0 code base using the ViewModelLocator.AutoWireViewModel . I have a single [ImportingConstructor] for my View Model with one parameter (my business service), but the ViewModelLocationProvider is using Reflection to get the View Model instantiating it with the default constructor. Therefore when the module attempts to display my view, I get this exception. "No parameterless constructor defined for this object." Should the ViewModelLocationProvider be using DI to get the View Model instance instead of Reflection?
GitHub isn't really good about this, but it would be cool to get a chat room to discuss items for this project. That way, meanderings, musings, and other unofficial banter don't get created as issues (halo). It is sort of confusing as "Issues" are really the only way to contact owners, and there really needs to be a forum/chat room for this.
I personally prefer forums, but it looks like chat rooms are the only offerings available right now. Here is one that I know of:
This is being split from Issue #15
Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.
If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.
Right now, Prism supports Unity and MEF out of the box, but we would love to add support for other containers.
Some containers we should consider adding support for:
If you would like to submit support for a container, use the Prism.Mef.Wpf, Prism.Unity.Wpf and Prism.Unity.Forms projects as a guideline. As you can see the naming convention is Prism... The namespace should follow the Prism. convention and not include the platform. For example, if using Autofac, the namespace should be Prism.Autofac.
This is an issue on the current Prism for store (Win8/8.1 RT) implementation. Logged considering we're taking it forward to Win10 (after \Build?) and keep it in the current lightweight form. API changes in Win10 might have impact on the logged issue.
The current implementation of Prism for Windows Runtime creates its own INavigationService object in MvvmAppBase.InitializeFrameAsync(). This creation is private and hard-wired to FrameNavigationService. Using your own implementation of INavigationService requires some dirty coding.
private INavigationService CreateNavigationService(IFrameFacade rootFrame, ISessionStateService sessionStateService)
{
var navigationService = new FrameNavigationService(rootFrame, GetPageType, sessionStateService);
return navigationService;
}
After talking to a number of Xamarin.Forms developers, I am finding that controlling the animation during navigation is very rare.
Is this correct? And if so, should we remove the animate parameter from the Navigate method signature?
If we do keep it, should we at least move it to the end of the method signature? Make it the last parameter?
How about adding official WinForms support?
I have checked source code of RegionNavigationService.cs, and It seems there is no such mechanism. I think it would be a good idea to dispose view/view model when IRegionMemberLifetime.KeepAlive
is false
. This is a good practice to put all clean ups in Dispose
method such as unregistering static CompositeCommand
s or disposing DbContext
instance in view model (yes, I'm not a fan of Repository pattern :P).
Would it be possible too add the [Serializable] and/or [DataContract] attributes to BindableBase? Without that, types that inherit from BindableBase are not serializable by data contract.
This is another odd behavior I'm afraid. What's happening is that when binding a Button.Command
property to a DelegateCommand
, the EventHandler
reference that the DelegateCommandBase
registers with the WeakEventHandlerManager
gets collected. So, DelegateCommandBase.RaiseCanExecuteChanged()
has no effect. Otherwise, I have no idea why it's being collected, but again, this maybe something off with Xamarin.Forms -- I wouldn't be surprised at this point.
Removing the usage of the WeakEventHandlerManager
from DelegateCommandBase
fixes the problem, but I'm not sure if that's what you're after. It maybe noteworthy that other libraries that provide an ICommand
implementation don't use WeakReference
s.
Consider the following ViewModel:
public class SignInPageViewModel : BindableBase
{
private readonly DelegateCommand signInCommand;
private string email;
private string password;
public SignInPageViewModel ()
{
this.signInCommand = Workify.Commands.DelegateCommand.FromAsyncHandler (this.ExecuteSignIn, this.CanExecuteSignIn);
}
public DelegateCommand SignInCommand {
get { return this.signInCommand; }
}
public string Email {
get { return this.email; }
set { this.SetProperty (ref this.email, value); }
}
public string Password {
get { return this.password; }
set { this.SetProperty (ref this.password, value); }
}
private async Task ExecuteSignIn ()
{
// Do something
}
private bool CanExecuteSignIn ()
{
return !string.IsNullOrWhiteSpace (this.Email) && !string.IsNullOrWhiteSpace (this.password);
}
protected override bool SetProperty<T> (ref T storage, T value, string propertyName = null)
{
if (base.SetProperty (ref storage, value, propertyName)) {
this.signInCommand.RaiseCanExecuteChanged ();
return true;
} else {
return false;
}
}
}
And the following ContentPage:
<?xml version="1.0" encoding="UTF-8"?>
<ContentPage
xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:prism="clr-namespace:Prism.Mvvm;assembly=Prism.Forms"
prism:ViewModelLocator.AutowireViewModel="True"
x:Class="Views.SignInPage">
<StackLayout>
<Entry Text="{Binding Email, Mode=TwoWay}" />
<Entry Text="{Binding Password, Mode=TwoWay}" />
<Button Text="SIGN IN" Command="{Binding SignInCommand}" />
</StackLayout>
</ContentPage>
What's supposed to happen is that the Sign In button is enabled as the Email and Password entries are filled out. But this doesn't happen.
I would really like to see the PubSubEvent maintained as it's own library rather then rolling it into a common Prism library. There are times when this component is very useful on its own with out anything else. My current project is a good example. They are very sold on the Prism event model but have no need for the rest of Prism. This is definitely the case in services
We need the community's input on this issue. We are considering changing the name of the event aggregator's PubSubEvent to PrismEvent to better align with Prism as a product. What are the community's thoughts on this? Should we make the change? Prism 6 for WPF will contain breaking changes in terms of namespaces. So, since we are breaking apps, now would be the time to do it.
What are your thoughts?
I think this is a good Idea to notify View-Model when associated View.Loaded/View.Unloaded event raise. Sometimes you (from inside a View-Model) need to know if View is loaded or not. For example when View still not loaded, if you call RegionManager.RequestNavigate
it does not works.
Loaded
and Unloaded
) to BindableBase
and call them when view loaded or unloaded.ILoadAware
, call Loaded
and Unloaded
methods properly.ViewModelLocationProvider
class.What's your Idea?
Silverlight had nice built in support for a message dialog that centered on the view and put a transparent overlay over the background. WPF does not have a native experience for that built in, but it can be written without a great deal of difficulty. It would be great to add this as an alternate presentation strategy for InteractionRequest out of the box.
I really want to have the ability to inject the INavigationService through constructor injection, and not have this workaround of having ViewModels implement the INavigationServiceAware interface in order to get the navigation service.
I want to use DI in my ViewModel constructors like I would for any other service.
What are the thoughts on switching the unit testing framework away from MS Test, to another more modern framework, such as xunit or fixie?
I should note that the dotnetfoundation projects all seem to be consolidating on xunit.
I think this is an important navigation feature that is currently missing in the WinRT/Universal branch, certainly for the LOB apps (to be) created on UWP. The way current navigation for RT works and how Prism plugs in, brings some challenges to the table but it can be done.
So {x:Bind} is changing how binding works. {Binding} connects to a context, which at a top most level is a DataContext. {x:Bind} doesn't connect to a context, it connects directly to properties on the host control, and is strongly typed. This means that {x:Bind} can't use DataContext, because DataContext is type object.
Also, as {x:Bind} has much better performance than {Binding} it should be the new default going forward.
With that context, I was just wondering how this should be handled. I mean I know in the short term one could just make a property that returns (IViewModelType)DataContext, and hope it all kind of works out haha. But in the long term, is there a plan for what the IView should look like to accommodate this?
Some thoughts - you could specify the ViewModel Type you're looking for in the IView itself - IView I suppose. And IView could also implement IView, so you can still do the IView checking for AutoWire?
Hi I'm writing a mobile app on Xamarin, and I'm having trouble using INavigationService
. It seems that no matter how I call INavigationService.Navigate()
, the useModalNavigation
parameter is true. For example, I'm currently calling it like this:
this.navigationService.Navigate ("SignInPage", useModalNavigation: false);
But I've also tried:
this.navigationService.Navigate ("SignInPage", null, false, true);
And:
this.navigationService.Navigate ("SignInPage", parameters: null, useModalNavigation: false, animated: true);
Is anyone else having this issue? I'm not sure if this is something specific with Xamarin or if it's the way the interface is defined.
I've followed Biran Lagunas tutorial for setting up Prism with Unity for my Xamarin Forms app that targets Windows Universal (RT+WP 8.1) and Android.
But any INavigationService.Navigate
call always gives NullReferenceException in Prism.Forms.
This is what I did: Added Prism for Xamarin Forms (Prism.Forms 5.6.1-pre1) package; this will only stick to the Windows 8.1 app, but the included references does in fact work with Xamarin PCL Libraries (Profile 111) if I add the Unity 3.5.1405-prerelease package.
In my PCL I then setup a UnityBootstrapper as such:
public class Bootstrapper : UnityBootstrapper
{
protected override Page CreateMainPage()
{
return this.Container.Resolve<HomeView>();
}
protected override void RegisterTypes()
{
// TODO: SettingsViewModel (plugin)
this.Container.RegisterType(typeof(IDatabaseManager), typeof(DatabaseManager));
this.Container.RegisterTypeForNavigation<SettingView>(ViewNames.SettingView);
this.Container.RegisterTypeForNavigation<TimeLogListView>(ViewNames.TimeLogListView);
this.Container.RegisterTypeForNavigation<TimeLogView>(ViewNames.TimeLogView);
this.Container.RegisterTypeForNavigation<HomeView>(ViewNames.HomeView);
}
}
And init this in my Xamarin PCL App.xaml.cs:
this.bootstrapper = new Bootstrapper();
this.bootstrapper.Run(this);
Running the app brings up the HomeView and with the prism:ViewModelLocator.AutowireViewModel="True"
attached property HomeViewViewModel is in fact hooked up properly.
But...
If I for example take in INavigationService
in my HomeViewViewModel and try to call navigationService.Navigate(ViewNames.HomeView);
, I see the View's Init run all well and fine before a NullReferenceException - Object is not set to an instance of an object in Prism.Forms.
Ideas, clues?
Trying to solve this before my presentation on Wednesday 20 may, at our next Xamarin Meetup here in Stockholm.
Back on this thread:
http://compositewpf.codeplex.com/discussions/581235
This was said:
Keep in mind, that not every platform has the concept of modularity or composition, and/or does not support it. For example, mobile apps don't support this concept, instead a navigation framework would be needed.
I would like to challenge this statement. Modularity to me is being able to succinctly compartmentalize a portion of an application. It doesn't necessarily need to be something that is loaded dynamically. I think of it is as clean separation of concern... an actual module, or perhaps an application "content" module. I really enjoyed this in Prism 4.1 and utilized it extensively. I was really able to modify the infrastructure around this feature to really build some awesome loading and initialization within my own framework.
What ends up happening is that each "page" (or "section" or "primary screen") turns into a module, and each module has its own configuration (comprised of commands that are executed when the module loads).
I used to have a project on CodePlex that was an outstanding example of this but then completely hosed it when I switched over to Git (and was sure that Silverlight was dead, and my code was no longer of value... D-O-H!). I wish I could show it to you now so you can get an idea of what I am talking about. It was pretty rad. :)
Anyways, having this functionality (outside of the definition provided above) in a cross-platform manner would be pretty useful/valuable.
Would be great if https://simpleinjector.org/ could be added to the list of supported DIs
Ideally, my vote would be to make the Forms Unity Bootstrapper as much like the WPF version as possible, if possible. For instance, the Logger should be part of the initialization process, in my view.
Also, there is a lot of room for improvement with the guidance provided with Xamarin's initialization. For instance, they do not define their Application object in Xaml, which I think is unoptimal. Here is an example of this in action:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client/ApplicationDefinition.xaml
You can also see that I define the MainPage defined in the Xaml there, so there is no need to create it during the setup (bootstrapper) phase.
Also consider that I define my bootstrapper in Xaml as well. Here is the WPF version of what I am working on (I am currently building a Xamarin.Forms WPF renderer as a proof-of-concept project):
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Setup.xaml
And you can see that this is assigned here:
https://github.com/DragonSpark/Framework/blob/Multiversal/DragonSpark.Testing.Client.Application/Application.xaml#L16
The reason I bring this up is that the Bootstrapper has typically had protected or non-public properties, and hinders it from being defined in Xaml. This would be something to be mindful of for design considerations.
Prism for WPF has a big issue when it comes to unit testing. Various important methods like RegisterViewWithRegion and RequestNavigate are provided as extension methods. That makes it unnecessarily hard to create fake objects. At least the navigation is something you might want to test within your view models to see if the correct target is selected.
Implement navigation using SplitView including:
Building menus dynamically.
Creation of generic menu.
Contextual menu associated with specific View / Views.
Hierarchical menus.
with specific View / Views.
Hierarchical menus.
(This might be related to: #26 ?)
Currently I can find no mechanism for letting view models opt out of registration in a journal or for removing journal entries. The RecordNavigation method on the IRegionNavigationJournal interface can only look at the view's Uri and the navigation parameters, not the ViewModel instance. I have also looked at writing my own IRegionNavigationService, but this class too is unaware of the ViewModel instance.
I have the following use case in which such a scenario would be useful. Consider the following sequence of views:
SomeView -> CreateItemView -> ItemView
Now from the ItemView I would like to 'GoBack' to the SomeView, skipping the CreateItemView.
It would be nice if there was a mechanism that lets ViewModels decide if they wish to be record in the journal or not, possibly via a parameter in NavigatedFrom?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.