= General suggestions:
- In the beginning, keep the current method naming to avoid confusion (and to be able to search on method names), but mark in the comments what's probably to be renamed.
- In most cases it would be hard to simplify things without a deep refactor. I may forget why I did something one way or another, but each time I decide "this should not be needed", sooner or later it proves needed in a specific scenario... Tests would be of great help here.
= Core
-
Class-level configuration:
-
Netzke::Base.config and Netzke::GridPanel.config are decoupled.
-
Example of usage: Netzke::GridPanel.configure :default_config => {:persistent_config => true} Netzke::GridPanel.configure :column_filters_available, true
-
Implement self.enforce_config_consistency to report incompatible configuration options
-
-
Instance-level configuration
- Whatever user puts into config[:ext_config], goes straight into the arguments for the constructor on the JS side. It'd be great to get rid of that. If we put everything together, without using ext_config, then we may want to implement something like validate_options, and 1) report those that are not known to the widget, 2) delete those that are not to be directly passed to the javascript side.
- Currently, the "strong children config" is used by BasicApp to signalize that all the children are rendered in the "config" mode.