[web-devel] missing web component needed: server-side page
michael at snoyman.com
Thu Jun 24 01:42:00 EDT 2010
On Wed, Jun 23, 2010 at 9:01 PM, Alberto G. Corona <agocorona at gmail.com>wrote:
> I forgot to send this to the list. This answers also some questions about
> the idea of server page control. I don´t think in to eliminate the option of
> client code, not at all. but server control is neccesary to ease
> interactions that MUST use data in the server.
> In fact, as I suggest here, pottentially, HJScript can be extended to make
> it run in the server or in the client depending on the requirements, just
> modifying (i guess) the underlying monad, because it has many of the common
> functionalities needed.
> Hi michael,
> More or less to solve these concrete problems is a requirement. I think
> neither using comunications using algebraic data types, nor JSON neither
> the client.
> Details below:
> 2010/6/22 Michael Snoyman <michael at snoyman.com>
>> I think it would be useful if we spoke in more concrete terms: in
>> particular, let's figure out some real world problems we want to solve,
>> instead of designing the perfect technology. I'll start with some simple
>> problems, feel free to add some of your own:
>> 1) Form validation. Here's an example from a project I'm working on now:
>> disable field B if field A has one of a list of values. We clearly need to
>> ensure server-side that field B has no value set if the conditions for A are
>> fulfilled, but we'd like to "gray out" the field client side.
>> because I have a copy of the HTML tree in the server( the way to
> maintain synchronization trough event forwarding to the server is not
> described here) I can check te value of the field A. If A meets the
> condition I just send to the browser the HTML DOM sentence
> care now to check the documentation and look for the details)
> in the browser the execution of
> eval("form.B.style.active=Disabled" )
> will disable the field.
> In fact the code would share ,much ideas and code with HJScript because
> HJSCript to make it run either in the server or the client, depending on the
> choices. HJScript uses HTML DOM.
> This case does a lot less sense if the control code does not make use of
> data in the server. For example, if the list of values of a combo box
> depends on the choice or values in another field in the form.
I understand the motivation here, but my biggest concern with this type of
approach is that it seems very unRESTful. I'm not a REST idealogue, but
planning to design a complex system that attempts to keep two identical
copies of browser state over a stateless protocol just doesn't seem
possible. I'm also concerned about Jeremy's comments regarding bandwidth
usage and latency.
The approach I would take is to accept the fact that we're going to have to
write code twice. But instead of writing a full-blown Haskell application,
(the idea behind widgets). If we do it properly, we can easily combine these
the Haskell properly, assuming the individual components are written
2) Ajax loading of pieces of pages. We can obviously make this very simple
>> ("download some HTML from this URL and stick it in this div") or much more
>> complex ("serialize this Haskell data structure to JSON, transfer it, parse
>> it client side and build up the DOM tree").
>> Just forward and eval the string
> "divName.innerHTML=\"text of th HTML to include\""
3) Perhaps not what you were thinking about, but easy integration with
>> This requires the detection of this condition. At the beginning, if the
> jscript code deoes not respond, ttoug the Ajax channel, then use HTML
Actually, it should work the opposite way, through graceful degradation. We
send a webpage that operates perfectly with HTML alone, and link in a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the web-devel