I work on site admin application and use marionette. And my problem is - how to organize views and applications for next requirements. Thanks for any help!
There are main menu on header - Users management, Evenets, General settings
And when user clicked to Users management On main region must shows additional menu with
Users Groups Permissions items and by default list of users (first tab is active).
Each item on click should shows coresponding view with list of entities.
And my question is how to organize applications, views and interaction between them?
Is sub menu part of users list view or it independent view? Which type of marionette view it must be?
Sounds a lot like typical web page where it would be much easier to just render HTML on the backend and not build a web-application.
As for structure, there is no one correct way, but I found these couple example projects as decent start to evaluate the best structure:
https://github.com/derickbailey/bbclonemail
https://github.com/Foxandxss/bbclonemail
https://github.com/brian-mann/sc02-loading-views
They all use slightly different structure and coupling. You have to decide yourself which one is best suited for your case.
In your case I guess main application with main region where you show different sub-applications based on user selection (tabs). For specific interaction patterns look at the examples. Try to decouple everything, don't pass around references instead emit and listen to events.
I've built and work with couple bigger web applications and I recommend to no go that path unless there is a reason to do that. Admin interface sounds like something you can "quickly" setup using existing frameworks like django-admin, flask-admin, Rails scaffolding, express-admin, well you get the idea. Then again I don't know anything about the project.
Related
I have an AngularJS application that grew up over the last months to a dozen of states with over hundred controls (input, combos, etc...).
A security-service gives me a few user-roles back (for instance a "read-only" role).
Now I'd like to know how you guys handle the management of the app's controls? I would like to to have a centralized logic/place where I could set the controls states (grey-out, disable or even hide).
I was thinking to have a own logic/schema of control IDs -> Assign each control a unique HTML ID. like "app.state.panel.control". Then based on that I could en-/di-sable a single, all or a part of the controls (for instance "state.panel.*" would address all controls of one panel).
What do you think? Any documentation discussing this topic? Any known existing Angular modules?
Thanks
I'm attempting to create a jump menu of links to external websites, and I would like to be able to order the links within this menu differently depending on the organic group of the current user attempting to access it. So far I've tried to accomplish this using views with nodequeue, and have come somewhat close, but its beginning to feel like a dead end.. Does any module(or combination of modules exist) which would allow me to accomplish this without having to write my own? Ideally each will be able to reorder the links according to their personal preference and override the default ordering of links. but that is not essential at this point
I know this is a role based solution, but it might be in the right direction.
Menu Per Role
It doesn't work with building a menu out of Views based on an OG permission? You could create multiple displays and it'd be a pain, but you could use Menu Views and see if that works.
Hope some of this helps.
Imagine you have a complex data object. It was complex enough that to edit the various properties of the object, it would be best for the user to have multiple screens. It's essentially a shopping cart for configured items.
So one screen would allow you to add items.
Another would allow you add modifications to those items, predetermined changes that have a cost associated.
A third screen would allow you to configure global settings for your items.
As I'm sure you can guess, each screen is operating on the exact same cart, just altering different properties and relationships of the items inside.
So, we're going to try to write the application using MVVM, and while discussing the various screens (as well as navigation between them) we arrived at the following question:
How do people generally manage application state when using MVVM? The navigation bar that the users will use to change screens will exist outside of the screen, but when a user clicks it, what common ways have people been using to hide one and show another?
More generally, how are people handling global application state? The user can only operate on one cart at a time, there can only be one user logged in at a time, only one screen can be shown at a time. Would it be best to create a singleton that stored these important properties and the ViewModels could keep a copy of them and subscribe to changes via an event aggregator?
As you can tell, I barely even know where to start with this problem, so any advice at all is welcomed and appeciated.
I would use ViewModels to track the application state.
One ViewModel controls the entire application, and it handles what page the user is currently on. The application itself is bound to the main ViewModel, and the majority of the application screen space is a ContentControl that is bound to ViewModel.CurrentPage. DataTemplates are then used to determine which View to display for whatever page the user is currently on
In the past I've used a global singleton for some objects (such as current user) and the ViewModels use a reference to this if needed. So if I wanted to display the UserName on a page, I'd have a property in the ViewModel called UserName and it returns Global.Instance.CurrentUser.UserName
For your type of situation I would look into PRISM. PRISM is a collection of patterns for developing WPF applications in a loosely coupled MVVM manner.
Specifically, for your example of the multiple screens and managing application state, using a "Controller" to load the views for the various representations of your ViewModel (the cart) into separate "Regions" would probably be a good start. There looks to be a great article on MSDN about getting started with PRISM, including composing user interfaces (Regions).
I am new to Silverlight/Prism, so not sure how a new layout page would be rendered. I've got the Shell working like a master page, but I want to have several pages in the application with a different layout master. So, how do I get another (shell) or layout page to arrange different regions?
Thanks for any conceptual feedback!
Have you considered having your Shell view contain either a ContentControl or a ItemsControl so that you can programmatically load different views. These different views could then contain regions or whatever you wanted.
I'd also remember that PRISM is likened to a buffet, you can pick and choose which parts to use. Once you look at ItemsControl and ContentControl consider what regions offer.
Treating Prism regions like Master pages seems to always lead to confusion. It is not designed (like ASP.Net) to potentially render a new shell around every page that appears. That was created for a Browser -> Server -> Browser model where the page is recreated on every request.
To implement a master page style scenario all you are really doing is providing a choice of outer shells that have the same region names defined, but in different visuals or positions. Changing the shell via an element/region in the root visual will cause all the child regions to repopulate in their new homes.
Personally I treat Silverlight more like I would a desktop application and less like a website. I dropped the idea of Master pages (as it feels backwards) and just use dynamic styling for overall changes.
Hope this helps.
The following thread deals with a similar situation. I hope it is useful.
http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=671911.
Thanks,
Damian.
I have an App which has a Tasks tab and a Projects tab. I decided to make a separate ViewModel for each of the tabs, TasksViewModel and ProjectsViewModel.
The Tasks tab has a new task area with an associated project pulldown and the Projects tab (obviously) has a list of projects.
What I'd like is for the pulldown on the Tasks tab to share the same collection as the Projects tab list so that any time I add or remove a project on the Projects tab the list on the Tasks tab is up to date automatically. This worked well with a single ViewModel but it was beginning to become quite unruly.
Should I not have split into two ViewModels? Is there a common method of sharing data like this? Perhaps pass the same ObservableCollection<Project> into each of the ViewModels? Perhaps some type of notification back to the TasksViewModel along the lines of ICollectionChanged.
Appreciate any insight/input!
The easiest solution here is often to use some form of Messaging Service to pass information between the two ViewModels.
For example, the MVVM Light Toolkit provides an IMessenger interface for situations like this.
Using a good IoC or DI toolset can help in this situation, as well. That would let you inject the project collection dynamically into both of your ViewModels, allowing a shared collection to be used in both Views.
It seems to me that your concepts of "Tasks" and "Projects" are part of your model, not part of your view model.
Consider this conceptual exercise: Suppose your app was written so that two users could use your application on two separate machines against a shared database, and one user adds a Project:
Would it be a good or a bad thing if the Project immediately showed up in the dropdown on the Tasks tab of the other user's screen?
Would it be a good or a bad thing if the Project showed up in that dropdown after the first user hit "Save" or "Commit" or "Ok"?
If the answer to either of these questions is "a good thing", your data is really part of your model not your view model. And it should be handled as such.
Your view model should incorporate your actual model by reference, and it is a good thing to share the model objects between view models as much as possible. In fact, ideally most of your application has a single set of model objects. The exception might be a dialog box where you want to be able to make some changes but then hit "Cancel" and not save them. In that case, the "Ok" button would copy data from the model maintained by your dialog box into the main application model. In this case the model objects used by the dialog and by the main application are different instances of the same class.
Now let's consider the case where you answered "a bad thing" to both of these questions. This would be an application where you never save your "Projects" list back to the main database/document/whatever, but it is a transient list used only for temporary work. In that case it would really be a view model, and I would attach it to the application (or whatever scope was appropriate) and have the two tabs access it.