(..in case my usenet client screws up the post, a copy is here:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/release-0.1-notes.txt )
SymbolicWeb; an AJAX/comet framework for Common Lisp.
Status: v0.1 (quite alpha)
Hi all,
Ok, this thing is still a bumpy ride and there isn't much yet, but I need to
try this.
So what is this? I'll just post some code and link to some "dead" HTML snapshots
of the results. After getting things up and running (see mention of INSTALL
below), start with "Hello World":
CL-USER> (in-package :sw)
SW> (add (make-instance 'span :html "Hello World") (root))
==> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/tmp/SymbolicWeb-1.html
..the stuff at the top is just some default header thing. Moving on:
SW> (children-of (root))
(#<SPAN {A739F89}>)
SW> (first (children-of (root)))
#<SPAN {A739F89}>
..ok great, so we got a tree with a SPAN widget in it. Let's try to change the
contents of the span widget:
SW> (defparameter *span* (first (children-of (root)))) ;; so we don't have to type as much
SW> (html-of *span*)
"Hello World"
SW> (setf (html-of *span*) "Hello Universe")
==> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/tmp/SymbolicWeb-2.html
So we can manipulate and add content at any time, and the page updates in
real-time as we go. This also works in callbacks triggered by client side events.
CSS also works; try this:
SW> (setf (background-color-of *span*) "lightblue")
==> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/tmp/SymbolicWeb-3.html
Try adding some callbacks:
SW> (setf (on-click-of *span*)
(lambda (&rest args)
(write-line "Universe said hi!")))
..when the user clicks, this is written to the REPL:
Universe said hi!
..but I'm lazy, so I want to trigger events from the server side:
SW> (trigger (on-click-of *span*))
Universe said hi!
This is great while doing interactive development. I use (REMOVE-ALL (ROOT))
at the top of a scratch buffer to tear things down, then build my widget tree
up again with my recent changes.
Let's add a second widget:
SW> (add (make-instance 'toggle-button
:children (list (make-instance 'image :src "http://www.normal-null.de/img/lisp/glossy120.jpg")))
(root))
==> http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/tmp/SymbolicWeb-4.html
(i'm in a hurry, and couldn't find an image with a transparent background ..)
When the user clicks, it changes color to illustrate its state. It is either
on or off (T/NIL). You can define how states are to look by supplying initarg
values for :TRUE-STATE-FN and :FALSE-STATE-FN. See the source code for
TOGGLE-BUTTON, here:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/src/widgets/toggle-button.lisp
Server side state change updates the client side visuals instantly:
(setf (state-of (second (children-of (root)))) t)
..or..
(toggle (second (children-of (root))))
Ok, that's it for now. See an example of a chat application here:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/examples/chat.lisp
..an old version (not the same source code) of it runs here:
http://swchat.nostdal.org/
See the file INSTALL for information about getting up and running:
http://common-lisp.net/~lnostdal/programming/lisp/symbolicweb/INSTALL
Some notes:
* SBCL only (must have thread support). I think it is possible to port to
other Lisps though.
* Only tested under Linux, but might run on other platforms where
SBCL runs.
* I did early tests on IE and Opera, and have confirmed that the client
side of SW runs there. However, the last couple of weeks I have only
been testing things on Firefox 2.x.
I will be at the IRC channel #symbolicweb on irc.freenode.org and
try to help anyone interested getting started. Questions can also be posted here:
http://groups.google.com/group/symbolicweb
Things I'm not happy with:
* The Aromyxo library/dependency. It is a huge mess. It is a place
I've been dumping code from REPL sessions since my early Lisp days.
* The way sw-jquery is selected as a JS backend using (use-package :sw-jquery)
in src/config.lisp. It seems "wrong" somehow. Maybe it isn't.
* src/widgets/dom-cache.lisp. It is just too complex and messy. I wanted to
use MOP. I need more time with AMOP, but I'm running out of time.
* It badly needs some unit tests. Someone is working on this though.
* It needs more examples and documentation.
* It should be possible to display a single widget (ex. chat output) at
multiple locations at the same time, I think.
* It needs IOLib etc. to scale.
* ..and more.
--
Lars Rune N�stdal
http://nostdal.org/
..no flamewar about how ajax is wrong? i'm kinda disappointed.. :)
--
Lars Rune N�stdal
http://nostdal.org/
From: Joost Diepenmaat
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <877iebz4qn.fsf@zeekat.nl>
Lars Rune Nøstdal <···········@gmail.com> writes:
> ..no flamewar about how ajax is wrong? i'm kinda disappointed.. :)
Just move over to comp.lang.javascript and start a thread on Comet :-)
Also; the nostdal.org chat page doesn't seem to like my browser
(iceweasel/firefox 2.0.0.14 on debian linux).
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat wrote:
> Lars Rune Nøstdal <···········@gmail.com> writes:
>
>> ..no flamewar about how ajax is wrong? i'm kinda disappointed.. :)
>
> Just move over to comp.lang.javascript and start a thread on Comet :-)
>
> Also; the nostdal.org chat page doesn't seem to like my browser
> (iceweasel/firefox 2.0.0.14 on debian linux).
>
That is strange .. I'm running the exact same setup here.
(PS: Opening two windows to the same page from the same browser
fails silently)
--
Lars Rune Nøstdal
http://nostdal.org/
From: Joost Diepenmaat
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <87zlr7xpm2.fsf@zeekat.nl>
Lars Rune Nøstdal <···········@gmail.com> writes:
> Joost Diepenmaat wrote:
>> Also; the nostdal.org chat page doesn't seem to like my browser
>> (iceweasel/firefox 2.0.0.14 on debian linux).
>
> That is strange .. I'm running the exact same setup here.
>
> (PS: Opening two windows to the same page from the same browser
> fails silently)
i've only got a single window open, and it does seem to load after a
while, but it *almost* locks up the browser at each click.
ps: I'm also running firebug (enabled) and noscript (disabled for your
site).
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat wrote:
> Lars Rune Nøstdal <···········@gmail.com> writes:
>
>> Joost Diepenmaat wrote:
>>> Also; the nostdal.org chat page doesn't seem to like my browser
>>> (iceweasel/firefox 2.0.0.14 on debian linux).
>> That is strange .. I'm running the exact same setup here.
>>
>> (PS: Opening two windows to the same page from the same browser
>> fails silently)
>
> i've only got a single window open, and it does seem to load after a
> while, but it *almost* locks up the browser at each click.
>
> ps: I'm also running firebug (enabled) and noscript (disabled for your
> site).
>
Hum, it isn't fast(#1), but it shouldn't lock down the browser. I did
try FF2.x and Opera on a Windows machine now, and things are responsive.
..I'm not sure what might be causing this. Firebug is enabled here also.
#1: Newer code has better performance and does less round-trips by the
way.
--
Lars Rune Nøstdal
http://nostdal.org/
From: Peter Hildebrandt
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <op.uak30ojxx6i8pv@babyfoot>
Wow, that's cool. Just a quick comment:
On Sat, 03 May 2008 11:08:24 +0200, Lars Rune Nøstdal
<···········@gmail.com> wrote:
> * SBCL only (must have thread support). I think it is possible to
> port to
> other Lisps though.
Have you looked at bordeaux-threads? From my experience it is quite easy
to migrate exisitng sbcl-specific code to use bordeaux-sockets (did it in
cells-gtk a while ago). In effect you get imnplemenation independence for
free :)
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> Wow, that's cool. Just a quick comment:
whoho! some feedback! .. lol ..thanks :)
> On Sat, 03 May 2008 11:08:24 +0200, Lars Rune Nøstdal
> <···········@gmail.com> wrote:
>> * SBCL only (must have thread support). I think it is possible to port to
>> other Lisps though.
>
> Have you looked at bordeaux-threads? From my experience it is quite
> easy to migrate exisitng sbcl-specific code to use bordeaux-sockets (did
> it in cells-gtk a while ago). In effect you get imnplemenation
> independence for free :)
Yes, I'll do a huge cleanup later and I'll probably port it
to bordeaux-threads then.
It needs more widgets. Maybe a table with pagination and
cells that can be updated from the server. I'd love to
hear suggestions and/or ideas!
--
Lars Rune Nøstdal
http://nostdal.org/
From: Peter Hildebrandt
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <op.uak6t9ucx6i8pv@babyfoot>
On Sat, 03 May 2008 17:42:29 +0200, Lars Rune Nøstdal
<···········@gmail.com> wrote:>
> It needs more widgets. Maybe a table with pagination and
> cells that can be updated from the server. I'd love to
> hear suggestions and/or ideas!
You asked for it, here it comes:
There is cl-weblocks, there is UCW, the brand-new OpenAIR, I read on
Planet Lisp that Attila Lendvai is making his own version of UCW, now your
symbolic web. So many projects geared towards the same goal.
I realize that lisp makes it so easy to tackle a fairly large problem, and
I realize how tempting that is. However, how much more effective would it
be if we all worked together on one web app toolkit? Even if it had
different backends (continuations/non-continuations based) and different
frontends (clients side js, widgets)?
Peter
PS. I am doing the same thing with cells-gtk: we have celtk, we have clg,
we have lambda-gtk, we have ltk, and yet I work on cells-gtk. I know the
temptation ...
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> On Sat, 03 May 2008 17:42:29 +0200, Lars Rune Nøstdal
> <···········@gmail.com> wrote:>
>
>> It needs more widgets. Maybe a table with pagination and
>> cells that can be updated from the server. I'd love to
>> hear suggestions and/or ideas!
>
> You asked for it, here it comes:
>
> There is cl-weblocks, there is UCW, the brand-new OpenAIR, I read on
> Planet Lisp that Attila Lendvai is making his own version of UCW, now
> your symbolic web. So many projects geared towards the same goal.
>
> I realize that lisp makes it so easy to tackle a fairly large problem,
> and I realize how tempting that is. However, how much more effective
> would it be if we all worked together on one web app toolkit? Even if
> it had different backends (continuations/non-continuations based) and
> different frontends (clients side js, widgets)?
I think the models or backends differ too much.
I'm not sure we have the same goals. I need something with a simple,
low-level well known event based model; like, say GTK+.
--
Lars Rune Nøstdal
http://nostdal.org/
PH> I realize that lisp makes it so easy to tackle a fairly large problem,
PH> and I realize how tempting that is. However, how much more effective
PH> would it be if we all worked together on one web app toolkit? Even if
PH> it had different backends (continuations/non-continuations based) and
PH> different frontends (clients side js, widgets)?
i'm afraid it's not possible to unite different approaches in one toolkit --
it will work suboptimally.
it seems UCW supports all what you've mentioned -- continuations,.
non-continuations, client side js, widgets.
and IMHO UCW is a bloody mess -- it is damn hard to use it partially because
there are many ways to do a thing, and it's hard to choose one.
so rather than monstrous package that supports everything i think it would
be better to have multiple toolkits with clear and well-defined goals.
also, competition is good. if toolkit does not evolves, it gets replaced
with more active ones. it's sort of evolution.
and also plurality can give innovation.for example, this SymbolicWeb things
that Lars showed to us seems to be quite a new thing -- haven't seen
anything like this before. would it be possible to implement thing like this
on UCW platform?
i think it's possible, but it would be way too messy sometimes it's easier
to start from scratch
On May 3, 7:48 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> PH> I realize that lisp makes it so easy to tackle a fairly large problem,
> PH> and I realize how tempting that is. However, how much more effective
> PH> would it be if we all worked together on one web app toolkit? Even if
> PH> it had different backends (continuations/non-continuations based) and
> PH> different frontends (clients side js, widgets)?
>
> i'm afraid it's not possible to unite different approaches in one toolkit --
> it will work suboptimally.
> it seems UCW supports all what you've mentioned -- continuations,.
> non-continuations, client side js, widgets.
> and IMHO UCW is a bloody mess -- it is damn hard to use it partially because
> there are many ways to do a thing, and it's hard to choose one.
>
> so rather than monstrous package that supports everything i think it would
> be better to have multiple toolkits with clear and well-defined goals.
>
> also, competition is good.
Competition is not always good. There is some economic goods that
doesn't work with laisse fare market , because they're natural
monopolies.
1.one firm can produce a desired output at a lower social cost than
two or more firms—that is, there are economies of scale in social
costs
2. only one firm is able to survive in the long run, even in the
absence of legal regulations or "predatory" measures by the monopolist.
[1] It is said that this is the result of high fixed costs of entering
an industry which causes long run average costs to decline as output
expands (i.e. economies of scale in private costs).
Imagine that you need a road between two cities, and there is a lot of
alternative, from straight one without touching any smaller towns
between our cities to some curved one with stops at almost every
village. There will be people who will prefer former , and those who
will prefer the latter, and even more will vote for something between
but the most foolish idea will be to build both of them and few
intermediate solutions because, you don't have the money to build 6
roads RIGHT. You must sacrifice something, like less instead of 6
lines highway all the way with high quality asphalt you'll have 6
roads with only one line with unfinished or poorly finished parts,
because any construction engineer will tell you 6 line road usually
cost much cheaper then 6 1 line roads.
Also don't forget auxilaries like gas stations, firms know where to
build gas stations if there is one road traveled by everybody but
there is 6 of them. Also where is the highway patrol help on the
road, medicine crews, maintenance crews etc. Everything is split
apart or non existing.
The situation with lisp web frameworks smells like that. There are
many web frameworks but like roads between our fictional cities
they're partially finished, lack utilities for normal travel so people
avoid them. So lisp has a lot of toy web framework, but none a serious
one. Don't get started about Marco Baringer, hacker like him could
easily build anything with brainfuck if needed, but mortals vote with
their feet. So I think we should have 1-2 web frameworks that doesn't
suck, than a gadzilion of toy ones.
I started working with weblocks instead of UCW because UCW was a total
unportable sbcl/linux specific mess.
So unless Symbolic Web has some really good reason for existence, and
I would like to hear them, I think that it's a step in a wrong
direction.
happy weekend lisping
> if toolkit does not evolves, it gets replaced
> with more active ones. it's sort of evolution.
>
> and also plurality can give innovation.for example, this SymbolicWeb things
> that Lars showed to us seems to be quite a new thing -- haven't seen
> anything like this before. would it be possible to implement thing like this
> on UCW platform?
> i think it's possible, but it would be way too messy sometimes it's easier
> to start from scratch
SB> Competition is not always good. There is some economic goods that
SB> doesn't work with laisse fare market , because they're natural
SB> monopolies.
web frameworks are not natural monopolies!
SB> avoid them. So lisp has a lot of toy web framework, but none a serious
SB> one.
you think that web framework has to be very complex.
believe me, it's not.
it's something that a experienced person can hack in couple of weeks -- and
it will be of quality that is *enough* for making useful commercial web
sites.
it's not a rocket science
actually that becomes a problem if web framework becomes too complex -- that
means that it's over-engineered, and needs to be simplified.
SB> So I think we should have 1-2 web frameworks that doesn't
SB> suck, than a gadzilion of toy ones
if there are gadzilion of them, that just means building one is easy.
as there are many different applications, it's quite natural to have many
different web frameworks that naturally fit applications (or are supposed
to).
SB> I started working with weblocks instead of UCW because UCW was a total
SB> unportable sbcl/linux specific mess.
and you have reasons to use something else than sbcl/linux?
On May 3, 11:03 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> SB> Competition is not always good. There is some economic goods that
> SB> doesn't work with laisse fare market , because they're natural
> SB> monopolies.
>
> web frameworks are not natural monopolies!
>
> SB> avoid them. So lisp has a lot of toy web framework, but none a serious
> SB> one.
>
> you think that web framework has to be very complex.
> believe me, it's not.
> it's something that a experienced person can hack in couple of weeks -- and
> it will be of quality that is *enough* for making useful commercial web
> sites.
> it's not a rocket science
>
> actually that becomes a problem if web framework becomes too complex -- that
> means that it's over-engineered, and needs to be simplified.
>
> SB> So I think we should have 1-2 web frameworks that doesn't
> SB> suck, than a gadzilion of toy ones
>
> if there are gadzilion of them, that just means building one is easy.
> as there are many different applications, it's quite natural to have many
> different web frameworks that naturally fit applications (or are supposed
> to).
You're arguments sound like amateur cook award constest winner telling
people that should drop premade food and hot dogs and cook their own
healthy and tasty meal. Well most of the people don't give a damn
about cooking or creating web frameworks, they want just to glue
things and get done their job. Something that's interesthing for
them. Creating web framework is not easy, if you take as web
framework:
1. Core
2. Premade widgets / controls whatever
3. Documentation
4. Learning material (tutorials , books etc)
5. Community
6. MANY of sites up and running
The only things that is relatively easy (and fun for some people) s
making 1, with some of 2, and next to nothing of the rest.
Or with other words I could make lisp implemenatation (interpreter for
a subset of lisp)over the weekend but making something like allegro or
sbcl takes a lot of time.
>
> SB> I started working with weblocks instead of UCW because UCW was a total
> SB> unportable sbcl/linux specific mess.
>
> and you have reasons to use something else than sbcl/linux?
I use whatever I want to use, one os/lisp framework is bad idea in my
eyes you mileage may vary.
??>> if there are gadzilion of them, that just means building one is easy.
??>> as there are many different applications, it's quite natural to have
??>> many different web frameworks that naturally fit applications (or are
??>> supposed to).
SB> You're arguments sound like amateur cook award constest winner telling
SB> people
i'm not giving advices here -- i just point to a fact that it is possible to
make successful projects both with self-made and third-party toolkits.
which way is feasible certainly depends on project's need.
you seem to have preconceptions that web toolkits are very complex things.
they are not -- just do an experiment, i'm pretty sure you'll be able to
hack something working in a day or so.
SB> that should drop premade food and hot dogs and cook their own healthy
SB> and tasty meal.
you don't need to be a "contest winner" to cook things.
SB> Well most of the people don't give a damn about cooking or creating
SB> web frameworks, they want just to glue things and get done their job.
i don't mind, there are open source frameworks available, aren't they?
SB> Something that's interesthing for them. Creating web framework is not
SB> easy, if you take as web framework:
SB> 1. Core
SB> 2. Premade widgets / controls whatever
actually only this is essential for successfully using a web framework
SB> 3. Documentation
SB> 4. Learning material (tutorials , books etc)
i do not see anything problematic here -- if we are speaking about a simple
toolkit,
it will require relatively small amounts of documentation and learning
materials, and they will be quite easy to do.
many sane programmers document their code no matter what they are doing.
also, if we are speaking about in-house framework, used by a person who
wrote it, it doesn't need much documentation, since that person already know
it.
if there is a bunch of developers working on a project, they can teach each
other verbally.
certainly some larger development team would require documentation -- but
often such larger teams already have documentation policies, so it's not a
problem.
SB> 5. Community
growing community requires good product and some time.
but if product is actively maintained, it's maintainer(s) can provide
"community help" -- this works fine until product becomes very complex.
and again, for in-house development there are no problems with community.
SB> 6. MANY of sites up and running
huh? let's also include fancy logo, site, slogan and whatever else is
required to satisfy you
SB> Or with other words I could make lisp implemenatation (interpreter for
SB> a subset of lisp)over the weekend but making something like allegro or
SB> sbcl takes a lot of time.
the difference is that Allegro and SBCL have to implement full Common Lisp
standard and other things like FFI,
while toolkit just needs to satisfy needs of one application.
SB>>> I started working with weblocks instead of UCW because UCW was a
SB>>> total unportable sbcl/linux specific mess.
??>> and you have reasons to use something else than sbcl/linux?
SB> I use whatever I want to use, one os/lisp framework is bad idea in my
SB> eyes you mileage may vary.
in other words, you have some "religious" preconceptions about different
operating systems and Lisp implementations,
and you care more about following your preconceptions rather than getting
things done in most effective way.
On May 5, 12:05 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> ??>> if there are gadzilion of them, that just means building one is easy.
> ??>> as there are many different applications, it's quite natural to have
> ??>> many different web frameworks that naturally fit applications (or are
> ??>> supposed to).
>
> SB> You're arguments sound like amateur cook award constest winner telling
> SB> people
>
> i'm not giving advices here -- i just point to a fact that it is possible to
> make successful projects both with self-made and third-party toolkits.
> which way is feasible certainly depends on project's need.
>
> you seem to have preconceptions that web toolkits are very complex things.
> they are not -- just do an experiment, i'm pretty sure you'll be able to
> hack something working in a day or so.
>
> SB> that should drop premade food and hot dogs and cook their own healthy
> SB> and tasty meal.
>
> you don't need to be a "contest winner" to cook things.
>
> SB> Well most of the people don't give a damn about cooking or creating
> SB> web frameworks, they want just to glue things and get done their job.
>
> i don't mind, there are open source frameworks available, aren't they?
>
> SB> Something that's interesthing for them. Creating web framework is not
> SB> easy, if you take as web framework:
> SB> 1. Core
> SB> 2. Premade widgets / controls whatever
>
> actually only this is essential for successfully using a web framework
>
> SB> 3. Documentation
> SB> 4. Learning material (tutorials , books etc)
>
> i do not see anything problematic here -- if we are speaking about a simple
> toolkit,
> it will require relatively small amounts of documentation and learning
> materials, and they will be quite easy to do.
> many sane programmers document their code no matter what they are doing.
>
> also, if we are speaking about in-house framework, used by a person who
> wrote it, it doesn't need much documentation, since that person already know
> it.
> if there is a bunch of developers working on a project, they can teach each
> other verbally.
> certainly some larger development team would require documentation -- but
> often such larger teams already have documentation policies, so it's not a
> problem.
>
> SB> 5. Community
>
> growing community requires good product and some time.
> but if product is actively maintained, it's maintainer(s) can provide
> "community help" -- this works fine until product becomes very complex.
>
> and again, for in-house development there are no problems with community.
>
> SB> 6. MANY of sites up and running
>
> huh? let's also include fancy logo, site, slogan and whatever else is
> required to satisfy you
>
> SB> Or with other words I could make lisp implemenatation (interpreter for
> SB> a subset of lisp)over the weekend but making something like allegro or
> SB> sbcl takes a lot of time.
>
> the difference is that Allegro and SBCL have to implement full Common Lisp
> standard and other things like FFI,
> while toolkit just needs to satisfy needs of one application.
We have misunderstanding of the view. There is a nice book called
crossing the chasm, Erick Sink wrote about it at http://www.ericsink.com/Act_Your_Age.html
.
Paraphrasing the basic idea fallows a short explanation. Basically
there are 5 types of peoploe in in technology acception.
Innovators, Early adapters, pragmatists, conservatives & laggards.
Innovators like Lars Rune start something new - Symbolic Web in our
case. So he has to *sell-it*(for lack of better word, if he wants to
be something that othe people beside he and his team will use it. So
there will go with curve of adaptation. There is different types of
people:
1. Early Adopters don't need much convincing. Some of them will try
your product just because it's new. They don't wait for anybody
else's endorsement. They are leaders who prefer to be on
the bleeding edge of technology.
3. Pragmatists will only buy your product when they see other
Pragmatists doing it. If this sounds like a chicken-and-egg paradox,
it is.
4. Conservatives will buy your product only after they see that the
Pragmatists are happy with it.
5. There is no way to predict the behavior of the Laggards. They may
never buy your product. You can safely ignore them.
So Symbolic web, will quickly gather early adapters, but they will
leave it as soon as something newer emerges. In order to succeed it
needs pragmatists. And they are hardest to get, because they're
*buying* only when they see other pragmatists buying. These people are
nothing like you. You're a geek and you enjoy technology for its own
sake. ***They just want their problems solved***, and they don't care
in the slightest about the religious wars we fight amongst ourselves.
Don't assume you know anything about the problems they're facing.
So you Alex, Lars Rune and Slava are the innovators. Your communities
are the early adapters. The people who are screaming for one quality
web framework are pragmatists. Maybe someday one web framework will
win the war, but untill then pragmatists will not make their sites in
lisp.
>
> SB>>> I started working with weblocks instead of UCW because UCW was a
> SB>>> total unportable sbcl/linux specific mess.
> ??>> and you have reasons to use something else than sbcl/linux?
> SB> I use whatever I want to use, one os/lisp framework is bad idea in my
> SB> eyes you mileage may vary.
>
> in other words, you have some "religious" preconceptions about different
> operating systems and Lisp implementations,
> and you care more about following your preconceptions rather than getting
> things done in most effective way.
That you are wrong I like sbcl and use it with Ubuntu.But if expecting
code to be portable across at least allegro/lw/sbcl and windows/linux
(I don't have access to Mac) is a religion then yes I am religious.
SB> We have misunderstanding of the view. There is a nice book called
SB> crossing the chasm, Erick Sink wrote about it at
http://www.ericsink.com/Act_Your_Age.html .
SB> Paraphrasing the basic idea fallows a short explanation. Basically
SB> there are 5 types of peoploe in in technology acception.
SB> Innovators, Early adapters, pragmatists, conservatives & laggards.
you see web framework as a must-use product.
but many [web] applications simply do not need any sophisticated web
frameworks at all -- they can just be built on top of very basic libraries,
e.g. mod_lisp, or even without them.
for example, consider PHP. standard PHP package does not include any
framework -- it just supports integration with Apache, that is roughly
equivalent to mod_lisp.
yet ordinary people (not some uber-cool hackers or innovators) can implement
their applications in bare PHP -- and be quite successful with this.
moreover, ones who use frameworks often end up with over-engineered
solutions and are damn hard to maintain.
of course, if you build application that is very similar to other
applications you've written, it's better to abstract common things, and
create so-called framework.
but often these applications are too different, and abstracting things from
them leads to overly-complex solutions.
??>> in other words, you have some "religious" preconceptions about
??>> different operating systems and Lisp implementations, and you care
??>> more about following your preconceptions rather than getting things
??>> done in most effective way.
SB> That you are wrong I like sbcl and use it with Ubuntu.But if expecting
SB> code to be portable across at least allegro/lw/sbcl and windows/linux
SB> (I don't have access to Mac) is a religion then yes I am religious.
even religious people have some reasoning behind their beliefs.
but what's your reason to require portability for webapp?
unlike desktop application, web applications are typically deployed in
controlled fashion -- people pick a server for application and configure it
according to application demands.
so for people who actually want application up and running portability has
very little value.
and it's quite adequate decision to sacrifice portability for, say,
features, or just cut development time on it.
it's another question if you're developing tools rather than application
itself -- tools might be required to play with other tools.
On May 5, 2:02 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> SB> We have misunderstanding of the view. There is a nice book called
> SB> crossing the chasm, Erick Sink wrote about it athttp://www.ericsink.com/Act_Your_Age.html.
> SB> Paraphrasing the basic idea fallows a short explanation. Basically
> SB> there are 5 types of peoploe in in technology acception.
> SB> Innovators, Early adapters, pragmatists, conservatives & laggards.
>
> you see web framework as a must-use product.
> but many [web] applications simply do not need any sophisticated web
> frameworks at all -- they can just be built on top of very basic libraries,
> e.g. mod_lisp, or even without them.
>
> for example, consider PHP. standard PHP package does not include any
> framework -- it just supports integration with Apache, that is roughly
> equivalent to mod_lisp.
> yet ordinary people (not some uber-cool hackers or innovators) can implement
> their applications in bare PHP -- and be quite successful with this.
>
> moreover, ones who use frameworks often end up with over-engineered
> solutions and are damn hard to maintain.
>
> of course, if you build application that is very similar to other
> applications you've written, it's better to abstract common things, and
> create so-called framework.
> but often these applications are too different, and abstracting things from
> them leads to overly-complex solutions.
And people prefer overly-complex solutions than bare metal things,
Strategy Letter IV: Bloatware and the 80/20 Myth
http://www.joelonsoftware.com/articles/fog0000000020.html it's people
like YOU who are fluent in the field who like tweak and build with
barebones, the rest of us just wan't get things done. People use php
because there is god damn script for everything, you need a calendar
here it is, credit card page with luhn formula balidator here it is,
connection with mysql embedded ... I tried once php and managed to
without learning much of it make a pretty good site by picking up the
staff on the internet. In lisp I would have to write manually. I
*suspect* that's the way people especially layman build apps in php.
So when I say web app for lisp I expect something that could be done
by GLUING not PROGRAMMING, because I hate to program in things that
doesn't interest me. Once we have a project in php and client
especially that all controls should be prefabricated. And if your
framework (including community and firms) doesn't offer control that
I need I'm not going to write it myself, I'll use another one that has
it, and I don't give a f*ch about managebility, your code needs to
grow a lot in size to become unmanageable. So there is no good enough
web framework for pragmatists in lisp. There is a proven web server,
html generating lib, databings but still no framework FOR THE
PRAGMATISTS. I think cl-weblocks has the best shot to become one but
we shall see.
>
> ??>> in other words, you have some "religious" preconceptions about
> ??>> different operating systems and Lisp implementations, and you care
> ??>> more about following your preconceptions rather than getting things
> ??>> done in most effective way.
>
> SB> That you are wrong I like sbcl and use it with Ubuntu.But if expecting
> SB> code to be portable across at least allegro/lw/sbcl and windows/linux
> SB> (I don't have access to Mac) is a religion then yes I am religious.
>
> even religious people have some reasoning behind their beliefs.
No faith is pure when it's unquestioned
>
> but what's your reason to require portability for webapp?
1. I prefer developing on windows and with IDE than on Linux with
Emacs/slime
2. I prefer to keep deployment options open
3. I hate lock ins for single implementation and OS
4. Quality of the code is very often correlated with portability, once
upon a time I made a patch for weblocks under sbcl/linux, testing it
with allegro, lw under both win and linux revealed a lot of low
quality and implementation specific code. So same as I test with opera/
safari/mozilla and ie 6/7 I like to test different oses and
implementations, and it always proved worthy my time leading to better
code and squashing bugs
>
> unlike desktop application, web applications are typically deployed in
> controlled fashion -- people pick a server for application and configure it
> according to application demands.
> so for people who actually want application up and running portability has
> very little value.
> and it's quite adequate decision to sacrifice portability for, say,
> features, or just cut development time on it.
>
> it's another question if you're developing tools rather than application
> itself -- tools might be required to play with other tools.
From: vanekl
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <fvj48n$818$1@aioe.org>
+1
Alex Mizrahi wrote:
> PH> I realize that lisp makes it so easy to tackle a fairly large problem,
> PH> and I realize how tempting that is. However, how much more effective
> PH> would it be if we all worked together on one web app toolkit? Even if
> PH> it had different backends (continuations/non-continuations based) and
> PH> different frontends (clients side js, widgets)?
>
> i'm afraid it's not possible to unite different approaches in one toolkit --
> it will work suboptimally.
> it seems UCW supports all what you've mentioned -- continuations,.
> non-continuations, client side js, widgets.
> and IMHO UCW is a bloody mess -- it is damn hard to use it partially because
> there are many ways to do a thing, and it's hard to choose one.
>
> so rather than monstrous package that supports everything i think it would
> be better to have multiple toolkits with clear and well-defined goals.
>
> also, competition is good. if toolkit does not evolves, it gets replaced
> with more active ones. it's sort of evolution.
>
> and also plurality can give innovation.for example, this SymbolicWeb things
> that Lars showed to us seems to be quite a new thing -- haven't seen
> anything like this before. would it be possible to implement thing like this
> on UCW platform?
> i think it's possible, but it would be way too messy sometimes it's easier
> to start from scratch
From: Ken Tilton
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <481dbaed$0$15200$607ed4bc@cv.net>
Peter Hildebrandt wrote:
> On Sat, 03 May 2008 17:42:29 +0200, Lars Rune Nøstdal
> <···········@gmail.com> wrote:>
>
>> It needs more widgets. Maybe a table with pagination and
>> cells that can be updated from the server. I'd love to
>> hear suggestions and/or ideas!
>
>
> You asked for it, here it comes:
>
> There is cl-weblocks, there is UCW, the brand-new OpenAIR, I read on
> Planet Lisp that Attila Lendvai is making his own version of UCW, now
> your symbolic web. So many projects geared towards the same goal.
>
> I realize that lisp makes it so easy to tackle a fairly large problem,
> and I realize how tempting that is. However, how much more effective
> would it be if we all worked together on one web app toolkit? Even if
> it had different backends (continuations/non-continuations based) and
> different frontends (clients side js, widgets)?
I think it is OK and perhaps preferrable to have multiple organisms
crawling around in the primoridal ooze. Then one or more of them
prevails (more if distinct evolutionary niches call for variety). But
this way we get a richer variety of ideas/approaches and avoid too-early
lock-in.
[How'm I doing on the lemons/lemonade conversion?]
Rationalizations aside, the problem may be that anyone who Actually
Writes Code does so because they are trying to Get Something Done, and
(as you say) it is actually easier/faster in Lisp to go from scratch
than try to learn and then live with someone else's decisions. More fun,
too, and from the fun comes 12-hour work days instead of 6.
[see "computed-class"]
The moral to library developers is to keep doing Good Things to get the
software to the point where people looking for what they have find it,
or close enough that it is in fact easier to use than to reinvent. The
sub-moral being that if someone says "Could you make this change?" the
answer should be as "Yes" as possible.
That's how Cells got lazy Cells (in lots of varieties).
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Frank "frgo" a.k.a DG1SBG
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <lzy76r2rn2.fsf@goenninger.net>
Lars Rune N�stdal <···········@gmail.com> writes:
> It needs more widgets. Maybe a table with pagination and
> cells that can be updated from the server. I'd love to
> hear suggestions and/or ideas!
Hmmm - how about using/leverang jQuery UI ? At least that would be the
widget set *I* am looking for ... And there's plenty of jQuery plugins
out there ...
BTW: nice idea! The comet thingy was the last bit I was missing in
openAIR so ... And I would need it on AllegroCL and/or Lispworks. I'd
be willing to help out there, if you want me to...
Keep going!
Best,
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
Frank "frgo" a.k.a DG1SBG wrote:
> Lars Rune N�stdal <···········@gmail.com> writes:
>
>> It needs more widgets. Maybe a table with pagination and
>> cells that can be updated from the server. I'd love to
>> hear suggestions and/or ideas!
>
> Hmmm - how about using/leverang jQuery UI ? At least that would be the
> widget set *I* am looking for ... And there's plenty of jQuery plugins
> out there ...
Yes, this would be interesting. I've looked at qooxdoo also, but I wanted
to start by building things "bottom up" first, from the Lisp side, so one
could add widgets by writing just Lisp instead of only by connecting to
client side JS-framework components.
> BTW: nice idea! The comet thingy was the last bit I was missing in
> openAIR so ... And I would need it on AllegroCL and/or Lispworks. I'd
> be willing to help out there, if you want me to...
Thanks .. :)
I guess what is needed is to get rid of the SBCL specific thread stuff;
bordeaux-threads was mentioned. I think it could be done quite easily
.. not sure yet .. there might be more.
--
Lars Rune N�stdal
http://nostdal.org/
From: Ken Tilton
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <481db69a$0$25022$607ed4bc@cv.net>
Lars Rune Nøstdal wrote:
> Peter Hildebrandt wrote:
>
>> Wow, that's cool. Just a quick comment:
>
>
> whoho! some feedback! .. lol ..thanks :)
This is comp.lang.lisp. Get used to disappointment.
As I recommended to Scott, just keep the spam machine going (and the
code moving forward). You might pick up only one/2 contributors, but
they will be worth it.
Me, the name SymbolicWeb got it past my radar initially but now that I
look at it it looks great, congrats.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
"Peter Hildebrandt" <·················@gmail.com> writes:
> Wow, that's cool. Just a quick comment:
>
> On Sat, 03 May 2008 11:08:24 +0200, Lars Rune N�stdal
> <···········@gmail.com> wrote:
>> * SBCL only (must have thread support). I think it is possible to
>> port to
>> other Lisps though.
>
> Have you looked at bordeaux-threads? From my experience it is quite
> easy to migrate exisitng sbcl-specific code to use bordeaux-sockets
> (did it in cells-gtk a while ago). In effect you get imnplemenation
> independence for free :)
Although looking at the intersection of implementations supported by
Bordeaux threads and implementations supporting native threads, the
"independance" gained at this time is debatable.
Bj�rn Lindberg
From: Peter Hildebrandt
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <op.uap8jcsjx6i8pv@babyfoot>
On Tue, 06 May 2008 11:42:42 +0200, Björn Lindberg <·····@runa.se> wrote:
> "Peter Hildebrandt" <·················@gmail.com> writes:
>> Have you looked at bordeaux-threads? From my experience it is quite
>> easy to migrate exisitng sbcl-specific code to use bordeaux-sockets
>> (did it in cells-gtk a while ago). In effect you get imnplemenation
>> independence for free :)
>
> Although looking at the intersection of implementations supported by
> Bordeaux threads and implementations supporting native threads, the
> "independance" gained at this time is debatable.
>
>
> Björn Lindberg
But then, if you wish to improve implementation independence, you can
contribute to bordeaux-threads instead of coding it into your specific
project. This way your work adds to every project using bordeaux-threads,
not merely the one at hand.
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: vanekl
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <fvj7pd$u4e$1@aioe.org>
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.
Prototype and JQuery are both running neck and neck in my
contest to determine which provides best value, and I still
haven't decided which horse to bet on. Jquery is obviously
the better choice if bandwidth is the most precious resource,
but I've seen some exquisite work done in Prototype. They
both look like quality libraries, but as with most important
decisions, it's time to stop reading and start writing test code.
The http://twistori.com/ site is a nice little showcase for
prototype. I think I'll see what it would like like in jquery to
get more of an idea of jquery's capabilities.
Anyway, (finally!) my question is this. I quickly took a gander
at the html code that was generated by your framework and liked
that it was slightly packed---saves on bandwidth---but wondered
if there was a more developer-friendly formatter available that
was able to add indentation and newlines and that stuff that
makes reading the markup bearable? Now that I've taken the time
to write this down, this is probably moot, huh? I guess firebug
would take that mangled copy and turn it into something that's
readable. I have firebug disabled right now so I can't tell.
I have 366 open tabs, and if I enabled firebug it would make
FF go into anaphylactic seizure. Never mind. I'll take a more
in-depth look at your code in the next couple of days after I
finish my twistori/jquery test.
Thanks for making this available. I'm not aware of any other CL
framework with this vision.
Oh, and for the guy who was having a hard time with the chat
page, turn firebug off and close a few tabs. Firebug is a
huge strain on FF. If that doesn't help, switch to FF3. It's
javascript speed is much improved, and the most recent FF3 nightly
build is now more usable than IE production code. I briefly
checked out your chat page and it loaded immediately (even with
366 tabs and utorrent chewing on my DSL line).
vanekl wrote:
> Lars Rune N�stdal wrote:
>> [major announcement]
>
> Anyway, (finally!) my question is this. I quickly took a gander
> at the html code that was generated by your framework and liked
> that it was slightly packed---saves on bandwidth---
The HTML is generated by CL-WHO. I think one can set CL-WHO to
add indentation to the generated HTML.
But, the HTML isn't that interesting; it is just an empty shell.
Or, well, if one _wanted_ to - one could have this shell contain
a completeish web-page of course.
Yes, you really need Firebug to see what's going on..
..when using widgets things are actually generated by JS code,
and Firebug will show you this in the "Console" tab for responses
to "comet requests". It looks like this:
$("#ROOT-87").append(decodeURIComponent("%3Cbutton%20id%3D'TOGGLE-BUTTON-175'%3E%3C%2Fbutton%3E"));
$("#TOGGLE-BUTTON-175").append(decodeURIComponent("%3Cspan%20id%3D'SPAN-173'%3E%3C%2Fspan%3E"));
$("#SPAN-173").html(decodeURIComponent("Toggle%20button%201"));
$("#TOGGLE-BUTTON-175").append(decodeURIComponent("%3Cimg%20id%3D'IMAGE-174'%2F%3E"));
$("#IMAGE-174").attr("src", decodeURIComponent("http%3A%2F%2Fwww.normal-null.de%2Fimg%2Flisp%2Fglossy120.jpg"));
$("#TOGGLE-BUTTON-175").css("background-color", "lightgray");
$("#TOGGLE-BUTTON-175").unbind("click");
$("#TOGGLE-BUTTON-175").bind("click",
*snip*(currently too) long code for binding an event*snip*);
..etc. After this code has run, you can still browse it as HTML
using Firebug to confirm that it is correct. Firebug updates, in
real time as things changes, a HTML tree/view of the page regardless
of how it is generated or manipulated.
Just note; the HTML/JS generated by the running swchat example is
not how things work or look like now. It runs on a much older version
of SW.
..I hope this made sense. I think it is very easy to understand once
one see it running and see this stuff happen. It is very very simple.
I use jQuery to generate the widgets, but if one wanted to one could
just send (yes, send) raw JS or JS that works vs. any other JS library
or toolkit one want to use:
SW> (run "return 2 * 3;") => "6"
SW> (run "alert(\"hi, i'm just plain javascript\");") :async t)
...
..from the REPL .. see?
> but wondered
> if there was a more developer-friendly formatter available that
> was able to add indentation and newlines and that stuff that
> makes reading the markup bearable? Now that I've taken the time
> to write this down, this is probably moot, huh? I guess firebug
> would take that mangled copy and turn it into something that's
> readable.
Yes, I use Firebug. It is the only way AFAIK to actually see what
is going on. Or, well, I guess I could have created debug-widgets
that displayed debug output etc.
> I have firebug disabled right now so I can't tell.
> I have 366 open tabs, and if I enabled firebug it would make
> FF go into anaphylactic seizure. Never mind. I'll take a more
> in-depth look at your code in the next couple of days after I
> finish my twistori/jquery test.
You can enable Firebug for a single domain/host only.
> Thanks for making this available. I'm not aware of any other CL
> framework with this vision.
Thanks :)
--
Lars Rune N�stdal
http://nostdal.org/
Lars Rune Nøstdal <···········@gmail.com> writes:
> Yes, I use Firebug. It is the only way AFAIK to actually see what
> is going on. Or, well, I guess I could have created debug-widgets
> that displayed debug output etc.
>
Have a look at mozlab. It provides a moz REPL that allows you to look at
and manipulate things inside firefox. If your an emacs user, it even has
an emacs interface. Its not a replacement for firebug, but provides
additional information/support and in a way that is sort of natural for
lispers.
see http://hyperstruct.net/projects/mozrepl
regards,
Tim
--
tcross (at) rapttech dot com dot au
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. 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?
--
Lars Rune N�stdal
http://nostdal.org/
From: vanekl
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <fvkir5$aka$1@aioe.org>
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.
vanekl wrote:
> 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.
Yes, in a way I guess I kinda want to bring the client to the server
so I can manipulate it there using a language I like. Then mirror
the effects at the client end in real time as I go.
It should really "feel" like the DOM or the browser is "right here
in the REPL" and also available at any time in any code.
I also want to maintain state so that when the user refreshes the page,
even though he probably doesn't have to do this, or when a widget is
hidden then shown again later - things are "redrawn as they where".
Wrapping things in "widgets" solve this; they are maybe like HTML with
closures -- or something like that.
> 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.
Hehe, let's kill it!
> 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.
I agree. I've noticed this also, and I can imagine it is a
stronger and more negative experience for a person not used to
computers or technology.
..this leads to another challenge wrt. expected behavior..
Some have asked me about maintenance of history (back/forward
buttons) combined with referenceability(#1), and I'm working on
some patches that will solve this in a, I think, clean way that
I haven't seen anyone take advantage of yet. :)
#1: The ability for a user to link to a certain location at a
site.
--
Lars Rune N�stdal
http://nostdal.org/
From: Ken Tilton
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <481decba$0$11625$607ed4bc@cv.net>
Lars Rune N�stdal wrote:
> vanekl wrote:
>
>> 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.
>
>
> Yes, in a way I guess I kinda want to bring the client to the server
> so I can manipulate it there using a language I like. Then mirror
> the effects at the client end in real time as I go.
>
> It should really "feel" like the DOM or the browser is "right here
> in the REPL" and also available at any time in any code.
Cells is good for this. It automates having one thing here on the Lisp
side and another thing there on The Other Side, which to date has been
CL<->Tk and CL<->GTk. yeah, one could getthe same effetc with Sufficient
Amounts of :before/:after/:around, like I said, Cells automates that.
>
> I also want to maintain state so that when the user refreshes the page,
> even though he probably doesn't have to do this, or when a widget is
> hidden then shown again later - things are "redrawn as they where".
> Wrapping things in "widgets" solve this; they are maybe like HTML with
> closures -- or something like that.
How about object identity for every node in the dom, and an include-node
bottleneck bit of xhtml that honors things like (a new) "visible"
attribute?
Getting back to Peter's Lament, is another problem that Lisp hacks are
so cool one cannot just always build on them? CellsJax might have to be
ground-up to be All That It Can Be.
>
>> 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.
>
>
> Hehe, let's kill it!
>
>> 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.
>
>
> I agree. I've noticed this also, and I can imagine it is a
> stronger and more negative experience for a person not used to
> computers or technology.
>
> ..this leads to another challenge wrt. expected behavior..
>
> Some have asked me about maintenance of history (back/forward
> buttons) combined with referenceability(#1), and I'm working on
> some patches that will solve this in a, I think, clean way that
> I haven't seen anyone take advantage of yet. :)
Sounds great, even without Cells. :)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> Lars Rune N�stdal wrote:
>> vanekl wrote:
>>> That's not important to me as much as whether SW can handle selective
>>> DOM manipulation seamlessly, which it can.
>>
>>
>> Yes, in a way I guess I kinda want to bring the client to the server
>> so I can manipulate it there using a language I like. Then mirror
>> the effects at the client end in real time as I go.
>>
>> It should really "feel" like the DOM or the browser is "right here
>> in the REPL" and also available at any time in any code.
>
> Cells is good for this. It automates having one thing here on the Lisp
> side and another thing there on The Other Side, which to date has been
> CL<->Tk and CL<->GTk. yeah, one could getthe same effetc with Sufficient
> Amounts of :before/:after/:around, like I said, Cells automates that.
Yup, I know what Cells is about. :) For now there isn't much dataflow going
on though; it is just a straightforward 1 to 1 mapping thing.
I'm thinking one could use Cells as a layer "outside" this stuff; when
one develop applications with connections between widgets and data
backends etc.. I think adding on-change hooks in the widgets will
make this possible..
>> I also want to maintain state so that when the user refreshes the page,
>> even though he probably doesn't have to do this, or when a widget is
>> hidden then shown again later - things are "redrawn as they where".
>> Wrapping things in "widgets" solve this; they are maybe like HTML with
>> closures -- or something like that.
>
> How about object identity for every node in the dom, and an include-node
> bottleneck bit of xhtml that honors things like (a new) "visible"
> attribute?
Hm, not sure I understand, but what's going on is that one create a tree
of widgets on the server (kinda like GTK+), then this tree is mirrored
"as we go" in the DOM on the client. So, what you say is already
happening, I think - or am I missing something?
One can hide/show widgets by manipulating the CSS display attribute:
(setf (display-of some-widget) "none")
..
(setf (display-of some-widget) "block")
..
(setf (display-of some-widget) "inline")
..not sure if this is what you meant. One can also just remove the
widget from the server side widget-tree:
(visibility-p-of some-widget) => T
(remove some-widget)
(visibility-p-of some-widget) => NIL
..and this will happen on the client side DOM tree also.
If you want raw HTML, things like the SPAN widget exist for that.
> Getting back to Peter's Lament, is another problem that Lisp hacks are
> so cool one cannot just always build on them? CellsJax might have to be
> ground-up to be All That It Can Be.
Ok, you lost me, I think. .. I'm from one of those crazy commie
countries, remember? .. hehe x)
I'm just going to guess; I don't want it to be cool, or, well, "too cool".
It should be as simple as possible so on can build on it. In a way I
feel a lot of web-frameworks already out there are "too cool" or maybe
too high-level; I can't seem to get to the core of them, so I needed SW. :)
--
Lars Rune N�stdal
http://nostdal.org/
From: vanekl
Subject: Re: ANN: SymbolicWeb v0.1 (quite alpha) w/ source code this time
Date:
Message-ID: <fvkn4q$s6p$1@aioe.org>
Lars Rune N�stdal wrote:
> vanekl wrote:
>> 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.
>
> Yes, in a way I guess I kinda want to bring the client to the server
> so I can manipulate it there using a language I like. Then mirror
> the effects at the client end in real time as I go.
>
> It should really "feel" like the DOM or the browser is "right here
> in the REPL" and also available at any time in any code.
Agreed. It really doesn't matter to me where the control logic mainly resides,
as long as this "feel" you mention is maintained. If I remember correctly,
IE6 starts having fits when more than 4,000 js objects are created, so
there's probably a limit on how much you can hand off to the client. And
as long as the feel can be maintained, there's not a lot of compelling reasons
why one would want to force the client to do everything, anyway.
> I also want to maintain state so that when the user refreshes the page,
> even though he probably doesn't have to do this, or when a widget is
> hidden then shown again later - things are "redrawn as they where".
> Wrapping things in "widgets" solve this; they are maybe like HTML with
> closures -- or something like that.
>
>> 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.
>
> Hehe, let's kill it!
>
>> 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.
>
> I agree. I've noticed this also, and I can imagine it is a
> stronger and more negative experience for a person not used to
> computers or technology.
Agreed.
> ..this leads to another challenge wrt. expected behavior..
Yup.
> Some have asked me about maintenance of history (back/forward
> buttons) combined with referenceability(#1), and I'm working on
> some patches that will solve this in a, I think, clean way that
> I haven't seen anyone take advantage of yet. :)
This is interesting. There's a huge push to make sites more RESTFUL.
I like the idea, but it's a trade-off. If I had to choose btn
client-side DOM manipulation OR FORWARD/BACK button functionality,
I would choose the former without reservation. I think the crowd
that insists that FORWARD/BACK buttons /must/ work correspond to
the same crowd that insist that universal COPY/PASTE must work on
smart phones, ergo the iPhone is a non-starter.
Designing is about choosing which trade-offs give you the best
overall value. Trying to satisfy every last request from every
last stakeholder is folly, IMO. Better to concentrate on core
competencies if resources are limited, which they usually are.
>
> #1: The ability for a user to link to a certain location at a
> site.
>