I have a working VueJs application, and when a user logs in, he gets some rights from the server like administrator, readOnlyUser, worker etc. Based on these privileges, some components/functionality in the application should be or, should not be available to the user. For an example I would like to put a reference to an access-right method on my differenct components/divs:
<MyComponent v-if="hasRights()"></MyComponent>
Or just access this method from the script section.
I am thinking of using mixins, this seem to suit my needs, but is mixin´s the right way to solve this issue? Are there another more patten-like correct way to do it?
My recommendation for architecture:
Create files per rights:
Admin.js
User1.js
User2.js
etc.
Now you can create a function (wherever that takes in the user from your server, and then referes you to the right file. By doing this you can call in . your components: this.$config.get().displaySomething . Where the get() knows which file to go to. Make your config available on bootstrap.
The reason I don't recommend vuex is since it sounds like your config is static and can just be hard coded into file.
Related
I studied the documentation for automatic global generation of base components but it is confusing. Can anyone please explain it in detail?
You can use require.context() in order to resolve a directory where components live during webpack's build process. this exposes to you, within the browser, the list of files in that directory. From that, you can use some magic to automatically register them, here's an example:
const files = require.context('./components', true, /\.vue$/i);
files.keys().map(key => Vue.component(key.split('/').pop().split('.')[0], files(key).default));
So in the above, we've said that we want webpack to create a context for us of all files in the './components' directory. From there, we can loop over all the keys of the files (which represent the file name) and register them with Vue.component(...)
I recommend watching this video:
https://www.vuemastery.com/courses/real-world-vue-js/global-components
First you can understand why you may want to use global components, then why you would want to automatically global register those components, and then what the registration code (taken from the following link) actually does.
https://v2.vuejs.org/v2/guide/components-registration.html#Automatic-Global-Registration-of-Base-Components
Does Vue.js have an idiomatic way of declaring application-wide globals like baseUrl and then referencing them throughout the app (for API calls etc)?
If so, what is the best way to configure such globals at build-time to create development, test and prod instances? For example, I imagine doing export BASEURL='http://dev.myapp.com', running a build and getting an app with this baseUrl configured. This would in turn allow me to create automated builds for Continuous Delivery certain branches are updated (develop -> dev.myapp.com, master -> www.myapp.com etc).
Thanks!
What I do: use some state management tool, like Vuex.
If you don't want to add complexity to your app, I use a parent Vue instance, let say App.vue and define global data in that instance, then when I need that data from the parent I call this.$root.baseUrl in case you want the baseUrl. Notice that you can also call this.$parent.baseUrl but this will only work for direct childs, if you are inside a child of a child, you wont get the global data, that's why is better the $root object.
What's the best practice when you have dependencies that you want to be able to configure when creating a PowerShell module in C#?
My specific scenario is that the PowerShell module I am creating via C# code will use a WCF service. Hence, the service's URL must be something that the clients can configure.
Is there a standard approach on this? Or will this be something that must be custom implemented?
A somewhat standard way to do this is to allow a value to be provided as a parameter or default to reading special variable via PSCmdlet's GetVariableValue. This is what the built-in Send-MailMessage cmdlet does. It reads the variable PSEmailServer if no server is provided.
I might not be understanding your question. So I'll posit a few scenarios:
You PS module will always use the same WCF endpoint. In that case you could hardcode the URL in the module
You have a limited number of endpoints to choose from, and there's some algorithm or best practice to associate an endpoint with a particular user, such as the closest geographically, based on the dept or division the user is in, etc.
It's completely up to the end user's preference to choose a URL.
For case #2, I suggest you implement the algorithm/best practice and save the result someplace - as part of the module install.
For case #3, using an environment variable seems reasonable, or a registry setting, or a file in one of the user's profile directories. Probably more important than where you persist the data though, is the interface you give users to change the setting. For example if you used an environment variable, it would be less friendly to tell the user to go to Control Panel, System, Advanced, Environment, User variable, New..., than to provide a simple PS function to change the URL. In fact I'd say providing a cmdlet/function to perform configuration is the closest to a "standard" I can think of.
I'm building an express app in express 4.0 (rc3), since I'm starting from scratch and in development for a while, but if there's a way to do this in 3.0, that'd be welcome too.
What I want is a set of comment REST routes that I can attach to other routes in my API. So:
/posts/:postID/comments/:commentID
/profiles/:profileID/comments/:commentID
The way I was doing it was to encapsulate the comment routes into a module, including a buildRoutes(router) function in the module.
Then I can do app.use('/api/comments', commentController.buildRoutes(express.Router())) in my main server definition, and then in my profile module's buildRoutes(router), I can do
buildRoutes = function(profileRouter)
.... build the basic CRUD routes ...
profileRouter.get('/:profileID', show)
profileRouter.use('/:profileID', commentController.buildRoutes(express.Router()))
It seems like only the .VERB methods actually replace :wildcards in the route, and not the .use one. I could always muddle through with a piece of custom middleware that goes on a /api/profiles/* and maps the appropriate URL parameters into req.fields, but I want to make sure that this is actually required.
So this wasn't particularly easy to do the way I originally intended. However, I just avoided the entire problem by reframing my buildRoutes method to accept a baseURL and a router argument. Instead of modularizing it completely, now I say, profileController.buildRoutes('/api/profiles/', router) which in turn calls commentController.buildRoutes('/api/profiles/:profileID/comments', router), and so on.
It's not terribly satisfying (I would rather encapsulate path/routing information and hide that from the controller) but it works.
I am interested in loading some system params into the Yii::app()->params array from the database using a CActiveRecord extension called SiteSetting.
Unfortunately I couldn't find much advice online for this, but believe I can place a method in SiteSetting called loadSiteSettingsToAppParams and add the setting...
'onBeginRequest'=>array('SiteSetting', 'loadSiteSettingsToAppParams')
...to the config.
I would like to know if I can only add this onBeginRequest to the Yii::app() somewhere within the SiteSetting class (to keep my code modular) and whether this is a sensible approach.
Thanks in advance.
Just re-read your question now and I'd try to provide answers.
To the question "I would like to know if I can only add this onBeginRequest to the Yii::app() somewhere within the SiteSetting class (to keep my code modular)": the answer is, You're not restricted to just a Class. You could (theoretically) place it anywhere within your application and also in the config.php file.
As to whether it's a sensible approach, it depends on the time it would take to request those settings from the database and whether you're prepared to add that time to your HttpRequest response time. The onBeforeRequest is fired before every HttpRequest and if the loadSiteSettingsToAppParams method consumes lots of time, you're adding that time to your HttpRequest response time.
I'd advise that you fetch those settings once after login and then update them only when they change (the settings are updated). This way, you could place the call to loadSiteSettingsToAppParams in the UserIdentity class and call it after a successful login.
That's just how I'd go about doing this though.
Hope I helped.
The easy & nice way to accomplish this by using a comoponent like SettingComoponent and place in the components directory protected/components then pre load this component in the preload section like this preload => array('log', 'setting', ...). That's it and now you can call this component anywhere you want like Yii:app()->setting->whatever.
I hope this is answer can be useful for you.