mantra-cli icon indicating copy to clipboard operation
mantra-cli copied to clipboard

Scaffolding?

Open aadrian opened this issue 8 years ago • 8 comments

Hi,

Any plans adding scaffolding support?

Thank you.

aadrian avatar Feb 22 '16 14:02 aadrian

What sort of implementation are you thinking?

sungwoncho avatar Feb 26 '16 23:02 sungwoncho

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.

aadrian avatar Feb 27 '16 09:02 aadrian

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

sungwoncho avatar Mar 25 '16 01:03 sungwoncho

@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..

andreyantipov avatar Mar 30 '16 13:03 andreyantipov

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.

aadrian avatar Mar 30 '16 13:03 aadrian

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.

  • mantra g model users - generates Users collection and publication.

sungwoncho avatar Mar 30 '16 22:03 sungwoncho

@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.

aadrian avatar Mar 31 '16 08:03 aadrian

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:

  • the posts module under the client/ folder
  • the module would have the show, index and form containers/components
  • the module would also have a set of actions for the create, edit and delete methods, which would be generated under the server/methods/ folder
  • the collection's definition under the lib/ folder
  • two publications: one listing all posts and the other for the title and content of a given post
  • the routes.js file for the new module with the definitions for each route and their corresponding container/component

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.

srbdev avatar Apr 21 '16 04:04 srbdev