Is it possible to use 2 yeoman generators in a single project? I want to use generator-angular and generator-node-express-mongo in a single project. Is this a good idea or its much easier to go with 2 separate projects?
The simple answer is YES. But some cases need to take in account like the use of two different JS-MV* frameworks like Angularjs and ember or build systems like gulp and grunt
Check this answer too:
Using two yeoman generators?
Related
I am new to WebJars and so far have failed to see any real advantages that they bring to the table compared to simply using Bower for example. What justifies the idea of putting frontend JS into backend JARs?
Please name at least one or more "objective" advantages to using WebJars.
WebJars are useful when you have a JVM-based project and you want to use only one dependency manager / build tool.
I would like to make a custom generator with the latest version of yeoman, but I'm having some difficulty. I've been digging around various sources of documentation and examples (like the webapp and angular generators), but I still have a few questions.
What is the workflow for testing a generator? If I have one project that is the generator itself, do I keep making new directories to run yo my-generator?
Has the generator framework changed at all with the beta of yo 1.0? Have there been breaking changes?
How does a generator register itself with the global yo binary?
Thanks.
This question is a few months old, but I think it's useful for anyone who finds it now to know that much more has been explained in http://yeoman.io/generators.html
Question 1:
Testing your generators locally can be easily done. For instance if your generator is called "generator-mtv-raps"
$ cd ~/dev/generator-mtv-raps/
$ npm link
Now if you do:
$ cd ~/dev/mytest/
$ yo mtv-raps
It will build.
Additionally, unit testing your generator with mocha is pretty straight forward. There is a set of test helpers built in. The basics of what you need to be testing against can be found in generator-webapp's tests https://github.com/yeoman/generator-webapp/blob/master/test/test.js
Test that the generator can be required without breaking.
Mock your prompts with helpers.mockPrompt
Test that all the files you want created are created via helpers.assertFiles
Test that the prompt values you mocked are inserted into the created files.
Number 4 is kind of tricky, the array of expected files can be passed a regular expression to check against. If you want to know more about the test helpers, the source is the best place. https://github.com/yeoman/generator/blob/master/lib/test/helpers.js
Question 2: already answered by btford
Question 3:
Generators are bound to yo by installing them globally (or linking them as above) and using a naming convention. All generators start with "generator" then "-" then "name".
hence generator-mtv-raps accessed via $ yo mtv-raps
What is the workflow for testing a generator?
I'll be working on this in the next couple of days for generator-angular. You can track my progress on Github. Unfortunately, there aren't too many examples yet because of the transition from one yeoman command to using yo alongside bower and yo. I imagine there will be some level of unit testing on the Generator.prototype.method, as well as E2E testing that involves writing bash scripts to run yo, npm, bower, and grunt.
Has the generator framework changed at all with the beta of yo 1.0? Have there been breaking changes?
In my experience porting over generator-angular, I haven't seen too many changes. There is a new, optional simplified API, which may be useful.
How does a generator register itself with the global yo binary?
The answer right now is that it doesn't. You install/use generators in a project directory. I somehow had it working due to an errant symlink, but that's not the recommended way of doing it.
What is the best way to organize directories within a large grails application?
In a typical Spring application, we'd have myproject/domain/ and myproject/web/controllers and myproject/services
Since grails puts these artifacts in their own directories... and then just uses the same base project package for everything, what is the best practice? Use the same sub package name for domain objects, controllers, services too?
Ken
Use packages like any other app. Classes for com.mycompany should go in myproject/grails-app/domain/com/mycompany, myproject/grails-app/services/com/mycompany, myproject/grails-app/controllers/com/mycompany, etc.
Decide on your package structure as makes sense for you. Split on component type or on functionality type (but I recommend functionality type).
I don't see a difference here from the structure you mentioned.
I have a project with a RESTful Rails back-end and a Flex front-end, first time for me with this combo and I debating whether to put the flex source somewhere inside the Rails folder hierarchy or making it a separate project. If I do so which folder would be most suitable /lib?
Also be doing one click deployment with Vlad which can also compile the flex app and dump it in the public folder.
Or does anyone have any good reasons why the flex project shouldn't reside within the Rails folder hierarchy?
Cheers
From personal experience, it's fine in the Rails folder structure. We have a "/flexsrc" folder a the rails project level in git, and when we build, the swf and related files are dumped to the /public area. It's been this way for a while, and there's no apparent drawback.
I think it would be more of a hassle to have two source depots.
(disclaimer, I've only used Flex with PHP and Java, I'm not terribly familiar with Rails so I can only really address the last part of the question).
My general experience is that it is best to keep both Flex and its hosting server components in the same source tree and svn project. Unless you have reason to believe that you are going to need a different server at some point, I can't really imagine any reason why you wouldn't want to:
Keeping them in the same project makes it easier to automate builds (in Java definitely, and it sounds the same in Rails).
If they are in the same tree, then it is easier for other developers to work on the same code without using SVN externals.
Placing them as separate projects can complicate compiler arguments for RemoteObjects and the like
This is the way I do it:
AppRepo
FlexAppFolder/
RailsAppFolder/
I like the Glenn's approach, but as ChrisInCambo said he's using a RESTful Rails back-end, which means that Rails has a bunch of services to expose and which means that the services could be consumed from different clients (front-ends), maybe not now, but in a future.
Another approach could be
RailsAppRepo
FlexAppRepo
and if you're using git you can do:
git submodule add backend git://your_backend_repo
or an svn external
Any ideas?
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .