Skip to content
This repository has been archived by the owner on Jan 13, 2018. It is now read-only.

bem mv command #317

Open
arikon opened this issue Nov 28, 2012 · 18 comments
Open

bem mv command #317

arikon opened this issue Nov 28, 2012 · 18 comments

Comments

@arikon
Copy link
Contributor

arikon commented Nov 28, 2012

Implement bem mv command.
See blog post for opinions on command line interface:
http://clubs.ya.ru/bem/replies.xml?item_no=2066

@narqo
Copy link
Contributor

narqo commented Nov 28, 2012

Maybe bem move?

@arikon
Copy link
Contributor Author

arikon commented Nov 28, 2012

@narqo I was thinking that bem move is about moving BEM-entities between levels.

@qfox
Copy link

qfox commented Nov 28, 2012

Agreed with @narqo. "move" is more intuitive and shorter for renaming. bem move --to-level=another mb?

@arikon
Copy link
Contributor Author

arikon commented Nov 29, 2012

bem mv?

# rename block__elem1 to block__elem2
bem mv block__elem1 __elem2

# make block2 from block1__elem
bem mv block1__elem block2 --recursive

# rename block1 to block2
bem mv block1 block2

# rename block1 to block2 (with all its contents)
bem mv block1 block2 --recursive

# rename block1 to block2 at levels common.blocks and desktop.blocks
bem mv --level common.blocks --level desktop.blocks block1 block2

# move block from desktop.blocks level to common.blocks level
bem mv --from desktop.blocks --to common.blocks block

# move block (and all its contents) from desktop.blocks level to common.blocks level
bem mv --from desktop.blocks -to common.blocks block --recursive

Provide another cases please.

@ghost ghost assigned arikon Nov 30, 2012
@corpix
Copy link

corpix commented Dec 2, 2012

Shortcuts like block__elem is good, but there is bem create with other api. I have read blog post and I totally agree with veged.

bem mv could be a shortcut to bem move, mv and move just about the same for me

@arikon
Copy link
Contributor Author

arikon commented Dec 3, 2012

@corpix It is fixed already, see #319 and #322

@corpix
Copy link

corpix commented Dec 3, 2012

@arikon oops, sorry. Missed this

Sergey Belov [email protected] wrote:

@corpix It is fixed already, see #319 and #322


Reply to this email directly or view it on GitHub:
#317 (comment)

@bariscicek
Copy link

@arikon are you working on this already?

@arikon
Copy link
Contributor Author

arikon commented Mar 29, 2013

@bariscicek I've started and then postponed my work

@bariscicek
Copy link

@arikon Maybe you can share your code so I can continue working on this issue?

@arikon
Copy link
Contributor Author

arikon commented Mar 30, 2013

I'll push it later today!

30.03.2013, 00:55, "Baris Cicek" [email protected]:

Maybe you can share your code so I can continue working on this issue?


Reply to this email directly or view it on GitHub.

Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

@bariscicek
Copy link

@arikon cool thanks.

@arikon
Copy link
Contributor Author

arikon commented Mar 30, 2013

@bariscicek Just pushed bem-mv branch

@bariscicek
Copy link

@arikon I just started working on the branch. I haven't committed anything, but first Ineed to clarify some stuff since it might be related with design decisions.
First of all I added a 'default level' option. Because otherwise you need to specify -s and -t everytime even though you're working in same level, which should be a case for most of the use cases. Now it uses -l option to set sourceLevel and targetLevel if they weren't specified.

Now on copying the entities my major question is this. Is it valid to have an empty directory on source levels? There are cases that you might leave the empty directory if you specify a tech file. Or move command should remove all the empty directories left behind. (my idea is to check directories of source files and if htye are empty remove them). an example can be

bem mv block__elem_mod_val.css block2__elem_mod_val.css

In that case _mod directory on source might be left empty. But mod entity should exists.

Basically it relies on if an empty directoy in BEM tree has any meaning. If there's no meaning at all, I believe it's better to clean the empty directories that would prevent clutter in the development environment.

Once implementing the move function, I"ll fix the change tech. Then it's better to brainstorm about the contents of the files. A basic replace would be fine but it might also break files. Maybe there should be a git-type of conflict or approve question before applying replace bem entity names. I remember I read a similar proposal on yandex club discussion over the topic, but could not understand very well. (limited pa-ruskiy over here.)

@bariscicek
Copy link

@arikon I need more info about BEM entity changes. First of all what's the point? I don't see any use case. Second, how it could be possible? For example for a tree block1_elem1_mod you want to move it as an element elemNew. So that content of block1 will be content of __elemNew and content of elem1 will be _elem1 (ie. a mod) and _mod will be a value indeed? I'm trying to say, once you try to move the hierarchy one level up you lose the logic of BEM.

I think it's not necessary to change BEM entity types. But we should discuss about the refactoring of files using the .tech files update functions that should be described. Do you have any idea for that? I believe there should be a default regex for the 'BEM entity' names per .tech. And it should be default a direct replace. But tech file should describe its regex in case, (for example css tech file should have /\.{block_name}/ kind of regex, so in case of a move a replace operation using this regex should be applied to files). What do you think?

bariscicek pushed a commit to bariscicek/bem-tools that referenced this issue Apr 9, 2013
bariscicek pushed a commit to bariscicek/bem-tools that referenced this issue Apr 9, 2013
	* Adds getSelector() to tech.js to change content of target file
	* Support changing tech of BEM entities
	* Couple of fixes to previous patch
@bariscicek
Copy link

Ok with recent patch, I'll be waiting for you to check. This includes content change as well which is pretty useful.

@arikon
Copy link
Contributor Author

arikon commented May 23, 2013

@bariscicek Sorry for the delay. Could you please open pull request for this?

@qfox
Copy link

qfox commented Nov 1, 2013

@arikon Np bro. Let's talk about it ;-) Don't merge it btw. It should be refactored asap.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants