Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Scaffolding? #7

Open
aadrian opened this issue Feb 22, 2016 · 8 comments
Open

Scaffolding? #7

aadrian opened this issue Feb 22, 2016 · 8 comments

Comments

@aadrian
Copy link

aadrian commented Feb 22, 2016

Hi,

Any plans adding scaffolding support?

Thank you.

@sungwoncho
Copy link

What sort of implementation are you thinking?

@aadrian
Copy link
Author

aadrian commented Feb 27, 2016

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
Copy link

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

@andreyantipov
Copy link

@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
Copy link
Author

aadrian commented Mar 30, 2016

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
Copy link

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.

@aadrian
Copy link
Author

aadrian commented Mar 31, 2016

@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
Copy link

srbdev commented Apr 21, 2016

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants