Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time

Lars Rune Nøstdal wrote:
vanekl wrote:
Lars Rune Nøstdal wrote:
[major announcement]


--
Lars Rune Nøstdal
http://nostdal.org/

Your timing is impeccable. I'm starting a new project and am
shopping around for the best framework that fits the project
needs. The biggest perceived need is trying to flip the client/
server model on its head and constructing as much of the widgets
client-side (or is this now the server?), and your framework at
first blush appears to fit this model. I hate page flash in IE,
and direct DOM manipulation fixes that. Should save me bandwidth,
too.


I forgot to comment on this. I'm not sure what you mean, but the
widgets are constructed (or coded?) on the server end.

You may have noticed that the client is slowly taking on more and
more of the server's tasks, such that the traditional server in some instances
may dump the majority of the processing off to the client and the server acts
more in a support role. The producer/consumer model is blurring, and in
some frameworks has actually flipped 180 degrees.
I haven't taken a close enough look around to know on which side
of the wire most of the "control" logic was happening in your
framework so I wasn't sure whether you had made the full switch, too.
That's not important to me as much as whether SW can handle selective
DOM manipulation seamlessly, which it can.

When they
are to be rendered on the client, or when they are determined to be
visible there, the HTML and JS needed to render them is transmitted
to the client. I am working on something that would allow one to
cache the basic common HTML+JS needed to render or create a new
widget instance on the client. That way, less will be transmitted
to the client when one, say, want to create 100 instances of the
same widget type that only differ a little.

To avoid flicker, one could transmit multiple updates in one go using
with-code-block.

Take this example;

* we want to provide a link that when clicked will toggle
between displaying a container or hiding a container

* a container is something that, well, contains multiple widgets

* when the link is clicked or toggled we'd want its text to change
between "Show" and "Hide" describing what it does when you click
it "this time"

(let ((state t))
(setf (on-click-of link)
(iambda
(with-code-block (:async t)
(if (setf state (not state))
(progn
(remove container)
(setf (html-of link-span) "Show"
(href-of link) "#container-id=shown"))
(progn
(add container (root))
(setf (html-of link-span) "Hide"
(href-of link) "#container-id=hidden")))))))


Without the WITH-CODE-BLOCK above, when clicking the first time (hiding),
the container would first disappear (remove container), then there would
be a short delay, then the text of the link would switch to "Show"
(setf (html-of link-span) "Show").

..but with the WITH-CODE-BLOCK added, both operations will happen at the same
time, or in the same "round trip".

..is this what you mean by avoiding flicker?

This is not exactly what I meant, but your code is helpful
and does provide a solution.
I was referring to the brain dead way IE6 refreshes the
entire screen by first whiting it out, and then redrawing
every control, even if no visible change has occurred.
This might happen on a POST, for example, when the data
is posted back to the server but the page remains the same.
I'm sure you noticed this doesn't happen with Mozilla.
Best way to get around this, as far as I can tell, is to
do the DOM manipulation manually (as you show above),
instead of doing the conventional Web 1.0 method of redrawing
the entire page. Yes, asp.net, I'm looking at you, bitch.

I guess i should have explained the reason why this "page flash"
business bothers me. I've noticed my style of web surfing acts
sort of like how an electron moves in a copper wire. Normally
things are fast and fluid, but when I have to make a decision
as to whether I should click on a conventional html button or link
and have the entire page redraw, even if none of the controls
change appearance I stop and think twice about continuing.
(This is equivalent to how an electron occasionally gets
stuck in its metal lattice in my metaphor.) I'm trying
to avoid that hesitation, that mental impedance one gets when one knows
that his environment is going to go away and something new is
about to take its place. It's a mental barrier that I think a
lot of people have, and if you are trying to get customers to
peruse your site, making the site morph to the customer's
commands is more friendly and has lower barriers than, in effect,
deciding to turn the entire screen white, go away for a few
seconds, and then redraw everything, sometimes looking exactly
like the screen was before. It makes coding more difficult,
but I think it makes sense monetarily if used for a store site,
for example. Less hesitation by customers should translate into
increased sales. That's the theory, at least.
.

Loading