Getting Ready for my UI Mapper Release
First there is the central UIMapper "framework" which totally makes sense to be open-source so that anyone can target it as a standard. This piece defines and parses the actual xml UI Mappings and contains the interfaces that must be implemented for the actual UI functionality. For instance, there is an IORMapper interface so that theoretically you can use any ORMapper, or even your own "old-fashioned" DAL for that matter. There is also an optional IResources interface so that you can localize all text using any approach you prefer. Then there are IListView, IEditView, and IEditWidget interfaces that the actual UI controls should implement if they want to be "standard" and somewhat interchangeable, at least as far as the basics go of course. My idea here is that you should be able to "map" your UI and later change the actual UI controls between those available by myself and other vendors. I hope you realize at this point that I'm trying to avoid vendor "lock-in" since you can swap any of the parts, using my ORMapper and UI controls today, and some other ORMapper/DAL and/or set of UI controls tomorrow. So this part I feel very comfortable making open source -- but I have a few questions even about this part -- should I name this part something different than "WilsonUIMapper" to make it feel more open, and does using ProjectDistributor for this make sense?
Then there are the actual UI "controls" that I have made, but which should in no way be required since I hope and encourage others to also make UI controls that target my "UI Mapper" framework. These are what I want to somehow try to sale for $50 since they represent some significant work -- but I still have several options so I still need some feedback. What I have are both Web and Windows versions of ListView (think grid) and EditView (think details) UI controls. The ListView controls allow you to specify which properties, and in which order, are columns in the list, as well as letting you specify header labels (localizable), width, alignment, format, and sortable. The built-in functionality is full support for selecting a row and paging and sorting, and filtering if you add the UI you want, as well as "links" for CRUD with optional deleting from the ListView with a confirmation dialog. A lot of people will say this isn't that different from the standard grids, and that's somewhat true, but the benefit here is that you can easily layout multiple "views" on the same data, either for more flexibility or for different languages or for different "roles", and you can even make it all user-definable if you save their preferences in your database. I also think the automatic support for paging and sorting, and deleting if you like it, is pretty slick, since the built-in grids use huge bloated datasets to "simulate" paging and sorting. So what are my options here, before I describe my EditView controls -- I can release the real executables for these ListView controls and keep the source for sale, or maybe release just one of the Web or Windows versions, or release just demos like I do now for my ORMapper. Maybe I even release the source for both of these and rely on only selling the EditView controls -- what do you think is a reasonable compromise to get people interested in "UI Mapping" while still making a little bit of money?
Finally there are my EditView and EditWidget controls, all of which come in both Web and Windows versions. The EditView controls create the overall "details" view of a single entity, existing or new, in either an editable or read-only manner. But note that the EditView controls do NOT actually "handle" the individual fields -- instead it creates an EditWidget for each field, and you can specify any EditWidget you want that implements my IEditWidget interface. I have 10 EditWidgets right now (maybe I'll have a couple more before release) that use the standard .NET controls, but you could very easily create (or get one from somewhere else maybe) versions that support your favorite 3rd party controls or your own business-specific needs. The types of things I have are "widgets" that represent single-line text, multi-line memos, read-only fields, boolean check-boxes, integer fields, number fields, date fields, single-select combo-boxes, multi-select list-boxes, and double-entry passwords. My integer and number boxes use just the standard text-boxes in Web and Windows flavors, with the appropriate validation, but you could easily create your own version using Infragistics or something else and plug them in with just a single configuration line in the mapping file. You may also want to create a more complex business-specific control, like an Address control or a custom Person Selection control -- that should also be easily doable. I think the EditView and the EditWidgets are where its more obvious how this can be a significantly "better" way to do things, at least for most of your basic "admin" screens anyhow. No longer do you have to carefully lineup 100 controls on a 100 different screens -- nor change them all when the designers want something slightly different. No longer will you have inconsistencies in your UI because integers or dates were handled one way on some screens and another way on another. No longer do you have to create separate versions for the Web and Windows, or different languages/locales -- you could even create another version of controls for cell phones if you wanted. So this I'm thinking I would only release in demo form, but I'm certainly still willing to hear your opinions as long as you keep in mind that I'm NOT going to just open-source everything.
So what do you think I should do -- and why? And what do you think of what I've laid out here -- any concerns or things you see missing that simply must be included from the beginning. Again my vision is to release the "framework" as open source so that others can also build on this, although my hope is that people will buy something from me to help compensate for my time. I also think there's a lot of value in a community of paid users from what I've seen with my ORMapper -- that may sound weird but its been very true. I get tons of feedback and suggestions and even bug-fixes and new features from my paid ORMapper users -- but I get nothing from my open-source things, unless you count tons of newbie questions that paying users seem to avoid for the most part. So please give me your thoughts now while I still have some choices remaining -- and thanks.