Template proposal

Question

Template proposal

schmunk42 opened this issue 7 years ago · comments

I recently experimented with an web/API application template for Yii 2.1, see https://github.com/schmunk42/foxy-roxy-rabbit

One thing I'd really like to see is a src folder for the application source code only, eg. no runtime in it. It currently contains: 1 config, 1 controller, 1 layout, 1 view.

The public folder web just contains index.php

A controversial point might be pkg, a pro here is, that the root folder is much less cluttered. And that we can place files of any future package manager there, whether it's composer, npm/yarn or whatever.

I'd not recommend to use application tiers like in the current advanced app, if you want that - simply use this template multiple times and if you need to share code (formerly common) use (private) vendor packages.

This is just a proposal, feedback welcome.

Bonus: And there's also https://github.com/schmunk42/eucliid - which is a super-minimal template for CLI only applications, which can be converted to Yii 2.1.

Alexander Makarov · Answer 1 · Thu Nov 09 2017 05:37:31 GMT+0800 (China Standard Time)

I don't think there will be high demand on separate CLI template.

Alexander Makarov · Answer 2 · Thu Nov 09 2017 05:40:39 GMT+0800 (China Standard Time)

pkg is unusual and IMO is overkill.
Having src sounds OK.
config could be moved to the root out of src.

Tobias Munk · Answer 3 · Thu Nov 09 2017 05:45:41 GMT+0800 (China Standard Time)

I don't think there will be high demand on separate CLI template.

If it's not a separate template it's even better ;)

Tobias Munk · Answer 4 · Thu Nov 09 2017 05:54:59 GMT+0800 (China Standard Time)

About the CLI stuff, it would be sufficient to add a command, ie. AppController which can be accessed via yii app. Like the SiteController for web.

Speaking about that, let's think about an ApiController which could return something like

{"status":"ok"}

by default.

Bulat Damdinov · Answer 5 · Fri Nov 10 2017 23:43:00 GMT+0800 (China Standard Time)

I suggest a format for directories:

/src
/runtime
/web (or public)
/config
/database
/resources
/tests

And dotenv default support.

Tobias Munk · Answer 6 · Fri Nov 10 2017 23:53:08 GMT+0800 (China Standard Time)

What would be in?

/database
/resources

Bulat Damdinov · Answer 7 · Sat Nov 11 2017 00:24:17 GMT+0800 (China Standard Time)

@schmunk42

- /resources
  - /views
  - /messages

- /database
  - /migrations
  - /(other files for db)

Alexander Makarov · Answer 8 · Sat Nov 11 2017 00:30:06 GMT+0800 (China Standard Time)

Doesn't look good to me. Don't see why views and messages aren't part of the application as well as migrations.

Bulat Damdinov · Answer 9 · Sat Nov 11 2017 01:26:24 GMT+0800 (China Standard Time)

@samdark
Agree.

- /config
- /runtime
- /src
  - ..
  - /Migrations
  - /Resources
    - /views
    - /messages
  - ..
- /tests
- /web (or public)

Alexander Makarov · Answer 10 · Sat Nov 11 2017 03:38:59 GMT+0800 (China Standard Time)

That's better. Not sure we need resources dir though.

Alexander Makarov · Answer 11 · Sat Nov 11 2017 03:54:45 GMT+0800 (China Standard Time)

src
    assets <-- not sure, maybe worth moving to root
    commands
    controllers
    migrations
    messages
    views
    forms <-- form models
    records <-- ARs
    fixtures
    widgets
    helpers
config
    .env (ignored)
    .env.example
    main.php
    console.php
runtime
    logs
    debug
vendor
tests
web
    index.php
    favicon.ico
    robots.txt
yii <-- probably worth moving to bin similar to composer
.gitignore
readme.md
composer.json
composer.lock
codeception.yml
requirements.php

Robert Korulczyk · Answer 12 · Sun Nov 12 2017 22:42:30 GMT+0800 (China Standard Time)

I'm for renaming web to public - it is most popular convention right now: symfony/flex#56 (comment).

assets dir should contain only real assets (like JS and CSS/SCSS files) and src/assets only assets bundles classes.

resources may useful, but as a place for some additional stuff, like ERD diagrams, raw SQL, some screens etc.

yii <-- probably worth moving to bin similar to composer

Why?

Alexander Makarov · Answer 13 · Sun Nov 12 2017 23:01:24 GMT+0800 (China Standard Time)

web → public makes sense considering REST APIs.

Alexander Makarov · Answer 14 · Sun Nov 12 2017 23:02:10 GMT+0800 (China Standard Time)

No particular reason for moving yii.

Tobias Munk · Answer 15 · Mon Nov 13 2017 20:57:15 GMT+0800 (China Standard Time)

@samdark

Shouldn't fixtures and requirements.php be part of tests/?
What's about also moving codeception.yml to tests/? It's not required to be in the project root, like composer.json or packages.json...

PS: I made some slight adjustments on my personal prototype according to this discussion.

Alexander Makarov · Answer 16 · Mon Nov 13 2017 21:05:03 GMT+0800 (China Standard Time)

fixtures — definitely not since fixtures could be used from command line to fill database for development purposes.

Alexander Makarov · Answer 17 · Mon Nov 13 2017 21:05:31 GMT+0800 (China Standard Time)

