Solutions Sought

Describe problems for which you'd like to solicit recommendations

I've been working on an open-source tool that combines (what I feel are) the best of ExBase, SMEQL (TopsQueryLanguage), and mouse-oriented SQL-centric DesktopDatabases such as MicrosoftAccess and ParaDox to produce a better instance of PowerfulAdHocDataProcessingTools, or at least provide a proof-of-concept to hopefully spark further projects. There's an open niche for a way to specify "chains of queries" and an occasional imperative loop or two in an easy-to-create, easy-to-read, and easy-to-manage way. I've refactored queries (including QueryByExample forms), macros, formats (DataDictionary), and scripts into what I believe to be fewer, more consistent, easier-to-view, and meta-able parts.

I tried to find a way to implement them in a web-based environment, but am running into annoying UI limitations. The most important gap is providing a combo-box in a data-grid. I need WebBrowserMissingWidgetWorkArounds. HtmlDomJsCss Pop-up menus are fairly easy for a few fields, but are slow and clunky when applied to a data grid. I would rather not get into the nitty-gritty of building GUI idioms from scratch if possible, for I want to focus on product features and not GUI's. And, I don't wish to switch languages, but am considering building a "table browser" in Java as a plan B. It would talk to a web-based scripting language, which is where most of the smarts will be. It is not meant as a GUI-builder (form-builder) tool, at least not as it's primary focus. Any suggestions?

-top

Write an 'idealized' domain-specific extensible intermediate language for describing the tables and available interactions (which columns may be updated, validation rules, relationships between tables, maybe information to regenerate/refresh the view, etc.). Then write a completely separate translation from this 'idealized' language into a UI language (be it HtmlDomJsCss or XUL or XAML or a Java/Flash/Silverlight applet or an <object></object> with a new MIME-type and a new browser-plugin). This strategy introduces YetAnotherIndirection and reduces coupling and interdependence of systems. It allows you to simply use the clunky UI for now, and upgrade or replace it on its own schedule. Cost is performance, but is not likely to be significant (and may ultimately be optimized away via static PartialEvaluation, and so is of little long-term significance).

Too much coupling between describing "what I want to display" and "how do I display it" has caused me headaches many times in the past. The above strategy breaks the problem into manageable pieces, and leaves me feeling better about the solution overall - in particular, it allows me to feel that imperfections or arbitrary limitations in the UI can be overcome later (when they actually become a problem), and it appeals to my perfectionist/idealist tendencies for the intermediate portion. Your mileage may vary.

An "under language" is kind of what I have in mind, except that it will be mostly table-based instead of language-centric (which should not be of any surprise). But it all hinges on relatively powerful open-source TableBrowser widget(s) capable of at least combo-box cells. Without that, it will be too clumsy to be practical, and thus nobody will bother using it enough to test and help improve it.

Note that it is mostly for batch and ad-hoc processing, not front-ends. Thus, form validation etc. will not be its primary focus.

An IntermediateLanguage would allow you to get away with using a less-powerful HTML or whatnot interface for the display. I think you give too much weight to the requirement for the "powerful, open-source TableBrowser widgets", at least in the SpikeSolution. And I think you underestimate the flexibility of HtmlDomJsCss - combo-box cells can be done with relative ease via flexible use of 'id', 'class', and JavaScript on an HTML Table. I suspect you envision something very specific that might not be possible with the tools available to you, but it is unlikely you need that very specific thing: you could probably nudge the idea a bit to make it fit the tools you have.

And if your goal is "batch and ad-hoc processing", then can you explain to me why "TableBrowser widgets" are a concern at all?

Are you familiar with MicrosoftAccess's query designer grid? I intend to build something along that line. One can type in column names or expressions, or they can use the pull-down-list having columns from pre-selected tables so that one does not have to type most column names. I have not found a decent work-around to combo-boxes. Putting a pull-down list next to a text-box is confusing, ugly, hacky, and hogs screen real-estate. And yes I could probably hack something up with HtmlDomJsCss, but HtmlDomJsCss tends to be version sensitive such that untested or future browser versions will likely break it or have unforeseen consequences. And they are usually slow and jittery, like Windows 3.0 on a 1987 286. I guess I'll just have to byte the bullet and live with the HtmlDomJsCss cockroach.

Consider GoogleWebKit. It produces high-performance HtmlDomJsCss, supports compatibility across browsers and browser-versions, supports construction of interactive pages (like Google Wave), And, just to irk you, it's type-safe - it compiles Java to HtmlDomJsCss. Even if you don't choose to use it, you should probably consider it. I suspect it beats your plan "B". I'll update the GWT page with a link to the current widget gallery, but it does support a great deal. Oh, and it isn't $495. It's free.

I'll have to first see if it can place combo-boxes and checkboxes inside a data grid table and do MDI. I couldn't find a near-match demo so far. Plus, it lacks other common TableBrowser idioms such as moving up and down via arrow keys and mouse-resizable column widths (display). A table-centric tool with lousy TableBrowser(s) is like a muscle-car (AmericanCulturalAssumption) with wheelbarrow tires.

CategorySolutions