[NPMCLI-86] Add ability to generate additional files with create commands Created: 27/Jan/17 Updated: 14/Feb/18 Resolved: 12/Dec/17 |
|
| Status: | Closed |
| Project: | Magnolia CLI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.0 |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Matthias Müller | Assignee: | Jaroslav Simak |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Epic Link: | CLI v3 | ||||||||||||||||||||
| Sprint: | Kromeriz 125, Kromeriz 126 | ||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||
| Description |
|
It's quite popular to have certain prefixes in CSS selectors to make sure, that the written CSS only applies where it should (scoping). CSS methodologies like BEM, SMACSS and CSS Modules try to solve the same problem with different naming conventions and folder structures using some sort of identifier. I personally tend to use the name of the magnolia component/area/page for this. Currently a template definition, a dialog definition and a template script are generated from the existing mgnl-cli-prototypes. It would be nice to be able to configure the generation of other files like like a corresponding CSS/SASS/LESS-File as well. e.g.: mgnl create-component my-component my-component.ftl <div class="my-component"> <h2 class="my-component--title">${content.title}</h2> ... </div> _my-component.scss
.my-component { ... }
.my-component--title { ... }
..
|
| Comments |
| Comment by Robert Kowalski [ 20/Mar/17 ] |
|
good idea matthias! here is what we have: right now we have a fixed set of files. its hardcoded were they are rendered into: prototype folder definition.yaml -> $module/templates/$type dialog.yaml -> $module/dialogs template.ftl -> $module/templates/$type with support for less / scss and other files we have to take care that the files are rendered into the right folders. hardcoding extensions into the client would lead to a lot of ongoing maintanance and we would be always one step behind the latest released transpiling format. we can archive that with a restructuring of the delivered prototype and their structure. proposal: prototype folder templates/$type/*.* -> rendered to $module/templates/$type dialogs/*.* -> rendered to $module/dialogs webresources/*.* -> rendered to $module/webresources |
| Comment by Robert Kowalski [ 29/Mar/17 ] |
|
Hm, tricky: to implement the directory traversal cleanly we have to break backward compatibility as the flat file structure is not compatible with the recursive rendering approach... |
| Comment by Robert Kowalski [ 29/Mar/17 ] |
|
working branch is feature/ |
| Comment by Robert Kowalski [ 29/Mar/17 ] |
|
possible migration strategy:
|
| Comment by Christopher Zimmermann [ 30/Mar/17 ] |
|
Recommend no automatic migration and a version of 3.0.0. |
| Comment by Christopher Zimmermann [ 30/Mar/17 ] |
|
The mgnl-cli-prototypes directory will get crowded, and it will be hard to know the type of each prototype - eventually we would have more types of them probably for apps and even 'light-modules'. |
| Comment by Christopher Zimmermann [ 30/Mar/17 ] |
|
Question 1 - how are the default prototypes named? "component" and "page" as now? I recommend renaming them to "default". |
| Comment by Robert Kowalski [ 03/Apr/17 ] |
|
Question 2 - how does the system choose which prototype to use by default? Just hardcoded? or can dev configure in the mgnl_config.json file? This sounds like a good follow up ticket. We can go with default for now and if additional flexibility is needed, we can add it to the mgnl_config.json file. I would be interested how our users are using the feature and then define the next step based on their feedback. |
| Comment by Robert Kowalski [ 03/Apr/17 ] |
|
Question 1 - how are the default prototypes named? "component" and "page" as now? I recommend renaming them to "default". sounds good to me |
| Comment by Robert Kowalski [ 06/Apr/17 ] |
|
mmueller here we go: https://git.magnolia-cms.com/projects/BUILD/repos/npm-cli/pull-requests/76/overview |
| Comment by Robert Kowalski [ 13/Apr/17 ] |
|
parked: breaking change. needs a final decision if we release it as 3.0 now (faster migration work for people, but shorter intervals) or if we put more breaking changes into it (longer timeframe between migrations, but more work to migrate) |
| Comment by Christopher Zimmermann [ 01/Sep/17 ] |
|
It depends on https://jira.magnolia-cms.com/browse/NPMCLI-119 which introduces breaking change because the prototype file structure is changed. |
| Comment by Christopher Zimmermann [ 04/Dec/17 ] |
|
Since this ticket will potentially impact the prototype structure as well, it should be completed for 3.0 release. |