A Yii asset hub.
sqlite key/val database:
path | value
A Yii asset hub.
sqlite key/val database:
path | value
That’s personal preferences. We should not require using docker as such. There are official Docker images already: https://github.com/yiisoft/yii2-docker
Also I’d not mix anything about containers into config or composer.json. From my practice these are pretty much unrelated.
I mean there’s Docker and docker-compose.yml for the purpose.
I’ve tried out yiisoft/yii2-docker and yiisoft/yii-docker and I’m using a modified version of yiisoft//yii2-app-basic as an SPA template. See: https://github.com/gazbond/yii2-app-basic.
I didn’t like yiisoft/yii2-app-advanced because I only need ‘frontend’ and ‘api’ and I like the simplicity of my data model being in the project root directory.
With yiisoft//yii2-app-basic I can specify my api as a module and then remap it with an api specific entry script and config file.
Which is what got be thinking about Yii modules and Docker.
OK. But how’s that related to asset publishing?
Because if Yii becomes docker only, project templates can be used as docker containers. Provide an asset hub image (php/apache2/Yii), maybe a Yii hub container (also php/apache2/Yii), and then you can specify which api, frontend and backend containers you want with their corresponding repos.
FYI this is a train of thought.
A Yii hub template would specify the ports an application is available on.
Then php containers are added, without specified ports, but link to which hub to use.
In terms of yiisoft/yii2-app-advanced:
common -> apche2 | ngnx / php : 8080 -> Yii bootstrap (configs, models, namespaces etc.)
frontend -> php -> Yii module (configs, models, namespaces etc.)
backend -> php -> Yii module
api -> php -> Yii module
Templates - web, api, common (each with own console) and console (just console).
Use ‘composer create-project’ for each template you want in your project directory.
Every project needs a ‘common’ directory that specifies docker-compose.yml and Yii bootstrap config.
Other directories specify Yii module config.
Assets module is a special case. It provides assets publishing config to all other modules.
All docker config is done in ‘common’ as well as all Yii module config.
That’s not direction we want to move to. Making Yii Docker-only will essentially kill it:
Not to mention web hosting providers that doesn’t provide docker integration.
Docker can’t definitely not be a requirement for Yii.
I see. Thanks for reading my ramble, I was a bit over-excited about v3 possibilities 
What’s the plan with Yii project template and application bases?
Would you use yiisoft/yii-project-template as top level project directory and checkout application bases into it?
I like the idea of having application bases that can also be modules. Load yiisoft/yii-base-api as a module in yiisoft/yii-base-web and also on its own as a Yii application.
@gazbond random thought: having a Docker setup for tests on each package would be something truly amazing.
That’s indeed how it’s meant to be used for now, see https://github.com/yiisoft/yii-project-template#installation.
DI’m thinking the following (which could allow multiple test containers):
frontend/
public/index.php <- run as vhost
composer.json
docker-compose.yml
backend/
public/index.php
config/modules.php <- load api + other
composer.json
docker-compose.yml
api/
public/index.php <- run as vhost
Module.php <- or as module
composer.json
docker-compose.yml
other/
Module.php <- only run as module
composer.json
vendor/
config/
runtime/
composer.json
docket-compose.yml <- run dev containerJust a question related to asset publishing.
Currently when using ActiveForm with client side validation, it will output the validation rules and error messages in the HTML.
How could we achieve the same thing if we want to build our frontend in a JS framework such as Vue or React? I know we can write our own custom validation in JS, but this means duplicating backend validation rules and error messages.
What techniques could we use to achieve the same result?
AJAX validation would, likely, do.
That’s something I’ve been wondering about as well. As @samdark mentioned, AJAX could be used, but it feels like we’ll be missing out too much on React/Vue client-side features by doing this, and doing a lot of roundtrips to the server that could be avoided.
What if we came up with a simple enough PHP/JS package that would expose the validations rules used server-side to our javascript. This would be fetched once from the client, and used to validate data locally. (Validation will of course still be happening on the server when saving.)
Still need to think this through…
“What if we came up with a simple enough PHP/JS package that would expose the validations rules used server-side to our javascript. This would be fetched once from the client, and used to validate data locally.”
Exactly what one expects from a current web-framework.