petkopara / PetkoparaCrudGeneratorBundle

Symfony3 CRUD generator bundle with pagination, filter, bulk actions and Twitter bootstrap 3.3.6 features.
MIT License
70 stars 17 forks source link

Humanize labels #49

Closed davidpeoples closed 7 years ago

davidpeoples commented 7 years ago

This adds two custom filters to the twig environment used by the CRUD generator: "humanize_lc" and "humanize_uc". Both are near clones of the "humanize" filter provided by the symfony/twig-bridge. Both filters split camelCase and snakecase text strings into individual words, broken on each capital letter and "" character. The _lc variant leaves all words lowercase. The _uc variant capitalizes the first letter of the first word. (I did not simply include the symfony/twig-bridge package because it introduced composer conflicts I could not resolve.)

With these two new filters available, the generator templates and the th_sortable macro have been altered to use them to split the entity name and field labels into more readable words.

(The title override in th_sortable remains, and that override is not run through any filter inside the macro. So users can change the index page column labels back to camelCase or snake_case if they desire, just by manually setting the titles that way after generation. And of course the entity names in page titles and headlines can still be manually changed after generation. This change just makes the default arguably more readable.

petkopara commented 7 years ago

Hi @davidpeoples, Thank you for your contribution, but I am I am still not sure whether to add this feature as long as we will make the generated templates too much dependent from the bundle. Yeah there is already defined macros for the sorting, but the end user can choose whether to add it this or not to the templates. At the end the idea was just to generate some boilarplate templates to start work on.

davidpeoples commented 7 years ago

Hi @petkopara,

Thanks for your feedback. I can understand that concern, and I will withdraw the pull request. In fact I have since figured out how to use the actual Symfony humanize filter function during generation, which makes this PR unnecessary.

However, that was just one change among a large set of much bigger additions and alterations I'm making to the generator for myself. I'll list them for you here and you can let me know if any sound interesting as submissions back to your project. But for now looks like I will fork your work to a new project with a new name (in case I decide to share it with the world on packagist rather than just keeping it to my own company).

Here are the changes I've made so far:

Revised all the generator templates to produce PSR-2 compliant code in the generated controller (with complete docblocks, etc.). Generated twig templates are more "tidy" and readable with consistent indentation and fewer random blank lines. I'm currently using PhpStorm's code inspector to judge compliance, but soon will also check with squizlabs/PHP_CodeSniffer (which appears to be more stringent). Added labels to all form fields where they were missing for accessibility (but set them hidden using the Bootstrap screen-reader-only class).

For all controller methods that modify the entity, wrapped the method in a try-catch block and database transaction. I may make the database transaction a normally-off generator option.

Split the project into two bundles. One contains only the assets needed in production, and does not depend on the original Symfony CRUD generator module. The second contains all the actual generator code, and depends on the asset bundle. The generator bundle can be excluded from the production app kernel.

Made the CRUD generator bundle read a section of app/config/config.yml (or config.xml, etc.) to set the default configuration. These settings override the stock generator defaults, and can in turn be overridden by command-line switches and the interactive choices. Now I don't have to manually override the base.html.twig setting every time I generate a new controller. I will soon enhance this feature to allow setting multiple named configuration sets, which can selected from during generation. Another coming enhancement will be to point the generator to any arbitrary location for the skeleton templates, rather than just the two predefined locations currently available.

If you are interested in any of these changes for your own project, let me know.

David Peoples

On Fri, Oct 13, 2017 at 5:54 AM, Petko Petkov notifications@github.com wrote:

Hi @davidpeoples https://github.com/davidpeoples, Thank you for your contribution, but I am I am still not sure whether to add this feature as long as we will make the generated templates too much dependent from the bundle. Yeah there is already defined macros for the sorting, but the end user can choose whether to add it this or not to the templates. At the end the idea was just to generate some boilarplate templates to start work on.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/petkopara/PetkoparaCrudGeneratorBundle/pull/49#issuecomment-336419753, or mute the thread https://github.com/notifications/unsubscribe-auth/AAj-dNtV7i-Z67vDS1VnFNi7eeeNsOueks5sr0FXgaJpZM4PSn48 .

-- David Peoples 314-210-9996 david.a.peoples@gmail.com http://www.linkedin.com/in/davidpeoples