Re: LSP violation or not

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 14:48:27 GMT

Responding to Matthies...

>>I guess I am asking why you need a framework for this at all. B-) Why
>>not implement the web GUI service subsystem once and sell that rather
>>than forcing the framework user to cobble the UI together at the widget
>>level? You can achieve further friendliness by providing a fancy
>>WYSIWYG tool to <reliably> create the configuration file for a given
>>application. The you don't even need a programmer to build the UI. B-)
>
>
> The GUIs in our applications tend to be too specialized and customized
> in look, structure and behavior to be mapped onto one generic pattern
> of presenting data with forms. Certain sub-panels with simple list or
> grid data or the like can be handled generically, and we do that, but
> that's typically just one widget (sub-tree) among many on a page.

Are you limited to a browser UI? If so, there really isn't a whole lot
of specialization or customization because HTML simply doesn't support
much. While the model I presented is simplistic (e.g., there are other
data aggregates than Table and Dataset), it isn't far off the HTML mark.
  What the subsystem does is abstract the invariants of HTML itself.
That allows all the details to be expressed in terms of data values.

Even if the browser UI is fat and there are custom applets that will
execute in the browser space it seems like the approach still applies.
The subsystem user still has to supply those custom widgets in an
encapsulated form so they can be passed to the browser. Those applets
are necessarily attached to the form via HTML so that the browser can
invoke them properly. That can be captured in the model as a
[CustomWidget] class related to the relevant model elements. When Page
"walks" the structure, the CustomeWidget.getApplet sucks the right
applet out of the library and Page embeds it in the initial HTML sent to
the browser for the form. To do that Page needs to know nothing about
what the aplet does.

To do that, all one needs is identity. The CustomWidget instance has
identity that it can map to the aplet library and can be used in
messages between the application and the browser. So once again, all
the initialization is quite generic and can be done from an external
configuration file. The user just has to supply the aplet library and
the identity mapping in the configuration file.

>
>
>> GUI and web builder tools have pioneered this approach to the
>>point where it is pretty cookbook, so I have to think there is
>>something else I don't know about driving your architecture.
>
>
> I believe the initial vision was to provide a VB-like GUI programming
> model.

That vision is what I am pushing back on. It is fundamentally a
programming view; you are trying to abstract how a /programmer/ would
build an individual UI. It seems to me that if one raises the level of
abstraction to the invariants of HTML, applets, and browser interactions
one can provide a more general solution implementation that requires no
3GL programming at all from the user's viewpoint. IOW, one should
emulate how the /user/ would build the UI.

Note that in RAD IDEs both the DB and the UI have been almost completely
automated by doing exactly that. Both are "programmed" graphically at a
much higher level of WYSIWYG abstraction than 3GL code. The only reason
VB exists in such environments is to support business rules that are
outside the DB and UI. Even when VB is used it is effectively just a
hook or callback into the DB/UI pipeline processing. Your framework may
well need to deal with the issues in your original post for the layers
between DB and UI that deal with arcane business rules, but for just the
UI I would look to the way RAD IDEs solve the problem (i.e., Just Do It).

The only difference between a RAD UI and your framework that you have
described (so far) is that the user can provide custom applets for the
browser. But that is a pretty basic facility that I think can be
abstracted as above in a quite generic implementation so that the user
is unconcerned with the linking details.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: url to ps/pdf
    ... browser at a link and clicked "Print" with a PS or PDF printer ... How are you getting the HTML pages now? ... Using a GUI web browser. ...
    (comp.unix.shell)
  • Re: url to ps/pdf
    ... popping up a GUI, would perform the same magic as if I pointed a web ... browser at a link and clicked "Print" with a PS or PDF printer ... How are you getting the HTML pages now? ...
    (comp.unix.shell)
  • Re: Easy GUI with HTML?
    ... I do know HTML quite well. ... browser (i.e., ... html) as a GUI for my C++ application? ... HTA is a regular HTML file with one special tag within HEAD ...
    (microsoft.public.vc.language)
  • Re: Simple question ??
    ... A web page is basically an HTML document. ... a technology that, at the most basic level, delivers HTML to a web browser. ... Internet Explorer, for example, can display Word documents, ... file format to a browser in its native state. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Toward WYSIWYG Web Page Authoring
    ... HTML and the web browser, ... Of course, even at the time of the first GUIs for developing HTML, WYSIWYG ... The best answer has emerged in the form of XML. ...
    (microsoft.public.dotnet.framework.aspnet)