is it possible to configure the base directory of a sails app? At the moment everything is in the root './', but I want to use something like './server/'. So that every files and folders for sails are in that directory, e.g. config, views, controllers, api etc.
How is that possible? Didn't found a solution...
Best regards,
Kersten
You can use the appPath configuration option to set the path your app resides in.
There are a few different ways you could do this. One would be to pass in the appPath while lifting sails
sails lift --appPath=<path>
Another is to set the appPath in your .sailsrc file
{
"generators": {
"modules": {}
},
"hooks": {},
"appPath": "<path>"
}
Related
I am building a project on Vercel, deployed to multiple subdomains. The code should be 99% the same, but I need to have a different manifest.json for each subdomain.
Is there a way to make the manifest.json file dynamic, based on the subdomain the user visits?
I thought perhaps NextJS rewrites could help, but I am not sure how to use them.
I wasn't able to figure out how to serve /manifest.json, but at least I can return a JSON file from a NextJS Serverless function at api/manifest like so:
res.setHeader("Content-Type", "application/json;charset=utf-8");
return res.send(manifestJSON);
I'd like to use something that automatically labels images into an sap Fiori app. I found that Cloudinary has an add-on called Google Auto Tagging which should suit well for this purpose. So I followed this guide to use Cloudinary javascript SDK in my controller files of the webapp, and I installed in my PC the javascript SDK but then I'm not able to import Cloudinary library into my project.
I tried to create a zip with the "cloudinary-core" folder, imported it into my project and include "cloudinary-core.js", but I got the error Cannot read property 'Cloudinary' of undefined.
I also tried to include "cloudinary-core.min.js" which should be, from what I understood, the standalone minified version of the library, but had same error.
This is how I'm trying to import the library:
/* global cloudinary:true */
sap.ui.define([
"sap/ui/core/mvc/Controller",
"mdonamcve/libs/cloudinary-core/cloudinary"
], function(Controller, cloudinary) {
"use strict";
return Controller.extend("mdonamcve.controller.MainTable", {
onInit: function() {
var cd = new cloudinary.Cloudinary({cloud_name: "demo", secure: true});
},
...
};
}
I checked the path and it's correct, but "cloudinary" remains undefined.
Cloudinary SDK can be used for sap Fiori apps, right? Am I doing something wrong? Are there any alternatives to Cloudinary in case the latter doesn't work?
If Cloudinary doesn't use UI5's way of defining modules there is a high change that undefined is passed to cloudinary.
The global name of Cloudinary seems to be cloudinary. To not overshadow that just pass a slightly different name when defining your controller:
sap.ui.define([
"sap/ui/core/mvc/Controller",
"mdonamcve/libs/cloudinary-core/cloudinary"
], function(Controller, Cloudinary /* now with a capital C */) {
This way the globally available window.cloudinary (or just cloudinary) should also be available in your controller. Cloudinary (with a capital C) will still be undefined and can be ignored.
Reference: This blog.
Since you need to use a Cloudinary add-on which requires signing the request, this is to protect you from others abusing that add-on. The easiest solution might be to use the Upload Widget. You will need to also have an endpoint to one of your servers that signs the request before uploading. Everything should be documented here:
(https://cloudinary.com/documentation/upload_widget#signed_uploads)
I have been looking for a solution for this for days and nothing I have tried worked so far :(
We want, in addition to the vendor folder, to have a lib folder where to store own libraries which shouldn't be managed by composer. All namespaces/classes should be automatically loaded.
We don't want to make modules out of these libraries, as they are unrelated to the display (we have a database library, for example).
I have tried:
application.config.php:
'module_listener_options' => [
'module_paths' => [
'./module',
'./vendor',
'./lib'
],
...
]
But doesn't work... Is what we want even possible? Or is it correct but needs more steps to work? I have found plenty of information on how to load a single class/library that is inside the vendor, but none on how to add a autoload path to autoload everything from a directory outside vendor.
Those libraries we have right now in vendor, the problem we have is that we modify the files regularly and every time we want to run composer, he wants to override all our changes...
What is the correct way to deal with this situation?
Any advice/info would be super helpful!!!
Gioia
You must add in your root/autoloader.php a statement to load your library. Eventually you have to write a autoload.php at the root of your library.
I am having trouble understanding the rules to ACL in ZF and the docs aren't clear. I am using a common Zend library for all websites. So far no problem but now every demo or example says that you should place the ACL class (acl.php) in the libraries directory as a plugin. Zend/Library/My/Controller/Plugin/.
I don't want to do this because it defeats the purpose for sharing a common framework directory.
Has anyone done or have any ideas about how to accomplish ACL using individual acl.php class files for each website/web application?
Thanks
You don't have to place the acl.php in the libraries directory as a plugin. The autoloader will load the class just fine, the trick to Zend_Acl is just priming an instance of the class with your roles and resources.
It's been a little while since I touched Zend Framwork but I'll try to steer you in the right direction.
In your bootstrap, create the Zend_Acl object
$acl = new Zend_Acl();
//see documentation on how to add roles and resources
Now create a Plugin folder inside your Controller directory, this will allow you authenticate with your acl.
Inside there create new class that extends Zend_Controller_Plugin_Abstract give it the correct class name to be picked up by the autoloader.
Store the acl you create in the registry and in your plugin override the preDispatch method, from here you have access to the request and the acl (from the zend registry) you can validate as needed. (Some people have controller/action as resources others models. It's quite freeform.
Register your plugin with the front controller.
$frontController->registerPlugin(new My_Controller_Plugin_Acl());
This is probably what the other tutorials are suggesting (or variants of this), it can just be a little confusing sometimes.
You should never add files to your Zend library directory - do you have any links to tutorials recommending this? The files should either go in the library directory under your application's namespace, giving you a structure like:
application/
library/
Zend/
(ZF files)
Foo/
Controller/
Plugin/
...
or in application/plugins, application/controller/helpers or somewhere else depending on the approach you are taking.
Edit: it sounds like a controller plugin is what the tutorial is recommending, in which case you'll want a class like Yourapp_Plugin_Acl (replace 'Yourapp' with your app's namespace) which would live at application/plugins/Acl.php.
Ultimately, you can place it anywhere you want as long as your autoloader is sufficiently configured to find it. And precisely how you use it depends upon what resources and privileges you are trying to protect.
But think you are confusing instantiating your ACL and querying your ACL.
You will most likely instantiate/populate your ACL object during bootstrap and store it in the Bootstrap registry or in the Zend_Registry singleton.
If your resources are controllers and your privileges are actions, then it is common to intercept the dispatch cycle with a preDispatch() plugin that queries your ACL object.
So, we are really looking at two different classes/objects:
One is the ACL itself, extending Zend_Acl. This one could be named Application_Model_Acl and placed in the file application/models/Acl.php.
The other is the front controller plugin. This one could be named Application_Plugin_Acl and stored in the file application/plugins/Acl.php
[Note that both of these presume that we are using an application namespace Application. Also, note that both of these are project-specific.]
Of course, the plugin as described needs to be given the ACL object in order to do its job, so your Bootstrap might have a method like this:
protected _initAclPlugin()
{
$acl = new Application_Model_Acl();
$plugin = new Application_Plugin_Acl($acl);
Zend_Controller_Front::getInstance()->registerPlugin($plugin);
}
But remember, this is only one way to use your ACL. In some cases, your ACL might not be limited to just controllers/actions. In that case, you might need to pass your ACL object to other models/services that query it, as well. In that case, you might have a separate method in your Bootstrap to create your ACL object and store it in the Bootstrap registry. Then your controllers - or even a dependency injection system - can grab it from there and pass it through to whatever downstream models/services might need it.
[You know, looking at my answer, it's not really different from that of #linead. Same idea, different words, but he totally got in first.]
I set up a Zend Framework application using Zend_Tool, but I wanted multiple modules (admin and default).
I moved the controllers, models and views for default into modules/default, then created an admin module and some controllers. I then added this line to my config file to specify the modules directory:
resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
Since doing this, I can't get my app to work properly. If I go to http://localhost/zfproject, it works (I get the index controller/action). If I go to http://localhost/zfproject/index/, I get 'Invalid controller specified (zfproject)'.
The same message appears when going to http://localhost/zfproject/admin. It seems to think 'zfproject' is the controller I'm specifying, despite that just being the folder the project is contained in.
Thanks,
Richard
This isn't a problem I've experienced before, but ZF should detect that it is in a sub folder and work accordingly. It seems that in your case it is not doing so. There is some stuff in the manual that might help you:
http://framework.zend.com/manual/en/zend.controller.router.html#zend.controller.router.rewritebase
it'd also be interesting to see whether the app works as expected when it is in the root directory, just in case there's another problem.