Prev: How to use with-open-file with variable arglist?
Next: Are we close to a Lisp boom ?
From: Ken Tilton on 4 May 2008 09:31


Peter Hildebrandt wrote:
> On Sat, 03 May 2008 17:42:29 +0200, Lars Rune Nøstdal
> <larsnostdal(a)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: Lars Rune Nøstdal on 4 May 2008 14:17
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: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 6 May 2008 05:42
"Peter Hildebrandt" <peter.hildebrandt(a)gmail.com> writes:

> Wow, that's cool. Just a quick comment:
>
> On Sat, 03 May 2008 11:08:24 +0200, Lars Rune N�stdal
> <larsnostdal(a)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 on 6 May 2008 05:55
On Tue, 06 May 2008 11:42:42 +0200, Björn Lindberg <bjorn(a)runa.se> wrote:
> "Peter Hildebrandt" <peter.hildebrandt(a)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/
 | 
Pages: 1
Prev: How to use with-open-file with variable arglist?
Next: Are we close to a Lisp boom ?