Simplifying

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.

This entry was posted in Development, UIs and Swing. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *