cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: disabling widgets
Date Wed, 25 Feb 2004 12:12:40 GMT

From: Antonio Gallardo [mailto:agallardo@agssa.net] 

> Reinhard Poetz dijo:
> > Sorry, I don't like this client-side approach.
> > We have to find something better because sometimes the 
> 'presentation 
> > state' of a widget can depend on the 'application state'. 
> Flowscript 
> > as controller should have access to both.
> 
> Hi Reinhard:
> 
> How manage a dynamic "show/hide a control" in a page without 
> doing a round-trip to the server?

Maybe I haven't understood Jeremy's requirements correctly but I don't
think the widget should change because a widget changed client-side
(without server interaction).

> Based on some observation while no-tech oriented users filled 
> HTML forms. It makes clear to me that they don't liked the 
> round-trip to the server. It was confusing to him! It is 
> clear a non-conventional interface. Also it waste time, no 
> matter how fast the connection (including the server) are. 
> The observation was related to calculated widgets.

I made similar observations too. This means to me that we have to offer
a clear client-side Javascript interface in order to control the
widgets.
+1 from me to give every widget a unique ID.

BTW, you suggested before

function toggleControl(id) {
    var element = document.getElementById(id);
    with (element.style) {
        if (display == "none") {
            display = ""
        } else{
            display = "none"
        }
    }
}

I think in this particular case you don't even need the id because pass
'this' to the toogleControl function which is a reference to the object.

function toggleControl(element) {
    with (element.style) {
        if (display == "none") {
            display = ""
        } else{
            display = "none"
        }
    }
}

> I think this is a similar case, because the show/hide control 
> is just a rendering page issue. Of course, you can add add 
> additional parameters to reflect the current "application 
> state" and let the page have the right behavior. If we 
> suspect that it can be a security concerns, there is a gold rule:
> 
> "Anything returned from the client must the checked again, 
> when the control return to the Flow (serversided)."

Of course, never trust the client ;-)

> Best Regards,
> 
> Antonio Gallardo.
> 
> P.S: I like this kind of discussion, because I will learn more! :-)


--
Reinhard


Mime
View raw message