Template proposal
schmunk42 opened this issue · 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.
I don't think there will be high demand on separate CLI template.
pkg
is unusual and IMO is overkill.- Having
src
sounds OK. config
could be moved to the root out ofsrc
.
I don't think there will be high demand on separate CLI template.
If it's not a separate template it's even better ;)
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.
I suggest a format for directories:
- /src
- /runtime
- /web (or public)
- /config
- /database
- /resources
- /tests
And dotenv default support.
What would be in?
/database
/resources
- /resources
- /views
- /messages
- /database
- /migrations
- /(other files for db)
Doesn't look good to me. Don't see why views and messages aren't part of the application as well as migrations.
@samdark
Agree.
- /config
- /runtime
- /src
- ..
- /Migrations
- /Resources
- /views
- /messages
- ..
- /tests
- /web (or public)
That's better. Not sure we need resources
dir though.
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
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?
web → public makes sense considering REST APIs.
No particular reason for moving yii
.
- Shouldn't
fixtures
andrequirements.php
be part oftests/
? - What's about also moving
codeception.yml
totests/
? It's not required to be in the project root, likecomposer.json
orpackages.json
...
PS: I made some slight adjustments on my personal prototype according to this discussion.
fixtures — definitely not since fixtures could be used from command line to fill database for development purposes.
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.
Moving codeception.yml sounds fine.
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...
- https://stackoverflow.com/questions/12071344/what-are-fixtures-in-programming
- https://softwareengineering.stackexchange.com/questions/211959/what-are-the-different-meanings-of-fixture
- https://en.wikipedia.org/wiki/Test_fixture
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.
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.
vendor/bin/yii
command won't be able to run if you have PHP 5.3. requirements.php
will run just fine.
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 ;)
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.
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.
There is a difference between common data and test/development-only fake data.
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
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
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.
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.
Yep. This is very subjective. Ninety percent of everything is crap
I am closing this, there's a nice structure available in the repo now, let's evolve that if needed.