requirements.php — not really, it's not part of automated tests. It is a one time script you execute to make sure server is OK.

Alexander Makarov · Answer 18 · Mon Nov 13 2017 21:05:51 GMT+0800 (China Standard Time)

Moving codeception.yml sounds fine.

Tobias Munk · Answer 19 · Mon Nov 13 2017 21:21:04 GMT+0800 (China Standard Time)

fixtures — definitely not since fixtures could be used from command line to fill database for development purposes.

I mean you can do that, but wouldn't migrations with development data be suited much better in such a case, while fixtures are used for testing?

Most stuff, I've found during a quick research refer (mostly) to testing...

requirements.php — not really, it's not part of automated tests. It is a one time script you execute to make sure server is OK.

But should it be part of an application template then? The framework repo has it already.
I would be nice to have a vendor/bin/yii command which runs the checks, btw.

Alexander Makarov · Answer 20 · Mon Nov 13 2017 21:31:13 GMT+0800 (China Standard Time)

What are migrations with development data? Do you mean having two separate migration sources?

But should it be part of an application template then? The framework repo has it already.

Probably not. It's there to make it more visible.

Alexander Makarov · Answer 21 · Mon Nov 13 2017 21:32:11 GMT+0800 (China Standard Time)

vendor/bin/yii command won't be able to run if you have PHP 5.3. requirements.php will run just fine.

Tobias Munk · Answer 22 · Mon Nov 13 2017 21:35:56 GMT+0800 (China Standard Time)

What are migrations with development data? Do you mean having two separate migration sources?

We usually have that, because we often need to run tests against a 100% defined set of data. I think fixtures would be better for that, in the past we were just not able to manage them easily.

Development data (or demo-data in our repos) is usually a cleaned subset of staging-data, which updated more often.

vendor/bin/yii command won't be able to run if you have PHP 5.3.

Minimum for Yii 2.1 is PHP 7.x ;)

Alexander Makarov · Answer 23 · Mon Nov 13 2017 22:02:41 GMT+0800 (China Standard Time)

Yes, fixtures are meant to set up environment to a certain fixed reproduceable state and they suit the purpose better than migrations do. The thing is fixtures may be used to non-automated testing or during development as well so they do not strictly belong to testing.

Minimum for Yii 2.1 is PHP 7.x ;)

Requirements script has to tell you that even if you're trying on 5.3.

Tobias Munk · Answer 24 · Mon Nov 13 2017 22:14:58 GMT+0800 (China Standard Time)

I generally agree. Maybe it should be differentiated clearer between structural migrations (schema) and (test-)data.
I know that there might also be need need for data in migrations, but it usually creates less problems when you have them separated.

Alexander Makarov · Answer 25 · Mon Nov 13 2017 22:38:05 GMT+0800 (China Standard Time)

There is a difference between common data and test/development-only fake data.

Sergey Pantushin · Answer 26 · Wed Nov 22 2017 16:07:16 GMT+0800 (China Standard Time)

My vision of this question

bin
    yii
docs
    README.md
src
    Site
        Controller
            DefaultController.php <-- App\Site\DefaultController
        Form
            Login.php <-- App\Site\Form\Login
        Migrations
            M171121204038Init.php <-- App\Site\Migrations\M171121204038Init
        Module.php <-- App\Site\Module
    Api
        Controller
            DefaultController.php <-- App\Api\DefaultController
        Module.php <-- App\Api\Module
config
    main.php
    console.php
runtime
    logs
    debug
vendor
tests
public
    index.php
    favicon.ico
    robots.txt
templates
    app
        site
            default
                index.php
        layouts
            main.php
    mail
        layouts
            main.php
.env (ignored)
.env.dist
.gitignore
README.md
composer.json
composer.lock
codeception.yml

aliraza · Answer 27 · Thu Dec 28 2017 18:47:28 GMT+0800 (China Standard Time)

maybe I am the only one, but the structure proposed is very similar to symfony, I would go with what samdark has proposed looks pretty close to what we have at the moment with codeception.yml moved to tests and yii moved to bin, if we change the directory structure we also have to educate the users please consider that as well

Sergey Pantushin · Answer 28 · Thu Dec 28 2017 19:00:42 GMT+0800 (China Standard Time)

Yes. PHP comes to standardization. Symfony offered a good structure. Soon you will have the same controllers to run different frameworks. I think the best way to use PSR-7.

aliraza · Answer 29 · Thu Dec 28 2017 19:19:03 GMT+0800 (China Standard Time)

Symfony offered a good structure

depends on who you ask, I personally don't have a problem with Symfony but I do know lot of users use yii because they don't like Symfony, I like what samdark has proposed with some additional changes we should be good.

PSR-7 has nothing to do with the directory structure PSR-7 proposes a standard for middlewares/filters, basically to run a function/method before and after a http request.

Sergey Pantushin · Answer 30 · Thu Dec 28 2017 19:25:01 GMT+0800 (China Standard Time)

Yep. This is very subjective. Ninety percent of everything is crap

Tobias Munk · Answer 31 · Thu Apr 05 2018 20:24:44 GMT+0800 (China Standard Time)

I am closing this, there's a nice structure available in the repo now, let's evolve that if needed.