using ConfigPropertiesHandler

[oozoofrog]

i have rough idea want showing up.
@gmlwhdtjd

By

1. handling properties with key that their name
2. using default initializer for view in UIKit.
3. handling custom view and UIKit view by CustomConfigurableProperties

ETC

• principal code is newly added regist() function and that is main result of this idea.

• all of codes has in rough.

• UIView and subclasses has same initializer, and in most cases, it's okay to create it directly from the type. for default reference view. additionally, can hand over default reference view instance upon request.

• adding ConfigPropertiesHandlable for customizable and standardization to regist configurable properties.

• using regist function for regist prepared configs and, also adding custom configs.

• CustomConfigurablePropertys also good approach for customzing of properties, i want both. so may this needs priority. currently, CustomConfigurablePropertys more higher priority than registed properties.

• DefaultConfigurablePropertys now has some logics and contains value, so change name and type to final class ConfigurableProperties and add default static self instance.

[gmlwhdtjd]

A good idea to increase scalability is very clear and good idea.

The only concern is the part of the initializer. Default initializer without argument, it is not essential for swift, so there is a possibility of problems.
As the user can register his own custom view in Defualt, the part seems to be mentioned enough.

[oozoofrog]

A good idea to increase scalability is very clear and good idea.

The only concern is the part of the initializer. Default initializer without argument, it is not essential for swift, so there is a possibility of problems. As the user can register his own custom view in Defualt, the part seems to be mentioned enough.

@gmlwhdtjd

that's right. view in UIKit almost no problem for this. but user view is should be problem.

i have two counterplot about this.

1. add init() definition to CustomConfigurablePropertys.
2. change scope to internal of regist function and user use CustomConfigurablePropertys.

... oh it's not two. just one only for CustomConfigurablePropertys.

[oozoofrog]

@gmlwhdtjd oh, i was an idiot. custom view of user can get default reference view at regist.

[oozoofrog]

@gmlwhdtjd
now, regist and using protocol both working.

[oozoofrog]

A good idea to increase scalability is very clear and good idea.
The only concern is the part of the initializer. Default initializer without argument, it is not essential for swift, so there is a possibility of problems. As the user can register his own custom view in Defualt, the part seems to be mentioned enough.

@gmlwhdtjd

that's right. view in UIKit almost no problem for this. but user view is should be problem.

i have two counterplot about this.

1. add init() definition to CustomConfigurablePropertys.
2. change scope to internal of regist function and user use CustomConfigurablePropertys.

... oh it's not two. just one only for CustomConfigurablePropertys.

anyway this counterplots was so bad approach. 🤪

[gmlwhdtjd]

I have some idea of remove new() method thoroughly, Give me a second

[oozoofrog]

I have some idea of remove new() method thoroughly, Give me a second

oh my god, oh no you are god.

[gmlwhdtjd]

@oozoofrog

I changed to provide defaultReferenceView unconditionally when registering propertiesHandler.
So even a "view" in UIKit should provide a defaultReferenceView.

And for unregistered views, defaultReferenceView of superclass is used. This wasn't a problem at all, and this way I was able to remove the new() method entirely.

[oozoofrog]

@oozoofrog

I changed to provide defaultReferenceView unconditionally when registering propertiesHandler. So even a "view" in UIKit should provide a defaultReferenceView.

And for unregistered views, defaultReferenceView of superclass is used. This wasn't a problem at all, and this way I was able to remove the new() method entirely.

it seems much more clearly. 👍