[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:
dependency
depends upon NPMCLI-119 Multiple prototypes for creating page... Closed
is depended upon by NPMCLI-148 Prototypes for create-light-module Closed
relation
is related to NPMCLI-147 Tab autocompletion should include pro... Closed
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/NPMCLI-86--additional-file-rendering

Comment by Robert Kowalski [ 29/Mar/17 ]

possible migration strategy:

  • try to detect if old structure is used, print error with link to migration help.
  • offer small script to migrate old prototypes
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'.
Recommend a subdirectory for each type, which match the directories in the light modules . "components" "pages" "apps".

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".
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?

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.

Generated at Mon Feb 12 04:46:23 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.