Add support for different formatting for different nodes

[mervynokm]

Hi, is it possible to have custom formatting for the different nodes as well? Something like this for eg:

pragma mark - segue.identifier

NSString * const PSBMasterToDetail = @"PSBMasterToDetail-Segue"; NSString * const PSBMasterToSettings = @"PSBMasterToSettings-Segue";

pragma mark - storyboardNames

NSString * const Main = @"Main-Name";

pragma mark - tableViewCell.reuseIdentifier

NSString * const PSBAwesomeCell = @"PSBAwesomeCell-ReuseIdentifier";

also, thanks for the awesome project!

[paulsamuels]

Hey @mervynokm thanks for the issue - I'm not 100% sure I see the benefits to this approach.

Originally I chose to keep the constant name as close to the value as possible so that when working with the identifiers you don't have to keep performing translations in your head from key -> value. The only time the key is manipulated to have a different name to the value is when the value would not form a valid identifier.

The naming scheme above also potentially increases chances of naming collisions e.g. PSBAwesomeCell would most likely be the name of an actual UITableViewCell subclass but this string constant will now clash with the symbol for the class name.

Ultimately when using a tool like this I don't actually care what the values behind the keys are as I just need some way of removing stringly typed code.

Perhaps I'm not seeing it from your perspective - I'd be keen to here any arguments you have for this formatting.

[mervynokm]

hi @paulsamuels thanks for getting back so quickly!

To better clarify my perspective, one issue we were facing was generating a very long list of constants. As we inherited our project from previous developers, older storyboards/xibs may not have adopted similar/proper naming conventions which in our scenario, led to collisions appearing with the newer storyboards.

That said, one approach for us could be to dig into each of the older storyboards and fix the naming conventions first but the scale of the project would make it difficult to do so.

As such, the perspective I'm coming from would be to enable such customization in the template files, such that for eg, the objc_header.erb could look something like:

Just a suggestion nevertheless. Appreciate the time taken to hear me out!

[paulsamuels]

It sounds a bit like it's very specific to your use case so it might not make sense to be generally included in the tool.

If you are interested in doing this you could certainly do it without forking the project by creating a custom template, which wouldn't be too hard. The below is extremely ugly and non idiomatic Ruby (shown only out of interest) but will get you most of the way towards your goal

objc_header.erb

<% section.locations.map { |location| location.key_path.split('.').last }.each do |type| %>
<% upcase_first = ->(string) { string.sub(/\S/, &:upcase) } %>
extern NSString * const k<%= upcase_first[type] %><%= constant_name %>;
<% end %>

objc_implementation.erb

<% section.locations.map { |location| location.key_path.split('.').last }.each do |type| %>
<% upcase_first = ->(string) { string.sub(/\S/, &:upcase) } %>
NSString * const k<%= upcase_first[type] %><%= upcase_first[constant_name] %> = @"<%= constant_value %>";
<% end %>

[mervynokm]

true its likely that what I'm experiencing is a very case by case thing. In any case, thanks for the implementation above, I'll dig deeper into it and see if i'm able to implement that into the template as you suggested.

Thanks for your help man! appreciate it

[patoroco]

This issue should be already closed, isn't it?