The DSP Container widget, the utility to build custom widgets?

The DSP Container, tweaking the layout all the way down to the pixel.
As it turns out, the DSP Container widget opens up a lot of interesting possibilities to the 4GL programmer.
With Uniface RIA, HTML and CSS are used to design the layout. HTML and CSS allow for a very small level of tweaking, even to the smallest pixel of the web layout. If you combine that capability with the flexibility of the DSP Container widget, which allows for nesting of DSP components, the DSP component suddenly becomes a lot more than the tool to implement a complete Web page, suddenly the DSP component can be used to implement only a small, very specific, piece of functionality. Combine multiple DSP components using the DSP Container widget and there is your web application.
 
Using multiple components to construct a single application is on it self nothing new, but the awareness of the level on which you can tweak the layout might be: all the way down to the pixels – Full control!
As an example of the capabilities, I used the DSP Container widget to implement a tree, but obviously I could also use it to build tabs, message boxes, harmonicas, dropdown menus, tool bars, etc. Check it out:
Maybe I’ll add some more examples later on.
Gerton

3 thoughts on “The DSP Container widget, the utility to build custom widgets?”

  1. I’m a critic at the moment- no dought about that. I like that Compuware wants catch up with the web based world
    but the web has changed to be very complex. Far to complex to make it at easy as Client/Server. In the beginning
    when people began to use scripts like ASP, PERL, PHP they made every little function in a single script producing
    many many tiny fragments. Today functions are more and more capsuled in on script depending upon the usability.

    The point is, that YOU have the option to choose, which way you go. The DSPs doesn’t offer that because of the painted
    layout and the restrictions caused by talking to DOJO (which is a good framework). There are so many things in the
    DSPs where I just think some sort of “WTF!”- e.g. the clipboard functionality “which makes it easy to give the HTML to a
    web designer”! Please, Gerton, don’t tell people with DSPs Web is easy as Client/Server- … Web demands knowledge of the
    materia as HTML, JavaScript, CSS and the browsers.

    Felt like, i had to say that! Maybe you give me some response on this.

    some greetz to you,

    -GHAN-

  2. Hi Gerton,

    This is surely a nice feature but its a horrible scenario somehow.
    On the one side you want to reduce to load volume (DATA) by fragmenting the
    requests (Go away from FULL PAGE RENDERING). And on the other side you want to make every
    little functionality to a DSP in a such DSP container (as in the MusicShopDemo even a footer image!)
    causing overhead (as mentioned at the CBG summit: 827KB for a inital page load!).

    Don’t get me wrong- The feature is nice, yes, but if I want to make a good web application,
    then the fragments should initially come in ONE PIECE (Initial FULL PAGE LOAD) and after that
    take the desired data from anywhere u want (operations from the components).
    Remember the CU2008 and CBG slides “RIA development challenges” listing a very
    important point called “REUSE EXISTING C/S CODE”. This won’t be archieved
    with this heavy load of DSPcontainers. We don’t want to make a homepage with Uniface! We are
    in the situation to deliver some web based presentation of our exisiting products.

    How many DSP components would you plan for a medium sized application suite when the MusicShop already takes 26 DSPs?! And as you launch the first DSP (wich
    calls the next three DSPs, which again launches another bunch of DSPs) how do want to be able to
    debug that?! At the CBG summit you told me, this shouldn’t be that difficult, but i still think so.
    How many DSPs and complete applications are we supposed to send in as a test set if we run into trouble?! 🙂

    The way of using the DSPcontainer at the moment doesnt differ that much from the once popular
    I/FRAME thing. Instead of calling the components with a FRAME target you handle this to
    the JavaScript and let it control Uniface to push the html results in html containers …

Leave a Reply