What I am trying to understand is: If after creation of express -v pug -c sass projectoName
is it possible to add views using the scafold Express-generator. For example, a partial for the footer, another for the navbar and so on...
In short: How to add a new page with the tool?
The express generator is a tool for the initial app creation and configuration. It creates a basic app structures, configures the view engine, the css engine... But it stops there.
Once you have made the command express -v pug -c sass projectoName, you are done with the express-generator. If you want a new view (complete or partial), you have to create a new file (a pug file in this case) in your views folder, manually.
It is not like the Ruby on Rails generator for example which can generate views, models, or scaffold a full CRUD.
There are other frameworks, like Sails.js (based on express.js) which have a command line interface and a generate command.
Related
I find myself use command scaffold to generate a template for a new module.
However, as I use it a lot, I need to tediously delete some files or some codes in order to make it into a structure I like most of the time. For example, I always delete control and demo folders, change some codes in init and manifest files, and add icon.
Is there any way I can do the modification and save it into the scaffold command so that every time I call it, it will generate according to my modification?
You can use scaffold -t or scaffold --template with your original source module name.
For example, build your template module and delete folders that you don't want to generate from scaffold.
Afterwards, pass that template module name when you generate a new scaffold module.
scaffold -t template_module new_customer_module_name destination_module_path
OR
scaffold --template template_module new_customer_module_name destination_module_path
My changes are not reflecting inside browser even after storage/framework/views clear and running various artisan clean-up commands.
To make clear that I am calling the right file.
Is it possible my PHP environment is somehow persistent loading this file?
I found the answer.
I am using Nwidart/LaravelModules to structure my project.
Laravel Modules has a command that publishes all modules to the views folder in resources/views. Apparently Laravel was using those 'published modules' alongside the 'official' modules, which caused the problem above.
I'm using sails(http://sailsjs.com) to develop a little platform. Everything goes smoothly following the documentation. But being new to this javascript frameworks world and npm etc etc, i've been having a trouble including other node_modules and use them in the .ejs views...
I understand not all modules are to be included in the views but how can I manage to include some?
Trying to use https://www.npmjs.com/package/vue-slider-component
Thank you in advance and sorry if this error is just plain out stupid.
Your confusion is understandable. The issue is that, until relatively recently, things installed in node_modules were solely for use in the back end code; that is, your Sails.js controller actions, models, etc. After all, the node_modules folder has the word "Node" right in it, and it was created for use with NPM (the Node Package Manager) to help organize Node (i.e. server-side JavaScript) files!
While many front-end plugins were (and still are) published on Bower, newer frameworks like Angular 2 and Vue often publish their plugins to NPM because it reduces the number of moving parts for your app. The problem is, if you try to require('vue-slider-component') in your server-rendered .ejs view, the server (i.e. Sails.js) will try and load and run that code before it renders the view, where what you really want is for that plugin to run in the browser.
The long-term solution is to use something like Browserify or Webpack to compile all of your front-end JavaScript files into a "bundle". So for example if you have a file like assets/js/my-vue-app.js that includes the line:
import vueSlider from 'vue-slider-component/src/vue2-slider.vue'
then Browserify will see that line, load up that vue2-slider.vue file, add it to the top of the my-vue-app.js file, perform some other magic, combine it with your other front-end .js files and output a file like browserified.js which you would then include via <script src="/path/to/browserified.js"> in your HTML.
Since new Sails apps use Grunt to organize and inject those <script> tags into your views for you, it can be kinda confusing as to how you would get something like Browserify or Webpack to work with Sails. For Sails 1.0, there's a seed project for using Webpack instead of Grunt. For Sails v0.12.x, you'll have to Google around to find some examples of using Broswerify or Webpack with Sails.
A short-term solution, and probably not as maintainable in the long run, is to save the contents of the minified vue-js-slider component into your assets folder (e.g. as assets/js/vue-slider-component.js), add it to your HTML with <script src="/js/vue-slider-component.js"> and access it in your code as window['vue-slider-component'].
In Sitefinity WebForms you have a ResourceLinks control allowing you to combine multiple, but what do you use in MVC layouts?
I'm not sure if the razor helper #Html.StyleSheet will do the job?
Adding all the CSS files to the Global folder in App_Data\Sitefinity\WebsiteTemplates[template_folder]\App_Themes[theme] will automatically add them to the site, but won't combine them.
We're working with Sitefinity 8.x and looking for a definitive way to compress and combine JS and CSS, but the pickings seem slim.
With the move from webforms to mvc, Sitefinity didn't include specifically introduce a new bundler or something so you're left with essentially 2 default options, but they've seemed to have opted for approach #3.
1) Use .less and .sass to pre-process as part of your build process.
So in your theme folder you would have a global.less (or scss or sass) that essentially combines them using the #import directive.
Install a VisualStudio extension like Mad's Kristensen Bundler and Minification VS Extension (previously part of WebEssentials) and then define in the VS settings that it should compile and minify on build.
Then every time you build or publish, your one bundled-and-compressed .min.css will be available for Sitefinity.
2) Second option would be to use default ASP.NET Web Optimization.
Where you define static bundles in VisualStudio and then use these bundles by means of #Styles.Render or #Scripts.Render to output them.
3) Lastly a new way has been added with the new Feather approach, which uses the current fashionable approach of Grunt to bundle and optimize your styles and scripts.
In the /ResourcePackages folder you'll already see a gruntfile.js file which has a task you can run which can then compile (and can be extended to prefix, bundle, minify, etc) your .sass into a .min.css which you can then add to your solution.
A sample can be seen here (https://github.com/Sitefinity/feather-packages/blob/master/Bootstrap/gruntfile.js)
I'd use a combination of the above approach to receive the maximum result with Sitefinity where you use option 1 to have VS build out your core/base CSS and JS and then include them using Web.Optimization.
Any additional page or widget related styles or JS can then be included afterwards manually through the css widget which gets compiled through option number 3.
Once you get more familiar with this new approach you can create and load optimized .css and .js on demand - even using a RequireJS approach to load them depended on the widget dragged and dropped on the page. RequireJS might seem out-dated given the latest gadgets and gizmo's but with v9.0 its still being used by Sitefinity itself to add inline-editing functionality.
Let me know if you need more info on option 3, I'm happy to extend my answer with some code snippets, or sample scripts on how I've tailored them.
I'm trying to create a custom release burnup app for my group. There is an existing app called 'Release Burnup' in Rally, and based on the instructions for rally-app-builder I thought I would be able to clone this app as a starting point.
However, when I use the rally-app-builder clone RallyApps ReleaseBurnup command, it doesn't seem to do anything except change the title in the output html files to "Son of ReleaseBurnup". When I tried the same thing with the example from the github page (which uses rally-app-builder clone RallyApps StoryBoard) then it seems to be successfully cloning an app, with updates to the App.js file, etc.
I'm guessing that I might be using the wrong name to clone, but I'm not sure how to know what names are valid for this command to clone the app I want.
Unfortunately rally-app-builder clone functionality predates newer developments and the availability of source code of catalog apps from RallyApps/app-catalog, so it does not support drilling down those directories.
clone RallyApps StoryBoard works because there is a StoryBoard app at that location. There is no ReleaseBurnup there. ReleaseBurnup code is not available.
Here are the steps to build an app from javascript source files from GitHub app-catalog repository
Prerequisites:
Node.js
rally-app-builder
Get the source to a local directory (you may either fork the
app-catalog repo, or download zip from the same location):
in terminal, cd to the directory of the app you want to work on, and call this command:
rally-app-builder build.
As a result a deploy folder is created with App.html and
App-uncompressed.html inside, and App-debug.html is created in the
root folder of the app.
These steps make sense only if you intent to customize the catalog app and want to use the source as basis. If you want to use a catalog app as it was designed, install the app directly from the AppCatalog as described in this help document.