bem-archive / bem-tools

Toolkit to work with files based on BEM methodology
http://bem.info/tools/bem/
MIT License
395 stars 72 forks source link

bem mv command #317

Open arikon opened 11 years ago

arikon commented 11 years ago

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

narqo commented 11 years ago

Maybe bem move?

arikon commented 11 years ago

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

qfox commented 11 years ago

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

arikon commented 11 years ago

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.

corpix commented 11 years ago

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 commented 11 years ago

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

corpix commented 11 years ago

@arikon oops, sorry. Missed this

Sergey Belov notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub: https://github.com/bem/bem-tools/issues/317#issuecomment-10937916

bariscicek commented 11 years ago

@arikon are you working on this already?

arikon commented 11 years ago

@bariscicek I've started and then postponed my work

bariscicek commented 11 years ago

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

arikon commented 11 years ago

I'll push it later today!

30.03.2013, 00:55, "Baris Cicek" notifications@github.com:

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 commented 11 years ago

@arikon cool thanks.

arikon commented 11 years ago

@bariscicek Just pushed bem-mv branch

bariscicek commented 11 years ago

@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 commented 11 years ago

@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 commented 11 years ago

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

arikon commented 11 years ago

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

qfox commented 10 years ago

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