Provide Overridable Capabilities/Render Customization

[Stunner]

This would allow you to provide a block on the object you want to customize rendering for. NUI would then call this block (if existent) when it attempts to render the object. You could even specify a key and value in the .nss file that NUI doesn't support and then handle it in the override block. More info on this can be found here and here. The implementation for this can be found here.

[timbodeit]

Why do this on a per-object rather than a per class level? Is there any advantage over class wide renderers?

To me it seems, that if I have to touch every individual object, it provides little improvement over making the changes manually.

I think providing override/extension capabilities on a class level would be the better option.
The first approach that comes to my mind would be turning NUIRenderer into sort of a renderer manager where you could register renderers for a specific class.
I'd change NUIRenderer to provide a single renderView: method, that would choose the appropriate renderer.

You could subclass NUITextFieldRenderer:

@interface UnderlineTextFieldRenderer: NUITextFieldRenderer
@end
@implementation UnderlineTextFieldRenderer
+ (void)render:(UnderlineTextField*)textField withClass:(NSString*)className
{
    [super render: textField withClass: className];
    if ([NUISettings hasProperty:@"textfield-underline-color" withClass:className]) {
        [textField setUnderlineColor:[NUISettings getColor:@"textfield-underline-color" withClass:className] forState: UIControlStateNormal];
    }
}
@end

And register this renderer in a fashion similar to this:

[NUIRenderer registerRenderer: [UnderlineTextFieldRenderer class] forClass: [UnderlineTextField class]];

@Stunner what are your thoughts on this?

[Stunner]

Appreciate your thoughts Tim. It's a good thought, however, your suggestion
causes a lot more work to be done by the end user to override a property
(in the single case). The inspiration for creating this feature came about
when my designer wanted to tweak the appearance of a custom text field
(underline text field) and I wanted a fast way to override customization on
a per-instance basis.

Your suggestion for class overridability makes sense for the custom class
case, but is not practical for an all-encompassing overridability feature.
Here is a realistic case: Let's say, for sake of argument, there is a bug
with NUI when rendering a UISwitch's background color property in a
specific view. The user should be able to set the render override block and
override that property on the object of interest. Requiring them to go
about subclassing UISwitch and then registering it with the render manager
is overkill and superfluous.

You bring up a valid point however. That this will cause potential
redundancy in the case of a custom class that is in need of styling. Your
approach makes sense in this case, but for the time being one can assign
the render override block to a variable or instance variable and assign it
to every instance of the custom object. Hopefully this will suffice until
something more elegant can be done about this case.

Considering this override feature is already a fair amount of work and
involves significant changes to the code base, I would like to hold off on
implementing your suggestion for the time being. I want to provide the
capability to override properties at the most granular level first. To
cover all bases so-to-speak. Good suggestion though. Keep the comments
coming.
On Fri, Nov 20, 2015 at 7:46 PM Tim Bodeit notifications@github.com wrote:

Why do this on a per-object rather than a per class level? Is there any
advantage over class wide renderers?

To me it seems, that if I have to touch every individual object, it
provides little improvement over making the changes manually.

I think providing override/extension capabilities on a class level would
be the better option.
The first approach that comes to my mind would be turning NUIRenderer into
sort of a renderer manager where you could register renderers for a
specific class.
I'd change NUIRenderer to provide a single renderView: method, that would
choose the appropriate renderer.

You could subclass NUITextFieldRenderer:

@interface UnderlineTextFieldRenderer: NUITextFieldRenderer
@EnD
@implementation UnderlineTextFieldRenderer

• (void)render:(UnderlineTextField_)textField withClass:(NSString_)className
  {
  [super render: textField withClass: className];
  if ([NUISettings hasProperty:@"textfield-underline-color" withClass:className]) {
  [textField setUnderlineColor:[NUISettings getColor:@"textfield-underline-color" withClass:className] forState: UIControlStateNormal];
  }
  }
  @EnD

And register this renderer in a fashion similar to this:

[NUIRenderer registerRenderer: [UnderlineTextFieldRenderer class] forClass: [UnderlineTextField class]];

@Stunner https://github.com/Stunner what are your thoughts on this?

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

[timbodeit]

If you already have the custom underline text field, what is there to tweak on a per instance basis? Why would you not want to apply these changes to all of the underline text fields in your app? How many of these UnderlineTextFields do you have in your app?

I do see a similar case in one of our ours. Our designer has chosen to make UITextField placeholders italic. I would estimate that we have around 20 to 40 of those in our app. Setting this custom block on every single one of them would not be practical. Currently we're crawling through the view hierarchy to make this change on every single text field. Note, that we haven't subclassed UITextField (even though that would probably have been the cleaner option, without NUI per-class custom rendering).

When there is a bug in NUI that is so easy to fix, I would expect the user to do that and file a pull request. NUI is an open source project after all.
I do get your point though: With my approach you wouldn't have to subclass UISwitch. You would only have to subclass the UISwitch renderer. And I wouldn't call subclassing a renderer to change render behavior overkill.

I would only apply this sort of styling when using multiple instances of a view. I still haven't understood, why when you only have one single object, you would need to do such changes in a NUI renderer block?

Why not just call

[textField setUnderlineColor: [NUISettings getColor:@"textfield-underline-color" withClass:className]
                    forState: UIControlStateNormal];

directly on the object?

[timbodeit]

Please have a look at cedbe29 on my custom-renderers branch.

I've made some changes to NUIRenderer as outlined above. Turns out these changes can actually clean up the class a bit.

Let me know what you think of this.

Note, Just in case that might not be clear: I'm not trying to take the overridability on a per-object basis away from you ;)
I'm only trying to understand your reasoning behind it, as the use case isn't quite clear to me yet.
There may very well be legitimate reasons to integrate both approaches into the framework simultaneously.

[timbodeit]

cedbe29 is also WIP.
Before this would be ready for a pull request, it would of course need some refactoring, additional test coverage for the renderer selection and a Readme update.
Also, I would probably provide deprecated versions of the unused methods I removed, just in case someone is calling them from outside of the framework.

[PabloLerma]

Hi guys! I will like to help more in the project but I don't want to do something that it's being already done. What do you think if we update the Roadmap wiki section?

[timbodeit]

By that you mean adding this discussion to the roadmap? Or what exactly do you have in mind?