I have created a module to manage my CRUD scaffolding. I currently define a context which I define for all my "collections" based on the URL in the router. ie: #/posts/admin tells me the collection is posts and my scaffolding is a list #/posts/admin/edit/xxxx is scaffolding for editing post xxxx. For each type of scaffolding I defined list of fields and actions. It is working fine but I would like to replace with with States from NGXS.
My thinking would be to define a base State for each scaffolding screens and then for each collection to create a substate.
How do you create a State which can be extended with its own set of actions.
Related
I am trying to decide on the best solution to loading form options dynamically with a restful api approach in mind. Im using laravel for the back end and Vue components to handle the frontend that live inside blade templates where necessary.
Currently my controllers all return a blade view that contains Vue components which handles all the front end stuff such as forms etc. So I am just wondering what the best approach would be to loading options for a select. I've thought of a few ways:
Pass the options necessary to the view and define them as props on the component.
Keep it as is and when the vue component loads go and fetch options via an api endpoint.
The problem with approach 1 is that my components are tightly coupled to the view it belongs to and I have to make sure in every controller that returns a view where a component requires some options i would have to pass down a potentially random set of collections to the view for example a collection of companies and roles could be passed down to the user edit view and assigned as props which can bloat the controller and cause confusion where it's not immediately clear what those collections are intended for unless you go to the component that's using them.
With approach 2 I can have a generic select component that takes a url as a prop and can easily reuse it everywhere with v-model. The problem with this approach is it doesn't feel right to have an entire route dedicated to return a different structure of an existing route for example:
/api/company/1/users -> returns array of entire objects and relationships
/api/company/1/users/options -> returns array of only id and name
The best solution I could think of is to go with option 2 and use the original route but with a parameter to determine the response structure:
/api/company/1/users?options=true -> controller checks for options and returns option version of users instead of all attributes+relationships.
So is there an ideal approach to handling this? Both approaches work but I'm hoping to get some advice on the best approach or there might be another way I haven't thought of.
Thanks.
I'm new to MVC pattern and Sails. From my understanding, it seems like I should create a controller for each model. A controller is like one page.
So, if I want create a page containing product category, product list and user authentication, there are 3 models in my page. How should I structure the controllers?
You don't have create separate controllers for each model.
Controllers handle the request from the client and return views, JSON, etc.
You may be being influenced by how sails documentation explains things due to their blueprints.
Mvc does not require a 1 to 1 of controller to model. Your controller should take care of massing the data and rules needed to show your view or a group of different views. A controller may have a link to a group of your functionality e.g. user management where you handle registrations, login, forgotten credentials etc. This may require a few different models and not just your user model. It may also display a number of different views too.
Sails.js comes with blueprints enabled which means a user model will have create,update,find,findone etc against a user model. Infact sails doesnt need a controller in this instance but you could make one to over ride logic or add additional logic. There is however nothing stopping you calling a user.find method in the user controller as well as a pets.find. Just think of the controller as the conductor telling and calling everything to fire and bringing this information together to push into a view or number of views.
I have a fairly large prism app and am trying to app a new feature. The feature is a serial port parameter selection.
I want to refresh the list of serial port names when my viewmodel's IsActive property is set to true. This is happily achieved in a sample but reality is...different.
The view i am modifying is contained in an ItemsControl (marked as "SettingsRegion") which is contained in a parent region ( marked as "PageRegion"). Settings region contains settings views from other modules.
I want to use the SyncActiveAwareAttribute for this but it requires scoped regions.
Do I need to use view injection (regionmanager.Regions["blahblah"].Add(....) here or can i get it working using view discovery (regionManager.RegisterWithRegion(...)?
If I have to use injection...
Given that the other modules would need a reference to the scoped IRegionManager instance in order to inject their views:
how is the best way to get the region manager to the other modules?
when should injection take place to ensure that the region exists?
can i mix-and-match injection with discovery? I want to avoid a big refactor.
In order to create Scoped Regions, you would need to use View injection. Related information can be found in the following MSDN Prism Chapter #7 links:
When to Use View Discovery vs. View Injection
Creating Multiple Instances of a Region
The Scoped Region Manager is returned by setting the createScopeRegionManager overloaded parameter as true on the Region.Add() method. You would perform this action in the same place you usually add or register Views into Regions like on the corresponding Module's initialize() method:
IRegionManager scopedRegionManager = scopedRegion.Add(view, null, createScopeRegionManager);
Then, one possible way of sharing the scopedRegionManager to other modules would be to Publish() an event with the scopedRegionManager as a parameter. However, you should be careful with Module dependencies and the Modules instantiation order.
Another approach would be to store the scopedRegionManager into for example, a Dictionary. You can find more related information in the following CodePlex thread:
Scoped Regions in TabControls
It should not be any problem by using View Discovery on other Views registration that would not present Scoped Regions.
I hope this helped you,
Regards.
I've been using Ember for a while but still struggling sometimes to find out the best practices. So one of the Ember ways regarding controller and view is
an opinion of Ember's designers, that is enforced by the router is that for a given BaseName (e.g. "Application," "CustomerEntry," "My Items") there should be a BaseNameView and a BaseNameController. -- Ember guide
The problem is that what if I want multiple instances of the same view on a page. Since the controller is created during initiation of the application, they are singletons under the application namespace, which will not be able to hold two instances of the model data.
One solution I see is to create controllers(and model data) manually and pass them to views. But in this case, I'd like Ember not create controllers automatically for me. Put it another way, why would Ember creates controllers as singletons during application startup.
I think there are many use cases where a View type doesn't have a corresponding Controller type. Especially when the type of view is more like a UI widget than a full-fledged application feature. Many views can share the same controller. Take a look at this applicationView template:
<h1>Here are two files, compare them</h1>
{{view App.MyFileView contentBinding="leftFileContent"}}
{{view App.MyFileView contentBinding="rightFileContent"}}
This creates two instances of my view class and binds their content properties to two different properties on the applicationController. The controller property for both of those views is set to the singleton applicationController instance.
One possible reason why controllers are singletons could be that they're able to be addressed in the global namespace via something like App.router.myController.
I have an entity framework generated Model. When the model is initially created I only want to require a few properties, but afterwards I want to require a few more. Is there any notion of validation groups or conditional validation attributes that would help me here?
I tried writing a custom conditional validation attribute that would just take another validation attribute in its parameter and just encapsulate other validation attributes but I get compiler errors saying "An attribute argument must be a constant express, typeof expression or array creation expression of an attribute parameter type"
Any idea how to accomplish this?
I have an entity framework generated Model
That's nice but not something that controllers should pass and take from views. In order to decouple the domain entities which, in theory, should be reusable among different applications from the way those entities are presented on a given view you could use view models. Those are classes which are specifically designed to the requirements of a given view. Thus you could have a CreateFooViewModel and UpdateFooViewModel both representing some domain model but of course with different validation rules (as validation rules differ between your views) and different formatting rules and properties selection. In order to ease the mapping between your view models and domain models you could use AutoMapper.