I always find it healthy to come back and use code you wrote a while ago. There’s nothing like a bit of space to help see things in a new light. Often too you can be so focused on solving one problem that you don’t get a chance to step back and see the bigger picture.
And so it was when using my binding framework the other day. Don’t get me wrong, I really like it. But the first pass gave me flexibililty I needed, but not the simplicity I needed for day to day regular use. Who really wants to create presentation models using the following?
// somewhere at startup
Pectin.registerMixin(ComponentMixin.instance());
// then when you need a presentation model
PresentationModel<ComponentValueModel> pm =
new PresentationModel<ComponentValueModel>();
// and use the "firstName" value model..
pm.get("firstName").setEnabled(false);
What’s a ComponentValueModel anyway and why do I need one? As it turns out I almost always want one (since it gives my value models the common enabled, visible, and editable properties) so why do I have to specify it every time? Then there’s validation, you almost always need that too.
So, short story long, I’ve layered the API. The original classes have been moved to a lower level (i.e. GenericPresentationModel) and I’ve created new implementations that extend them and that come pre-configured with the default interfaces. I’ve also installed the associated Mixins automatically so for everyday use it’s now just:
// This is much better
PresentationModel pm = new PresentationModel();
pm.get("firstName").setEnabled(false);
Much nicer.