symfony / maker-bundle Goto Github PK
View Code? Open in Web Editor NEWSymfony Maker Bundle
Home Page: https://symfony.com/
License: MIT License
Symfony Maker Bundle
Home Page: https://symfony.com/
License: MIT License
This is a small first step towards my bold plan of having the MakerBundle completely reinvent the experience of working with Symfony security :).
When you run make:auth
, I would like to also update the user's security.yaml
file. In future commands (like make:user
) I would like to make even more changes to this file. But, there are some complications:
We must update the file without changing anything else - like spacing or comments. That means Yaml::dump()
is out of the question
We must be able to smartly detect that there is only 1 firewall and update it (i.e. we need to be smart enough to detect and ignore any dev
firewall)
Before writing the new security.yaml
file, we should validate that our new YAML is valid YAML.
If we cannot figure out how to patch their security.yaml
, then we should not do it and print a clear message and what they need to do at the bottom.
For me, one of the first downsides I have encountered while testing out Flex with Symfony4 is the missing command of doctrine:generate:entity
with all the helper questions + the not working doctrine:generate:entities
(see doctrine/DoctrineBundle#729 fore more info).
My previous workflow whenever I was prototyping something was:
doctrine:generate:entity
by answering to a couple of questions;doctrine:generate:entities
to get the new properties and appropriate methods (e.g. __construct with initialized ArrayCollection objects, addElement, removeElement etc.)With the current make:entity command, it took me more than 4 times the time in order to get an up & running 3 entities related between them (Job, Category, Affiliate - remember good ol' Jobeet tutorial).
I would like to bring under your attention the need of migrating the functionality from SensioGeneratorBundle to the MakerBundle for doctrine:generate:entity
command (very useful when first creating an entity).
Also, I would like to propose discussing the idea of migrating doctrine:generate:entities
from DoctrineBundle, as the core maintainers from that project are not in favor of maintaining this command for the purpose of generating setters and getters based on mapping information.
I don't know if the 2nd proposal should be part of make:entity
command or another one command.
In old behaviour with doctrine when you add or remove some attribute, the new entity is updated and you dont have to delete it and recreate it again.
Currently the behaviour is a warning message saying that the entity file already exists and it doesn't update the new parameters. Even if probably this could be done via doctrine migrations, probably at initial stages when you build you anemic model, you don't have clear all the attributes and it is needed to update frequenly the entity.
Hi there.
May be we can change InputConfiguration
to handle options like autocomplete and validation? It will help us to simplify custom makers and brings ability to make complex interaction automatically.
Example changes
If no one mind, I will create PR and we can discuss the best way to improve this part of bundle :)
Maybe this is something obvious but wondering...
Within the repo code we use short array syntax []
but in docs (https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html) we are using older one - array()
.
Shouldn't this be unified?
src/Doctrine/DoctrineEntityHelper.php
line 45
$entityClassDetails = new ClassNameDetails($metadata->name, 'App\\Entity');
src/Maker/MakeCommand.php
line 91
$generator = new Generator($this->fileManager, 'App\\');
This has been something we've debated. I just had a long conversation with @nicolas-grekas about it, who feels pretty strongly about pushing this best practice now. I don't feel too strongly, and certainly we need to do this at some point. Since MakerBundle is for Symfony 4 (so new projects, or people who have upgraded and are fully using the new features), this is a great place to push the best practice.
I have a question:
Why we can't configuration path to template of different commands?
For example to pass option path_to_skeleton.
In the same spirit of make:controller but for those who prefers ADR action instead controller
By example:
<?php
namespace App\Action;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Component\HttpFoundation\Response;
class ShowCategory
{
/**
* @Route("/category", name="category")
*/
public function __invoke()
{
return new Response('Welcome to your new action !');
}
}
I have time to add a PR tomorrow I think
Since doctrine/doctrine-fixtures-bundle has a very nice Flex support, why not including it in this bundle, too?
Always with the aim of making our developments faster, would it be interesting to introduce some override:*
commands for overriding all what is possible to override from core and third-party bundle? For instance:
override:template
override:error-pages
override:route
override:entity
Maker Bundle is not registering make
commands, although I've followed the instructions in the docs carefully.
> composer create-project symfony/skeleton my-app
> cd my-app
> composer require maker --dev
> php bin/console list make
Symfony 4.0.2 (kernel: src, env: local, debug: true)
Usage:
command [options] [arguments]
Options:
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
-e, --env=ENV The environment name [default: "local"]
--no-debug Switches off debug mode
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
2017-12-25T15:41:30+01:00 [error] Error thrown while running command "list make". Message: "There are no commands defined in the "make" namespace."
There are no commands defined in the "make" namespace.
list [--raw] [--format FORMAT] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<namespace>]
uname
: CYGWIN_NT-10.0
(Windows 10)
php -v
: PHP 7.1.3 (cli) (built: Mar 14 2017 23:33:35) ( NTS MSVC14 (Visual C++ 2015) x64 )
composer --version
: Composer version 1.5.6 2017-12-18 12:09:18
Also, it says env: local
although APP_ENV=dev
is set in .env
.
Hi all.
The idea is to hide DependencyBuilder from Maker and simplify dependency configuration.
Now we have:
public function configureDependencies(DependencyBuilder $dependencies)
{
$dependencies->addClassDependency(
Route::class,
'annotations'
);
}
After:
public function getDependencies(): array
{
return [
Route::class => ['package' => 'annotations']
];
}
I understand that it's BC break, but we have #120 which is already a BC break, and we can combine it if community and @weaverryan doesn't mind
Hello, I have opened this issue on the main symfony repository and I was told to do it on this one. Here is the main issue if you want to read it - symfony/symfony#25406 (comment)
Here is the idea - a command to create register and login form by providing an entity which implements UserInterface
(I have seen that some think that this is a bad practice so if you really dislike UserInterface
that much we can think of another requirement) and has some base options.
The command will generate SecurityController
if it doesnt exist as well as login and register forms and views. It will change the route.yml
and security.yml
files to basically make everything needed for a login and register to work properly.
This way the user doesn't need to repeat everything mentioned in the documentation or download FOSUserBundle and then follow the documentation again. It saves a lot of time for people like me who make lots of demo projects to try new stuff (expecially after 4.0 is out).
If this command generates everything needed there is no need for any kind of magic. currently if you follow the documentation for register and login or if you download FOSUserBundle there is a lot of magic going on and you don't see the code (unless you dig into vendor
folder a lot).
With that command the code generated can be dependency free (everything used by it is generated by it) and with no magic involved so that if a new user wants to use it and understand how it works he can do so very easily without having to write anything.
The command might be separated into two commands
make:security:register
- -algorithm={algorithm name}
(default is bcrypt)
- --withsalt
determines if the user wants the encryption to use salt( default is yes
)
- -entity={entity name}
(default looks for User
)
- -path={path for register}
(default is /register
)
make:security:login
if possible to use the options provided to make:security:register
if not - repeat the same options
- checkpath={path for check}
(default is /login
)
- loginpath={path for login}
(default is /login
)
As you can see the two commands are under make:security
which might have other commands.
I would love to participate in the development of these commands or anything to help Symfony, but I have never been part of such big repository so I would love it if there is someone willing to help me and answer my questions as I try to contribute to Symfony! If there is none - hope you guys will like the idea so that I can use it!
http://symfony.com/doc/current/form/create_custom_field_type.html
Although the class has the same methods available as the one generated by the make:form
command, it's a bit different from what is needed for custom form field types.
Skeleton:
namespace App\Form\Type; // <-- different location (src/Form/Type)
// ...
class <?= $form_type_class_name ?> extends AbstractType
{
public function buildForm(FormBuilderInterface $builder, array $options)
{
}
public function buildView(FormView $view, FormInterface $form, array $options);
{
// this method is commonly used rather than buildForm
}
public function configureOptions(OptionsResolver $resolver)
{
$resolver->setDefaults([
'option_name' => null,
// most of the time it is not a compound form, so data_class option is rare
]);
}
public function getParent()
{
// we might need a good default parent, may be:
return TextType::class;
}
}
Creating a template for the field (if Twig is available):
{# templates/form/fields.html.twig #}
{% block <?= $form_type_block_name ?>_widget %}
{% endblock %}
Configuring the form theme template (if Twig is available and it is not configured):
# config/packages/twig.yaml
twig:
form_themes:
- 'form/fields.html.twig'
Should we add this feature to the current MakeForm
(through a flag option) or would it be a new maker make:form-type
?
As a chore, we should remove service autowiring and auto-registration.
There are 2 reasons:
A) make the bundle faster in dev (no autowiring)
B) give the services non-class ids (no auto registration + use traditional-style ids) so that the commands don’t display in debug:autowiring
Hello,
tried command make:entity Color
Entity has successfully generated, but getting this error when trying to run website.
The "App\Repository\ColorRepository" entity repository implements "Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepositoryInterface", but its service could not be found. Make sure the service exists and is tagged with "doctrine.repository_service".
Generated Repository:
<?php
namespace App\Repository;
use App\Entity\Product\Color;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Symfony\Bridge\Doctrine\RegistryInterface;
class ColorRepository extends ServiceEntityRepository
{
public function __construct(RegistryInterface $registry)
{
parent::__construct($registry, Color::class);
}
/*
public function findBySomething($value)
{
return $this->createQueryBuilder('c')
->where('c.something = :value')->setParameter('value', $value)
->orderBy('c.id', 'ASC')
->setMaxResults(10)
->getQuery()
->getResult()
;
}
*/
}
I tried this bundle today and was quite surprised to find that the generated PHP files do not contain declare(strict_types=1);
. I can't see any reason for that since this bundle itself requires PHP 7 anyway. Is there some other reason? Or should I send a PR?
Symfony 3.3 Flex
composer require maker
=>
[InvalidArgumentException]
Could not find package symfony/maker-bundle at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability
There are too many people that have just 7.0 installed and we would be way more welcoming to them and every newcomers if things worked out of the box here with eg Ubuntu LTS.
This bundle actually does not replace the current generator bundle as it was more focused on a CRUD generator. Is it something we want to do here as well?
Hi,
how can I generate a form type class based on an existing entity class, like in the old generator bundle:
doctrine:generate:form
http://symfony.com/doc/current/bundles/SensioGeneratorBundle/commands/generate_doctrine_form.html
Can this be done with the Maker bundle?
It looks like we're starting something that may look a lot like what Drupal Console already did for Drupal.
I already talked several times with @jmolivas and @enzolutions: they built an amazing DX there, I'm sure we'll end up providing something similar, yet tailored to Symfony 4.
I'm just wondering where we can collaborate to move faster.
What about a new target
option for each command that allows us to change the target directory where the final skeleton file is generated?
For example make:unit-test FooTest
always creates the file class inside tests/
directory, but as the best practice recommends:
By convention, the
tests/
directory should replicate the directory of your bundle for unit tests. So, if you're testing a class in thesrc/Util/
directory, put the test in thetests/Util/
directory.
Something like this make:functional-test FooTest --target=tests/Util
will be great to not move each generated file to the corresponding directory and change its namespace.
Hi I have a question
example generate an entity in with the doctrine config:
https://github.com/symfony/recipes/blob/master/doctrine/doctrine-bundle/1.6/config/packages/doctrine.yaml#L13
If you install Symfony 4 from scratch you will install:
symfony/config (v3.3.*)
The marker-bundle as a dependency on v3.4
, which I don't see tagged properly in Packagist? Only seeing 3.4 RC, BETA, etc...
If you do:
composer require maker
After a completely fresh install of Symfony 4.0 you will get the error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for symfony/maker-bundle ^1.0 -> satisfiable by symfony/maker-bundle[1.0.0].
- symfony/maker-bundle 1.0.0 requires symfony/config ^3.4|^4.0 -> satisfiable by symfony/config[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2] but these conflict with your requirements or minimum-stability.
If I try to install 3.4 or 4.0 via: "symfony/config": "^3.4|^4.0
I get:
λ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package symfony/config ^3.4|^4.0 is satisfiable by symfony/config[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2] but these conflict with your requirements or minimum-stability.
Problem 2
- symfony/framework-bundle v3.3.9 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.8 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.7 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.6 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.5 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.4 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.3 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.2 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.13 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.12 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.11 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.10 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.1 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.0 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- symfony/framework-bundle v3.3.13 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
- Installation request for symfony/framework-bundle ^3.3 -> satisfiable by symfony/framework-bundle[v3.3.0, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9].
Is maker not compatible with Symfony 4 at this time? Is Symfony 4 docs out of date?
https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html#creating-your-own-makers
Creating your Own Makers
------------------------
In case your applications need to generate custom boilerplate code, you can
create your own ``make:...`` command reusing the tools provided by this bundle.
Imagine that you need to create a ``make:report`` command. First, create a
class that implements ......
... wait no no, just run make:maker report
that's it! =)
What do you think?
Hi guys!
This maker command would generates a new (form) type extension class under src/Form/Extension/
and the argument is the extended type class (the class name is derived from it).
What do you think?
The documentation covers a lof of other boilerplates, but theses one are less common. So, we can imagine the next commands:
make:security:guard
docmake:serializer:encoder
docmake:profiler:data-collector
docmake:security:form-login
docmake:monolog:processor
docThis bundle is interested only by the most common makers or these previous examples are potentially to include in this project?
Hi to everybody.
The new 1.1.0 makerbundle return error during object creation ( entity, form, controller etc ).
The version 1.0 work correclty
I'm working under Window 7 and Windows 10 environments
This is the verbose output:
2018-02-21T10:21:45+00:00 [debug] Warning: mkdir(): No such file or directory
2018-02-21T10:21:45+00:00 [error] Error thrown while running command "make:entity -vvv prova". Message: "Failed to create "C:\PHPDevelopment\mrc//C:\PHPDevelopment\mrc\vendor\composer/../../src/Entity""
2018-02-21T10:21:45+00:00 [debug] Command "make:entity -vvv prova" exited with code "1"
In Filesystem.php line 106:
[Symfony\Component\Filesystem\Exception\IOException]
Failed to create "C:\PHPDevelopment\mrc//C:\PHPDevelopment\mrc\vendor\composer/../../src/Entity"
Exception trace:
Symfony\Component\Filesystem\Filesystem->mkdir() at C:\PHPDevelopment\mrc\vendor\symfony\filesystem\Filesystem.php:682
Symfony\Component\Filesystem\Filesystem->dumpFile() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\FileManager.php:55
Symfony\Bundle\MakerBundle\FileManager->dumpFile() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Generator.php:162
Symfony\Bundle\MakerBundle\Generator->writeChanges() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Maker\MakeEntity.php:77
Symfony\Bundle\MakerBundle\Maker\MakeEntity->generate() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Command\MakerCommand.php:93
Symfony\Bundle\MakerBundle\Command\MakerCommand->execute() at C:\PHPDevelopment\mrc\vendor\symfony\console\Command\Command.php:252
Symfony\Component\Console\Command\Command->run() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:883
Symfony\Component\Console\Application->doRunCommand() at C:\PHPDevelopment\mrc\vendor\symfony\framework-bundle\Console\Application.php:84
Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:241
Symfony\Component\Console\Application->doRun() at C:\PHPDevelopment\mrc\vendor\symfony\framework-bundle\Console\Application.php:72
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:143
Symfony\Component\Console\Application->run() at C:\PHPDevelopment\mrc\bin\console:39
make:entity [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] []
In order to be able to implement the security part of symfony, in my opinion it can help people to have the whole user stack generated
Since the only thing they will to do is to configure guard for this.
WDYT ?
see #41 for an implementation and testing if you want this in the Maker Bundle.
Some questions:
Hi
Could it be great to use the constant in
https://github.com/symfony/http-kernel/blob/master/Kernel.php (MAJOR|MINOR_VERSION)
to change the value of "current" in https://github.com/symfony/maker-bundle/blob/master/src/Command/MakeEntityCommand.php#L69
could define it in the abstractcommand and use it in the subcommand ?
so that it is a real link depending on the dev sf version :)
Hi,
It will be great to add support a generation of the translation file.
At this moment it can be done by creating custom Generator, because at this moment it is not possible to override existing file.
Hi, since 1.1
and changes to the MakerInterface
I'm unable to find good way to write own makers that are not inside MakerBundle
. I want keep them in my code and register through tag.
Hardcoded class in MakerCommand
$generator = new Generator($this->fileManager, 'App\\');`
https://github.com/symfony/maker-bundle/blob/master/src/Command/MakerCommand.php#L91
Hardcoded templatePath in Generator
class
$templatePath = __DIR__.'/Resources/skeleton/'.$templateName;
https://github.com/symfony/maker-bundle/blob/master/src/Generator.php#L130
I'm trying to find the best solution, without hacking this, is there a recommended way I missed? I can't think of any in this case.
maker-bundle can not generate controllers in subdirectories, or at least it is not in the documentation of how to do it.
I already tried the following options
1.- People:ProfessionController
2.- People\ProfessionController
3.- People/ProfessionController
If somehow this option is not created, it would be good to enable it for all bundle commands. And apply it with the first option.
My Entity name is "App\Entity\DepartmentPo"
After make:crud in controller a get method
App\Controller\DepartmentPoController.php
public function index(DepartmentPoRepository $departmentPoRepository): Response
{
return $this->render('department_po/index.html.twig', ['departmentPos' => $departmentPoRepository->findAll()]);
}
templates\department_po\index.html.twif
{% for department_po in department_pos %}
In the controller defines "departmentPos" varible but in twig we trying find "department_pos".
I think the problem in the entity name "DepartmentPo".
When creating this bundle we decided to not require Twig to keep things simple. That means that our skeleton files can't have complex logic and we need to interpolate the placeholder variables ourselves. Not a big deal ... but not using Twig and not defining skeleton files as Twig templates has another problem...
... you can't easily override the skeleton files in your project (see #32 and lots of related issues in the SensioGeneratorBundle). Should we...
... add Twig as dependency and turn skeletons into templates?
... try to make the skeleton files overridable using the kernel file locator ?
... not support this feature explicitly?
Hi,
When we generate a controller from the make:controller
command and Twig is available, the template generated is invalid: it uses the getParameter
method which is not available on a AbstractController
.
Hey guys,
Currently, unless I missed the option somewhere, when I do
$ bin/console make:con
Choose a name for your controller class (e.g. OrangeKangarooController):
> NameController
It create a controller using annotations.
/**
* @Route("/name", name="name")
*/
What do you think of asking for the desired route name, path and the strategy:
$ bin/console make:controller
Choose a name for your controller class (e.g. OrangeKangarooController):
> NameController
Choose a path (default: name)
> some-path
Choose a route name (default: name)
> some-name
Annotations or yaml? (default: Annotations)
> yaml
If you think this could be an interesting feature, I could give it a try.
Cheers.
has the fields interaction just not been added yet, or was it a conscious choice to leave it out?
Maybe add support for Symfony 3.3 + Flex? Right now old generator is not working with flex and this one is for SF3.4+
Hello,
I'm currently using this bundle with Symphony 3.4 to create custom makers.
According to the documentation, this bundle depends on Flex, and I had to remove the Flex dependency check to make it run.
If I understand correctly, the Flex dependency is there because the default makers (controllers, entities, ...etc.) make use of the new Flex file structure. But in the case of custom makers, it's a shame that one can not use this bundle with "Flexless" Symfony 3.4...
Wouldn't it be enough to show a warning message like "Beware, default makers will only work in a Flex environment" ?
Or have I missed anything ?
Thanks in advance ;-)
Currently, the generators are hardcoding the src
folder for the source. But SRC_DIR
is configurable in Flex.
The bundle should read the configured value in the composer.json instead, to account for Flex configuration.
Hello,
let's say I keep my entities in ./src/Entity/ but I want to organize it better, so I've decided to split entities into other directories, for example ./src/Entity/Shop/ and other in ./src/Entity/Auth/
how do I achieve this using php bin/console make:entity? Is there a way to do this?
To create a reusable bundle is a little boring. SensioGeneratorBundle have a command for this. Why not have a similar command here?
At the time of speaking there are no CI running the tests for the repository. Do we keep using travis ou do we add something like CircleCI ?
We use $this->render()
in make:controller
to render a pretty page :). But we cannot do that if TwigBundle is not installed. In that case, we should generate a simple new Response()
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.