mantrajs / mantra-cli

Command line interface for building Meteor apps with Mantra
MIT License
135 stars 33 forks source link

Scaffolding? #7

Open aadrian opened 8 years ago

aadrian commented 8 years ago

Hi,

Any plans adding scaffolding support?

Thank you.

sungwoncho commented 8 years ago

What sort of implementation are you thinking?

aadrian commented 8 years ago

What sort of implementation are you thinking?

Right now the tool only generates, "almost empty" files for most cases. It would be even more helpful if it could fill in where it's possible, or where the user has the information, in form of model fields, values in the DB, etc.

sungwoncho commented 8 years ago

That will work inasmuch as we don't get too opinionated. PR and ideas welcomed.

andreyantipov commented 8 years ago

@sungwoncho

That will work inasmuch as we don't get too opinionated. PR and ideas welcomed.

How exactly can i help it?

I'd like to participate in this. Especially to bring some partial cli functionality like it did in Rails

Mantra routing, mantra models..

aadrian commented 8 years ago

IMHO Grails did Scaffolding quite well: combination of dynamic and static scaffolding, even at a later time in the project, and also the possibility for the users to modify the scaffolding templates (to fit with the CSS framework/Theme required markup).

This is the main reason we use Grails in so many projects (despite other disadvantages): the productivity gain (even in projects with many iterations and changes) is fantastic.

If Mantra-CLI could boost Meteor in such a way, Grails Scaffolding does Grails, it could become a serious adoption motivator for Meteor for a whole new group of users.

sungwoncho commented 8 years ago

Okay I see where we are headed. We have some ideas but they are vague at best. I think we need to brainstorm some examples of commands and their possible outcomes.

e.g.

aadrian commented 8 years ago

@sungwoncho see Grails commands for an example (the quick reference): https://grails.github.io/grails-doc/latest/ref/Command%20Line/Usage.html

create-app
create-command
create-controller
create-domain-class
create-functional-test
create-integration-test
create-interceptor
create-plugin
create-script
create-service
create-taglib
create-unit-test 
generate-all
generate-controller
generate-views

Might be interesting the distinction between "create" vs "generate":

Create makes an "initial" stub (by no means complete), but based on available info: e.g. create-domain-class mymodel1 will make an empty model. and another one: create-domain-class mymodel2 and than calling: create controller [TAB] it will know to do completion the available models with their correct path.

If the user adds some fields the application might be already usable (using dynamic scaffolding)

If the user calls, e.g. generate-views [TAB] than do completion for the model name, it will generate a static version of the views for that model.

These are all for Model/Domain specific to the user's work, not those required by the various plug-ins. Plug-ins themselves might install (dynamic or static) controllers/views/models. For the generation of model of the plug-ins, there are usually extra commands that allow the user to map to different names.

srbdev commented 8 years ago

I wonder if this counts as too "opinionated" but consider the following command to easily get up and going for a prototype CRUD application:

$ mantra g scaffold posts title:string content:text

It would create the following:

I think that covers it all. It could start by supporting the recommended libraries, i.e. FlowRouter for the routes but eventually become extensible whereas the developers could create their own templates for their library of choice; thus, removing mantra-cli's opinion.