Lisp Server Pages (LSP)
Release 0.5d
Home page: http://lsp.sourceforge.net
Project page: https://sourceforge.net/project/?group_id=6252
Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
Contact email: ···@everest.com
We are pleased to announce Lisp Server Pages, or LSP, as an open source
project. LSP is a Common Lisp based technology for dynamic HTML
generation that transforms LSP documents embedded with Common Lisp into
executable HTML generation functions. Unlike many other dynamic content
packages, LSP succeeds in simultaneously providing the author with SGML
and lisp semantics while composing an LSP document.
LSP has two primary components-- an LSP page compilation facility, and a
server independent publishing facility. The page compilation facility is
nearly complete. It currently lacks support for tags TEXTAREA and
SELECT. The server independent site publishing facility is currently
less evolved. AllegroServe is well supported, and CL-HTTP is not so well
supported. We would like to also see support for Apache and so on, but
we neither have the time nor the knowledge for such an endeavor. Hence,
this LSP release is to be regarded as a developer release. We would
welcome developers that have an interest in using and extending LSP.
Documentation for LSP is included in the directory lsp-doc. This
directory also serves as a minimal demonstration of LSP's abilities. In
lsp-doc/lsp-intro.html, we describe how this directory can be easily
published to an available web server. Loading start.lisp (after loading
in AllegroServe or CL-HTTP) automatically does this for you.
Please send any bug reports, feature requests, comments, success stories
and so on to ···@everest.com. LSP is available at Sourceforge at
lsp.sourceforge.net.
Many thanks to our employer, Everest eCommerce Inc., in providing the
resources that have made it possible for us to develop this package, and
the encouragement to make it an open source project. More information
about Everest can be found at www.everest.com.
-- Sunil Mishra
This has been fixed. I was a little confused by the HTML page setup at
sourceforge.
Sunil
"Gisle S�lensminde" <·····@kolibri.ii.uib.no> wrote in message
·························@kolibri.ii.uib.no...
> In article <············@corp.supernews.com>, Sunil Mishra wrote:
> >Lisp Server Pages (LSP)
> >Release 0.5d
> >
> >
> >
> >Home page: http://lsp.sourceforge.net
> >Project page: https://sourceforge.net/project/?group_id=6252
> >Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
> >Contact email: ···@everest.com
>
> From your homepage at sourceforge:
>
> We're Sorry but this Project hasn't yet uploaded their personal webpage
yet.
> Please check back soon for updates or visit SourceForge
>
> --
> Gisle S�lensminde ( ·····@ii.uib.no )
>
> ln -s /dev/null ~/.netscape/cookies
"Sunil Mishra" <·······@arslogica.com> writes:
> LSP has two primary components-- an LSP page compilation facility, and a
> server independent publishing facility. The page compilation facility is
> nearly complete. It currently lacks support for tags TEXTAREA and
> SELECT. The server independent site publishing facility is currently
> less evolved. AllegroServe is well supported, and CL-HTTP is not so well
> supported. We would like to also see support for Apache and so on, but
> we neither have the time nor the knowledge for such an endeavor. Hence,
> this LSP release is to be regarded as a developer release. We would
> welcome developers that have an interest in using and extending LSP.
>
I've looked at it and at AllegroServe.
What do you see as a substantial advantage for using LSP above "raw"
AllegroServe functionality?
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
"Lieven Marchand" <···@bewoner.dma.be> wrote in message
···················@localhost.localdomain...
> "Sunil Mishra" <·······@arslogica.com> writes:
>
> I've looked at it and at AllegroServe.
>
> What do you see as a substantial advantage for using LSP above "raw"
> AllegroServe functionality?
>
AllegroServe is an HTTP server. LSP is dynamic content generation. LSP would
run on top of aserve. A component of aserve, htmlgen, would make a better
point of comparison. I would say that LSP is substantially more efficient
and powerful. There is no way to *compile* an htmlgen document. htmlgen has
to step through the document, one sexp at a time, and generate equivalent
HTML. LSP preserves as much as possible of the source document (which looks
almost exactly like regular HTML) in string form, and turns the remainder
into compiled lisp code. The compiled lisp code can also be easily
modularized for reuse across documents, which I think is pretty cool.
In so far as LSP may be compiled, a better point of comparison is the
presentation macros in CL-HTTP. Both CL-HTTP and htmlgen suffer from another
problem, that it is sometimes difficult to visualize precisely what HTML
some input lisp code (or sexp) will turn into. In particular, this is not
the kind of authoring you can hand over to an artist or designer to handle.
LSP embodies a handful of HTML extensions, and will continue to look
familiar to an artist/designer.
There is more information in the documentation on the web site. I'd like to
expand LSP into a site management system, but that is much further down the
line.
Sunil
From: Tim Bradshaw
Subject: Re: Announcing Lisp Server Pages
Date:
Message-ID: <ey3wvkb7ha2.fsf@cley.com>
* Sunil Mishra wrote:
> AllegroServe is an HTTP server. LSP is dynamic content generation. LSP would
> run on top of aserve. A component of aserve, htmlgen, would make a better
> point of comparison. I would say that LSP is substantially more efficient
> and powerful. There is no way to *compile* an htmlgen document. htmlgen has
> to step through the document, one sexp at a time, and generate equivalent
> HTML. LSP preserves as much as possible of the source document (which looks
> almost exactly like regular HTML) in string form, and turns the remainder
> into compiled lisp code. The compiled lisp code can also be easily
> modularized for reuse across documents, which I think is pretty
> cool.
I think that htmlgen compiles pretty much. Something like
(html
(:h1 "foo"))
macroexpands to:
(progn (progn (write-string "<h1>" *html-stream*)
(progn (write-string "foo" *html-stream*))
(write-string "</h1>" *html-stream*)))
That doesn't look like `stepping through the document' to me. Of
course you could compile further (for instance in this case you could
spot that this is just the string "<h1>foo</h1>"), but that's really a
matter of the macro expansion being smarter. The macro I posted the
other day compiles to a similar degree (actually I think slightly
less, as it ends up with something at the level of (emit-tag 'h1), but
that's just because I didn't write the compiler macro for EMIT-TAG...
> In so far as LSP may be compiled, a better point of comparison is the
> presentation macros in CL-HTTP. Both CL-HTTP and htmlgen suffer from another
> problem, that it is sometimes difficult to visualize precisely what HTML
> some input lisp code (or sexp) will turn into. In particular, this is not
> the kind of authoring you can hand over to an artist or designer to handle.
> LSP embodies a handful of HTML extensions, and will continue to look
> familiar to an artist/designer.
Again, I see this for cl-http's macros, but not for htmlgen or mine,
where you write something that looks really like html:
(:html
(:head
(:title "foo"))
(:body
(:h1 "foo")
"<p>this is my foo</p>"))
I guess you could argue that people can't hack the parens or
something, but those people probably need a visual design tool because
they can't hack the <> either...
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Sunil Mishra wrote:
>
> > AllegroServe is an HTTP server. LSP is dynamic content generation. LSP
would
> > run on top of aserve. A component of aserve, htmlgen, would make a
better
> > point of comparison. I would say that LSP is substantially more
efficient
> > and powerful. There is no way to *compile* an htmlgen document. htmlgen
has
> > to step through the document, one sexp at a time, and generate
equivalent
> > HTML. LSP preserves as much as possible of the source document (which
looks
> > almost exactly like regular HTML) in string form, and turns the
remainder
> > into compiled lisp code. The compiled lisp code can also be easily
> > modularized for reuse across documents, which I think is pretty
> > cool.
>
> I think that htmlgen compiles pretty much. Something like
>
> (html
> (:h1 "foo"))
>
> macroexpands to:
>
> (progn (progn (write-string "<h1>" *html-stream*)
> (progn (write-string "foo" *html-stream*))
> (write-string "</h1>" *html-stream*)))
Sorry, I take that back then. The efficiency argument then comes down to a
relatively small difference in the number of function calls one would have
to make. Which is not all that relevant.
> Again, I see this for cl-http's macros, but not for htmlgen or mine,
> where you write something that looks really like html:
>
> (:html
> (:head
> (:title "foo"))
> (:body
> (:h1 "foo")
> "<p>this is my foo</p>"))
>
> I guess you could argue that people can't hack the parens or
> something, but those people probably need a visual design tool because
> they can't hack the <> either...
>
> --tim
That is precisely the point though. Regardless of my programming skills, I
would not trust myself to come up with a decent user interface for public
consumption. Nor would I want to spend time on that task. It is arguably a
lot easier to get a better picture of your page layout when you do use one
of the whizzywig tools, rather than when you are staring at the raw HTML
document. That's why there exist page scripting languages. This is precisely
the niche that we are trying to fill, while at the same time making it
possible to treat the LSP document (which is very close to HTML in
structure) as a lisp program.
It's late, I have to run off to the train, perhaps we can continue this
argument tomorrow?
S
[...]
SM> That is precisely the point though. Regardless of my
SM> programming skills, I would not trust myself to come up with a
SM> decent user interface for public consumption.
OK as far as layout/looks go, the on rest of the UI you probably would
have a lot to say.
SM> [...] It is arguably a lot easier to get
SM> a better picture of your page layout when you do use one of
SM> the whizzywig tools, rather than when you are staring at the
SM> raw HTML document. That's why there exist page scripting
SM> languages. [...]
This does not follow in my mind but that's probably because I am
misunderstanding you. Are you arguing that page _scripting_
languages shorten the edit/test cycle? Or that you can marry
WYSIWYG tools with page scripting? If the latter, how? Do you
have a point-and-click tool that can edit HTML and turn it back
into the LSP syntax?
BM
Bulent Murtezaoglu <··@acm.org> writes:
> This does not follow in my mind but that's probably because I am
> misunderstanding you. Are you arguing that page _scripting_
> languages shorten the edit/test cycle? Or that you can marry
> WYSIWYG tools with page scripting? If the latter, how? Do you
> have a point-and-click tool that can edit HTML and turn it back
> into the LSP syntax?
We have something similiar to what Sunil is talking about, but we only
have one tag to support, and it just has a single attribute and no
content. In our normal development cycle we have an HTML production
person use a WYSIWYG tool to generate the HTML, and then once they
have it looking like they want, they add the tags for connecting the
HTML with our lisp web framework. The tools they use will preserve
these tags between edits as well. I believe they are using Adobe
GoLive.
This way, you HTML production staff, who are much better at making
good looking interfaces than our coders, get to handle all of the
graphic design and page layout, without having to either learn how to
use an editor that can handle paren matching (a must for lisp editing
of any kind) or learning our macro language. When it comes time to
tie in the dynamic data with the IMHO tags, they have no problem
handling that, since there is no execution model or state to track,
it's just "plug it in", simple substitution.
This is the same model that WebObjects uses BTW although the
complexity of their tag extensions to HTML is somewhere in between
IMHO and LSP. IN the long run I would like to have IMHO support both
the aserve macro mechanism for generating HTML, since in some cases it
is just easier to generate HTML at that level, and also to support
more sophisticated tags and template languages like LSP.
It seems that in the last month that alot of projects for web
programming in Lisp have come into their own.
--
Craig Brozefsky <·····@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
in article ··············@piracy.red-bean.com, Craig Brozefsky at
·····@red-bean.com wrote on 5/30/00 11:17 PM:
> Bulent Murtezaoglu <··@acm.org> writes:
>
>> This does not follow in my mind but that's probably because I am
>> misunderstanding you. Are you arguing that page _scripting_
>> languages shorten the edit/test cycle? Or that you can marry
>> WYSIWYG tools with page scripting? If the latter, how? Do you
>> have a point-and-click tool that can edit HTML and turn it back
>> into the LSP syntax?
>
> We have something similiar to what Sunil is talking about, but we only
> have one tag to support, and it just has a single attribute and no
> content. In our normal development cycle we have an HTML production
> person use a WYSIWYG tool to generate the HTML, and then once they
> have it looking like they want, they add the tags for connecting the
> HTML with our lisp web framework. The tools they use will preserve
> these tags between edits as well. I believe they are using Adobe
> GoLive.
>
> This way, you HTML production staff, who are much better at making
> good looking interfaces than our coders, get to handle all of the
> graphic design and page layout, without having to either learn how to
> use an editor that can handle paren matching (a must for lisp editing
> of any kind) or learning our macro language. When it comes time to
> tie in the dynamic data with the IMHO tags, they have no problem
> handling that, since there is no execution model or state to track,
> it's just "plug it in", simple substitution.
>
> This is the same model that WebObjects uses BTW although the
> complexity of their tag extensions to HTML is somewhere in between
> IMHO and LSP. IN the long run I would like to have IMHO support both
> the aserve macro mechanism for generating HTML, since in some cases it
> is just easier to generate HTML at that level, and also to support
> more sophisticated tags and template languages like LSP.
>
> It seems that in the last month that alot of projects for web
> programming in Lisp have come into their own.
Thank you for putting in your response! This expresses quite well what LSP
is trying to do. The tag soup that we have provided is there for good
reasons. We identified some common tasks that one would want to perform when
working with dynamic HTML. And then we provided the simplest hooks we could
to perform these tasks. (The listing below is aside from the ability to
embed lisp code.)
One key feature of LSP is to turn an arbitrary snippet of "HTML" into a lisp
function. This can be used to transform a row or set of rows in a table into
a function, easily populating a table with data. Such a function can even be
used from another web page, producing a great deal of flexibility. We have
taken a great deal of care in trying to preserve expected lisp semantics,
even at the reader level.
We also spent a fair amount of time working on form interfaces. It is easy
to relate the fields of a form (currently only of the INPUT variety, but
more to come) to the bindings the page receives in the URL or the request
body for a POST. This allows for the output of computed forms across
multiple HTML pages to share context.
Finally, we have simplified cookie access substantially. It is not clear if
the paradigm we have applied will work well in a server farm situation, but
that's not something we can worry about right now :-)
Sunil
From: Tim Bradshaw
Subject: Re: Announcing Lisp Server Pages
Date:
Message-ID: <ey3n1l76se5.fsf@cley.com>
* Sunil Mishra wrote:
> That is precisely the point though. Regardless of my programming skills, I
> would not trust myself to come up with a decent user interface for public
> consumption. Nor would I want to spend time on that task. It is arguably a
> lot easier to get a better picture of your page layout when you do use one
> of the whizzywig tools, rather than when you are staring at the raw HTML
> document. That's why there exist page scripting languages. This is precisely
> the niche that we are trying to fill, while at the same time making it
> possible to treat the LSP document (which is very close to HTML in
> structure) as a lisp program.
[Note, I'm not trying to win any battles here -- I think there's
likely plenty of room for several approaches and they all have
merits.]
OK, so would your approach be that you'd expect page-design people to
use an existing wizzy HTML-authoring tool to design most of the
content, but then to put in your (presumably small) bits of lisp (the
EVAL element and so on) using its `insert a random element'
facilities? That seems like quite a good approach to me.
Is LSP robust against junk in the non-special-to-it parts of the
document? I get the impression that a lot of wizzy HTML-generating
tools create some pretty grotty html with things like overlapping tags
(<x>ccc<y>ddd</x>eee</y> kind of thing).
--tim
Tim Bradshaw wrote in message ...
>OK, so would your approach be that you'd expect page-design people to
>use an existing wizzy HTML-authoring tool to design most of the
>content, but then to put in your (presumably small) bits of lisp (the
>EVAL element and so on) using its `insert a random element'
>facilities? That seems like quite a good approach to me.
>
>Is LSP robust against junk in the non-special-to-it parts of the
>document? I get the impression that a lot of wizzy HTML-generating
>tools create some pretty grotty html with things like overlapping tags
>(<x>ccc<y>ddd</x>eee</y> kind of thing).
The tools are getting much better at this, but they do put in a lot of cruft
that a normal HTML person would leave out. Many of the HTML tools could well
do with an HTML equivalent to a peephole optimizer.
MS Word is notoriously bad, however, for mucking up tags. But this will
affect just about any tool that wants to read an HTML file and transform it
in any way.
The other (minor) problem is the misuse of tags, and the lack of closing
tags (<P> and <BR> being most prevelant offenders), but most HTML readers
deal with this by closing off elements when they encounter them again in the
HTML stream (since most elements can't nest within themselves).
Will Hartung
(······@home.com)
in article ·······················@news1.alsv1.occa.home.com, Will Hartung
at ······@home.com wrote on 5/31/00 6:58 AM:
>
> Tim Bradshaw wrote in message ...
>> OK, so would your approach be that you'd expect page-design people to
>> use an existing wizzy HTML-authoring tool to design most of the
>> content, but then to put in your (presumably small) bits of lisp (the
>> EVAL element and so on) using its `insert a random element'
>> facilities? That seems like quite a good approach to me.
>>
>> Is LSP robust against junk in the non-special-to-it parts of the
>> document? I get the impression that a lot of wizzy HTML-generating
>> tools create some pretty grotty html with things like overlapping tags
>> (<x>ccc<y>ddd</x>eee</y> kind of thing).
>
>
> The tools are getting much better at this, but they do put in a lot of cruft
> that a normal HTML person would leave out. Many of the HTML tools could well
> do with an HTML equivalent to a peephole optimizer.
I had at one point started working on an HTML pattern matcher. Maybe I
should make that available too. It is most certainly in an unfinished state,
mainly because I could not get it to do the right thing for the task I had
at hand. But something like that might be more useful in the context of
rewriting HTML.
> MS Word is notoriously bad, however, for mucking up tags. But this will
> affect just about any tool that wants to read an HTML file and transform it
> in any way.
>
> The other (minor) problem is the misuse of tags, and the lack of closing
> tags (<P> and <BR> being most prevelant offenders), but most HTML readers
> deal with this by closing off elements when they encounter them again in the
> HTML stream (since most elements can't nest within themselves).
Heh, this reminds me of a "problem" that is left over in my HTML parser.
HTML 4.0 for some odd reason defines LINK, META etc as inclusions in HEAD
(and excluded in TITLE). The result is that my parser puts successive
occurrences of these tags inside one another.
Sunil
"Will Hartung" <······@home.com> writes:
> The other (minor) problem is the misuse of tags, and the lack of closing
> tags (<P> and <BR> being most prevelant offenders), but most HTML readers
> deal with this by closing off elements when they encounter them again in the
> HTML stream (since most elements can't nest within themselves).
The HTML DTD specifies that some tags have no closing (like <BR>), and
that other tags have `optional' closing (like <P>).
~jrm
in article ···············@cley.com, Tim Bradshaw at ···@cley.com wrote on
5/31/00 1:22 AM:
> * Sunil Mishra wrote:
>
>> That is precisely the point though. Regardless of my programming skills, I
>> would not trust myself to come up with a decent user interface for public
>> consumption. Nor would I want to spend time on that task. It is arguably a
>> lot easier to get a better picture of your page layout when you do use one
>> of the whizzywig tools, rather than when you are staring at the raw HTML
>> document. That's why there exist page scripting languages. This is precisely
>> the niche that we are trying to fill, while at the same time making it
>> possible to treat the LSP document (which is very close to HTML in
>> structure) as a lisp program.
>
> [Note, I'm not trying to win any battles here -- I think there's
> likely plenty of room for several approaches and they all have
> merits.]
Nor am I, I was in a rush, and didn't have the time to edit my response in
all the excitement.
> OK, so would your approach be that you'd expect page-design people to
> use an existing wizzy HTML-authoring tool to design most of the
> content, but then to put in your (presumably small) bits of lisp (the
> EVAL element and so on) using its `insert a random element'
> facilities? That seems like quite a good approach to me.
> L
> Is LSP robust against junk in the non-special-to-it parts of the
> document? I get the impression that a lot of wizzy HTML-generating
> tools create some pretty grotty html with things like overlapping tags
> (<x>ccc<y>ddd</x>eee</y> kind of thing).
LSP uses the HTML parser I had written for CL-HTTP to do its parsing. It is
robust against junk insofar as the parser is. (The parser has also been
worked over a fair bit to eliminate various bugs and dependencies upon
CL-HTTP code, but hooks into it rather nicely nevertheless.)
Further work on the parser would be a big win too. Having the parser
*validate* the LSP source and generate the appropriate warnings would be
good, but shall have to be a lower priority given the existence of nsglmls
and company.
Sunil
Tim Bradshaw wrote in message ...
>* Sunil Mishra wrote:
>
>> LSP preserves as much as possible of the source document (which looks
>> almost exactly like regular HTML) in string form, and turns the remainder
>> into compiled lisp code. The compiled lisp code can also be easily
>> modularized for reuse across documents, which I think is pretty
>> cool.
>
>I think that htmlgen compiles pretty much. Something like
>
> (html
> (:h1 "foo"))
>
>macroexpands to:
>
> (progn (progn (write-string "<h1>" *html-stream*)
> (progn (write-string "foo" *html-stream*))
> (write-string "</h1>" *html-stream*)))
>
>
*snip*
>
>Again, I see this for cl-http's macros, but not for htmlgen or mine,
>where you write something that looks really like html:
>
> (:html
> (:head
> (:title "foo"))
> (:body
> (:h1 "foo")
> "<p>this is my foo</p>"))
>
>I guess you could argue that people can't hack the parens or
>something, but those people probably need a visual design tool because
>they can't hack the <> either...
They both seem to do essentially the same thing. LSP seems to convert HTML
into a Lisp construct, whereas htmlgen and its brethren allow one to "write
HTML" in Lisp. At this stage you'd think that LSP could save some time and
re-use some code if it converted HTML into htmlgen, and then let htmlgen do
"the dirty work".
An interesting side show that would be worth considering is over at
www.enhydra.com. There they have this program called XMLC. It's pretty
crafty.
What it does is essentially converts an HTML (or XML) file into a Java
program that creates a DOM object from it. As an enhancement, if you add the
ID attribute to the tags in the HTML (I think that ID is allowed on pretty
much every tag now), then they create a getTag method that brings you to the
point within the DOM structure where that tag is located, so you can
manipulate it. When all is said and done, you have a Java class that
represents the HTML file, and the segments that you're interested in within
that HTML file.
This is quite handy, as it lets you seperate the code behind the page for
the dynamic elements from the page itself, a shortcoming of the JSP/ASP/PHP
etc models. (And perhaps LSP, I haven't looked at these yet).
This is particularly important because once you agree on your ID names and
conventions (they need to be unique within the page), then the HTML is
"unspoiled" by application code. Save for keeping the ID codes around with
the tags, any HTML editor (both silicon and carbon based) can work with the
main document without having to work around the logic on the page. A classic
case of the mock-ups used for storyboarding being identical to the
production pages.
I haven't seen how they do this in XMLC with Java, but with Lisp it is very
easy to keep the HTML and the code completely seperated, whereas with Java I
would think you would need to have the custom code and the generated code
within the same physical file (perhaps there's an include directive or you
can use cpp or m4 with Java). Also with Lisp, with a little tweaking, you
can easily have a group of documents specialize on a base class, and generic
functions handle the page by page details, while the base class handles the
meta pieces.
Also, there's no reason to go to the level of a DOM if you don't need to
manipulate the page at that level. Most pages are more "fill in the blank"
or "repeat this block" (a derivation of fill in the blank). So, rather than
convert the document into a large tree, convert it into a literal template.
Then, when you "generate lisp", the contents of those tags that are ID'd can
be yanked out of the document en masse, converted into htmlgen macros and
placed into a skeleton method ready to go.
Then, you can do something like this:
[test.html]
<HTML><HEAD><TITLE ID="doctitle">This is a title</TITLE></HEAD><BODY><SPAN
ID="text">This is some text</SPAN></BODY></HTML>
[test-html-render.lsp]
(defclass test-html (htmldoc)
((bodytext :initform "<HTML><HEAD></HEAD><BODY></BODY></HTML>")))
[test-html-gf.lsp]
(defmethod render-doc ((doc test-html) (s html-stream))
(let ((txt (slot-value doc 'bodytext)))
(princ s (subseq txt 0 11))
(render-tag-doctitle doc s)
(princ s (subseq txt 12 24))
(render-tag-text doc s)
(princ s (subseq txt 25 38))))
(defmethod render-tag-doctitle ((doc test-html) (s html-stream))
(with-html-stream s
(html (:title "This is a title"))))
(defmethod render-tag-text ((doc test-html) (s html-stream))
(with-html-stream s
(html (:span "This is some text"))))
Anyway, the idea is that the only real thing that the generator needs to
create is the render-doc GF. In this case, it yanks out the entire ID'd tag
and places it into a GF, and it has the flexibility of doing whatever it
finds "most efficient" (see "Sufficiently smart compiler") to the boiler
plate HTML. If you happened to nest ID'd tags, then the generator would call
those GFs inside of the htmlgen'd GFs.
But once created, you wouldn't have to recreate the test-html-gf.lsp file.
You'd specialize this file (of course, what you REALLY want to do is have
the generator read the GF file, and create any GF's that are not defined in
it, so that you can easily add tags to an existing file).
Once in this mode, all of your code is seperated from your HTML designers.
This leaves the HTML up to the creative/artistic/layout folks versus the
logical/no-sense-of-color-or-design programmers. With JSPs et al you get
HTML guys that can't code, or coders that can't do HTML creating your pages.
Of course in the server, you can detect file changes, recompile on the fly,
and reload on the fly.
Throw in a framework to handle all of the mutlipart/form data, and you're in
business doing Interesting Things.
This is where I think something like LSP should move towards. I also think
that it should move itself out of the web server and interact with any web
server through a socket, like that other group does using the Apache JServ
module to talk to their Lisp application server.
IMHO, IANAL, etc.
Will Hartung
(······@home.com)
"Will Hartung" <······@home.com> wrote in message
····························@news1.alsv1.occa.home.com...
> They both seem to do essentially the same thing. LSP seems to convert HTML
> into a Lisp construct, whereas htmlgen and its brethren allow one to
"write
> HTML" in Lisp. At this stage you'd think that LSP could save some time and
> re-use some code if it converted HTML into htmlgen, and then let htmlgen
do
> "the dirty work".
I'm not entirely clear on what you mean by this. Are you suggesting a one
time operation where HTML is converted to htmlgen syntax in a one-off
operation, and assumed to not change? The problem then is that if the
powers-that-be decide to change the corporate look, one would have to start
over from scratch, writing HTML, turning it into htmlgen, then reinserting
all the lispisms. It might well be that this is the easiest way out of the
situation... But my instincts favor a process that has fewer steps to it.
> An interesting side show that would be worth considering is over at
> www.enhydra.com. There they have this program called XMLC. It's pretty
> crafty.
>
> What it does is essentially converts an HTML (or XML) file into a Java
> program that creates a DOM object from it. As an enhancement, if you add
the
> ID attribute to the tags in the HTML (I think that ID is allowed on pretty
> much every tag now), then they create a getTag method that brings you to
the
> point within the DOM structure where that tag is located, so you can
> manipulate it. When all is said and done, you have a Java class that
> represents the HTML file, and the segments that you're interested in
within
> that HTML file.
>
> This is quite handy, as it lets you seperate the code behind the page for
> the dynamic elements from the page itself, a shortcoming of the
JSP/ASP/PHP
> etc models. (And perhaps LSP, I haven't looked at these yet).
LSP was not designed to work this way. The parser output would probably be
substantially different from the DOM specs, as we try to be clever about
what structures we parse and save and what we leave as strings. That is not
to say that LSP could not be *extended* to have a more DOM-like interface,
but the transformation from parsed structures to code would have to be a
compile time operation, as would the linking of the external code to the
parser output. Otherwise there would be a substantial loss in efficiency.
> This is particularly important because once you agree on your ID names and
> conventions (they need to be unique within the page), then the HTML is
> "unspoiled" by application code. Save for keeping the ID codes around with
> the tags, any HTML editor (both silicon and carbon based) can work with
the
> main document without having to work around the logic on the page. A
classic
> case of the mock-ups used for storyboarding being identical to the
> production pages.
>
> I haven't seen how they do this in XMLC with Java, but with Lisp it is
very
> easy to keep the HTML and the code completely seperated, whereas with Java
I
> would think you would need to have the custom code and the generated code
> within the same physical file (perhaps there's an include directive or you
> can use cpp or m4 with Java). Also with Lisp, with a little tweaking, you
> can easily have a group of documents specialize on a base class, and
generic
> functions handle the page by page details, while the base class handles
the
> meta pieces.
Another question that arises here is one of engineering practice. Is it a
good idea to keep code and HTML so separate? While programming, such
modularization is of course a good thing. While documenting, on the other
hand, I tend to think that having the documentation near the code is better.
So, is writing dynamic methods (in lisp or any other language) to work with
a given HTML document more like writing two parts of a given program, or is
it more like annotating the HTML with some executable code?
> Also, there's no reason to go to the level of a DOM if you don't need to
> manipulate the page at that level. Most pages are more "fill in the blank"
> or "repeat this block" (a derivation of fill in the blank). So, rather
than
> convert the document into a large tree, convert it into a literal
template.
> Then, when you "generate lisp", the contents of those tags that are ID'd
can
> be yanked out of the document en masse, converted into htmlgen macros and
> placed into a skeleton method ready to go.
>
> Then, you can do something like this:
>
> [test.html]
>
> <HTML><HEAD><TITLE ID="doctitle">This is a title</TITLE></HEAD><BODY><SPAN
> ID="text">This is some text</SPAN></BODY></HTML>
>
> [test-html-render.lsp]
>
> (defclass test-html (htmldoc)
> ((bodytext :initform "<HTML><HEAD></HEAD><BODY></BODY></HTML>")))
>
> [test-html-gf.lsp]
> (defmethod render-doc ((doc test-html) (s html-stream))
> (let ((txt (slot-value doc 'bodytext)))
> (princ s (subseq txt 0 11))
> (render-tag-doctitle doc s)
> (princ s (subseq txt 12 24))
> (render-tag-text doc s)
> (princ s (subseq txt 25 38))))
>
> (defmethod render-tag-doctitle ((doc test-html) (s html-stream))
> (with-html-stream s
> (html (:title "This is a title"))))
>
> (defmethod render-tag-text ((doc test-html) (s html-stream))
> (with-html-stream s
> (html (:span "This is some text"))))
>
>
> Anyway, the idea is that the only real thing that the generator needs to
> create is the render-doc GF. In this case, it yanks out the entire ID'd
tag
> and places it into a GF, and it has the flexibility of doing whatever it
> finds "most efficient" (see "Sufficiently smart compiler") to the boiler
> plate HTML. If you happened to nest ID'd tags, then the generator would
call
> those GFs inside of the htmlgen'd GFs.
>
> But once created, you wouldn't have to recreate the test-html-gf.lsp file.
> You'd specialize this file (of course, what you REALLY want to do is have
> the generator read the GF file, and create any GF's that are not defined
in
> it, so that you can easily add tags to an existing file).
>
> Once in this mode, all of your code is seperated from your HTML designers.
> This leaves the HTML up to the creative/artistic/layout folks versus the
> logical/no-sense-of-color-or-design programmers. With JSPs et al you get
> HTML guys that can't code, or coders that can't do HTML creating your
pages.
>
> Of course in the server, you can detect file changes, recompile on the
fly,
> and reload on the fly.
>
> Throw in a framework to handle all of the mutlipart/form data, and you're
in
> business doing Interesting Things.
>
> This is where I think something like LSP should move towards. I also think
> that it should move itself out of the web server and interact with any web
> server through a socket, like that other group does using the Apache JServ
> module to talk to their Lisp application server.
Thanks for the feedback. I'll have to think about this a little bit more. It
might be better to make such changes to LSP once we begin moving to xhtml,
as xml is better specified than HTML. But first I'd like to have LSP working
in the model we have defined right now...
Sunil
"Sunil Mishra" <·······@arslogica.com> writes:
> Another question that arises here is one of engineering practice. Is it a
> good idea to keep code and HTML so separate? While programming, such
> modularization is of course a good thing. While documenting, on the other
> hand, I tend to think that having the documentation near the code is better.
> So, is writing dynamic methods (in lisp or any other language) to work with
> a given HTML document more like writing two parts of a given program, or is
> it more like annotating the HTML with some executable code?
;;; Just adding my two silly little cents (USD/EUR, take your pick)...
IMHO mixing HTML and code-snippets is the right thing todo, just as
you don't usually separate the GUI and the underlying GUI code.
What obviously should be seperated out as far as possible is the
code doing the real work (i.e. the application logic, internal
representation, etc.). But code and GUI stuff that have to change
together to continue to work should be kept together, or otherwise
you'll have serious maintenance problems, IMHO, especially since
there is usually much less support for keeping code and external
entities in sync, than there is for keeping code and code in sync.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Sunil Mishra wrote in message ...
>
>"Will Hartung" <······@home.com> wrote in message
>····························@news1.alsv1.occa.home.com...
>
>> They both seem to do essentially the same thing. LSP seems to convert
HTML
>> into a Lisp construct, whereas htmlgen and its brethren allow one to
>"write
>> HTML" in Lisp. At this stage you'd think that LSP could save some time
and
>> re-use some code if it converted HTML into htmlgen, and then let htmlgen
>do
>> "the dirty work".
>
>I'm not entirely clear on what you mean by this. Are you suggesting a one
>time operation where HTML is converted to htmlgen syntax in a one-off
>operation, and assumed to not change? The problem then is that if the
>powers-that-be decide to change the corporate look, one would have to start
>over from scratch, writing HTML, turning it into htmlgen, then reinserting
>all the lispisms. It might well be that this is the easiest way out of the
>situation... But my instincts favor a process that has fewer steps to it.
I'm sorry, I haven't actually looked at LSP. It just sounded as if it
converted an HTML file into a Lisp function, and I just felt that if that
was the case then you could write your Lisp funtion using the htmlgen
macros, thus leveraging off of the infrastructure that it supplies. But it
appears (from what has been said, again I haven't seen LSP yet) that you
only use strings for most of the page and then supply Lisp code for the
appropriate "dynamic" bits. However, it still seems that it would be a fine
idea to leverage something like htmlgen that lets the code writers use it
instead of writing HTML by hand. Your system may already provide a higher
level foundation to let users create HTML, but if that is the case, then now
there are TWO systems for accomplishing essentially the same thing. No
preference, mind you, but if LSP could be readily change to accomodate
something like htmlgen, then there would only be one Lisp in HTML paradigm
(or rather than one, I should a "more popular" version because if you
integrated it, then there'd be TWO systems using htmlgen! :-).
My only thinking is that if there isn't any really compelling technical
reason to not use a pretty much generic sub system, such as something like
htmlgen, then why reinvent it when it could be reused, and thus making the
one thing more capable for all users.
It would be nice to have a higher level abstraction for creating "hand
coded" HTML in Lisp, and such a system is pretty generic. I think htmlgen
needs to have an *html-stream* or something, but other than that, it's
pretty much standalone.
With such a common system, then others systems, such as LSP, could use this
HTML method when creating their Lisp code from the HTML files. In your LSP
example (and in my previous one), the choice was made to represent some HTML
as pure data (strings), and other HTML as code. If the HTML as code was in a
common system, then whenever folks saw the HTML in Lisp code they'd know
"Oh, yeah, this is system HiL" and know how to work with the macros and any
side effects. Much like you could have the LSP code use LOOP instead of DO.
Anyway, I don't really care, it's just that it would be a shame to have two
very similar yet different systems trying to flower at once for representing
HTML as Lisp code.
>> This is quite handy, as it lets you seperate the code behind the page for
>> the dynamic elements from the page itself, a shortcoming of the
>JSP/ASP/PHP
>> etc models. (And perhaps LSP, I haven't looked at these yet).
>
>LSP was not designed to work this way. The parser output would probably be
>substantially different from the DOM specs, as we try to be clever about
>what structures we parse and save and what we leave as strings. That is not
>to say that LSP could not be *extended* to have a more DOM-like interface,
>but the transformation from parsed structures to code would have to be a
>compile time operation, as would the linking of the external code to the
>parser output. Otherwise there would be a substantial loss in efficiency.
I think that for most dynamic HTML, converting into a DOM is a waste of
time. It's usually not necessary for 90% of the functionality that folks are
trying to get out of server applications. Why cons up a bunch of objects
just to spit them back out again. Some systems certainly need to be able to
tear an HTML document into its component bits, but dynamic presentation and
generation isn't usually one of those applications.
>> This is particularly important because once you agree on your ID names
and
>> conventions (they need to be unique within the page), then the HTML is
>> "unspoiled" by application code. Save for keeping the ID codes around
with
>> the tags, any HTML editor (both silicon and carbon based) can work with
>the
>> main document without having to work around the logic on the page. A
>classic
>> case of the mock-ups used for storyboarding being identical to the
>> production pages.
>>
>> I haven't seen how they do this in XMLC with Java, but with Lisp it is
>very
>> easy to keep the HTML and the code completely seperated,
>
>Another question that arises here is one of engineering practice. Is it a
>good idea to keep code and HTML so separate? While programming, such
>modularization is of course a good thing. While documenting, on the other
>hand, I tend to think that having the documentation near the code is
better.
>So, is writing dynamic methods (in lisp or any other language) to work with
>a given HTML document more like writing two parts of a given program, or is
>it more like annotating the HTML with some executable code?
You could treat it as some kind of literate programming thing, but as I've
painfully found out, modern GUI HTML editors are particularly unkind to
embedded languages. The extra tags either get mashed by the editor, or they
spew little bits of garbage all over the "WYSIWYG" display. I'm currently
fighting one where the editor converts some text with % and & within an HREF
(later to be used within a printf, roughly) into a nice horrible meaningless
filename. This "feature" renders the entire tool not only useless, but
destructive as well.
If you think about modern GUIs, almost all of them have two pieces: the
layout and the code backing up the layout. Now, of course, code could be
used to create the screen layout, but for many tasks there's no real gain in
doing so. It's faster and easier to use a screen painter and then tie your
code into the assorted IDs and tags within the form.
Most of the Lisp GUI tools I've seen "write your code" for you. I suppose
the Java ones do as well.
But look at many screen painters and report writers over a variety of
platforms, and you'll find that seperating the code from the layout is not
particulary uncommon.
Also, web designers, in general, just flat out are not coders. And
vice-a-versa with coders to web designers. Keeping the code seperated lets
each person work in their own domain, with their own tools. A coder can come
up with a quick, simple screen that contains all of the desired
functionality, and then ship it off to the designers to pretty it all up. If
the code is removed from the pages, then the coder can continue to test and
work on the logic side without conflict with the designer. With embedded
code, there's nothing more exicting than shipping off a page to the designer
only having to roll in new functionality and bug fixes when you get it back.
By hand.
Finally, for me, I find that HTML is particularly hard to read and manage.
People complain about Lisps parentheses, but I'll take them any day over the
plethora of indenting styles and tags with HTML (not to mention the <,
, etc.). And the mechanical editors don't clean it up much. (Then, of
course, you get to run it through the HTML Packer to save bandwidth!!! :-)
>Thanks for the feedback. I'll have to think about this a little bit more.
It
>might be better to make such changes to LSP once we begin moving to xhtml,
>as xml is better specified than HTML. But first I'd like to have LSP
working
>in the model we have defined right now...
My current project works with JSPs. It's a fine idea, all of the embedded
languages are a fine idea. But in my project, everything comes to a
screeching halt when the pages head on over to the web guys. They are more
artists than coders, so they struggle with the basic logic. They struggle
because their tools won't work well in the environment. The back end guys
try to shroud as much of the logic as is necessary so that it can be kept
out of the web page, and kept in classes. But still, there's some
complicated navigation code stuff into the JSPs, and its all a jumbled mess.
Of course another problem is since the coders aren't the ones fighting the
HTML and page problems, they're not thinking about the problem. Like, "Gee,
maybe if we had an entity to encapsulate the navigation login, and then the
web page just needs a couple of 'Go' buttons, feeding a state machine". HTML
designers don't think in those terms of abstraction, mostly because it's not
in their background. A coder would write that code twice and say "There has
GOT to be a better way".
No, the Web Designers, with their hammers, just beat their way through the
task at hand and get the job done as best they can.
WebObjects does a similar thing to the idea I presented, keep the code out
of the page. But, they use custom tags, and you need their custom interface
builder. Not that it's a particularly bad thing, it's a pretty cool tool,
but it can't keep up with the bleeding edge of web development.
The best part about my suggestion is that it's about as close to WYSIWYG as
you're going to get. Run the HTML through the processor, create the
function, run the function, and you'll pretty much get what you started
with, and all you started with is simple HTML, with the most basic of
extensions, if it's an extension at all (I'm not familiar with what tags ID
can and cannot be used with). No delimiters, no paradigm shift, nothing.
HTML in, HTML out on the one side, and Lisp in and out on the other.
Commodity tools for the coders (emacs, ACL, Linux) and the designers (PCs,
Macs, GoLive, DreamWeaver, etc). About the only other extension I can think
of is some META tags to talk to the processor. (Like maybe some slot names,
a class name, a superclass, etc.)
It could use a content management system, if anyone has any ideas on that
:-).
Anyway, my 2 cents.
Will Hartung
(······@home.com)
in article ··········@news2.newsguy.com, Will Hartung at
············@havasint.com wrote on 5/31/00 4:45 PM:
>
> Sunil Mishra wrote in message ...
>
> I'm sorry, I haven't actually looked at LSP. It just sounded as if it
> converted an HTML file into a Lisp function, and I just felt that if that
> was the case then you could write your Lisp funtion using the htmlgen
> macros, thus leveraging off of the infrastructure that it supplies. But it
> appears (from what has been said, again I haven't seen LSP yet) that you
> only use strings for most of the page and then supply Lisp code for the
> appropriate "dynamic" bits. However, it still seems that it would be a fine
> idea to leverage something like htmlgen that lets the code writers use it
> instead of writing HTML by hand. Your system may already provide a higher
> level foundation to let users create HTML, but if that is the case, then now
> there are TWO systems for accomplishing essentially the same thing. No
> preference, mind you, but if LSP could be readily change to accomodate
> something like htmlgen, then there would only be one Lisp in HTML paradigm
> (or rather than one, I should a "more popular" version because if you
> integrated it, then there'd be TWO systems using htmlgen! :-).
>
> My only thinking is that if there isn't any really compelling technical
> reason to not use a pretty much generic sub system, such as something like
> htmlgen, then why reinvent it when it could be reused, and thus making the
> one thing more capable for all users.
I think I now see where the source of confusion lies. htmlgen and LSP do
conceptually different things. While htmlgen is intended to turn an
arbitrary snippet of HTML-like sexp into an HTML output, LSP attempts to
turn a well written, verifiable page into one instance of an HTML page. The
intermediate representation (that gives both of them their dynamic property)
is a lisp function. You can arguably replace LSP with htmlgen, but the
result will be general dissatisfaction if you ask your designers and what
have you to work with the sexp representation. (Unless of course you have
the resources to invest in a great sexp oriented design tool.) In the LSP
scheme of things, htmlgen would be great for programmers to embed little
snippets of generated HTML output in their code. (We had considered using
LSP for this purpose at one point, but after a major redesign decided it was
not necessary.) LSP on the other hand is geared toward writing entire HTML
pages. If you really wanted to, you could potentially write entire pages,
turn portions of those pages (say headers and footers) into functions, and
call them from your htmlgen functions. I wouldn't do it, but then you never
know what situation a (lsp and htmlgen) user might find herself in.
The way I see it, both LSP and htmlgen have their places. I would not try to
replace either one with the other, but keep both available for their unique
strengths.
> It would be nice to have a higher level abstraction for creating "hand
> coded" HTML in Lisp, and such a system is pretty generic. I think htmlgen
> needs to have an *html-stream* or something, but other than that, it's
> pretty much standalone.
>
> With such a common system, then others systems, such as LSP, could use this
> HTML method when creating their Lisp code from the HTML files. In your LSP
> example (and in my previous one), the choice was made to represent some HTML
> as pure data (strings), and other HTML as code. If the HTML as code was in a
> common system, then whenever folks saw the HTML in Lisp code they'd know
> "Oh, yeah, this is system HiL" and know how to work with the macros and any
> side effects. Much like you could have the LSP code use LOOP instead of DO.
I would suggest that you see how LSP turns HTML into code. I'll give a brief
description. Consider any HTML tag as a container. (Some like <br> are
empty.) If you want to turn a tag into code, you give that tag a name, and
the contents of that tag can be output through a function call. If that
snippet of HTML happens to contain lisp code, it is executed.
If the same lisp snippet happens to appear outside of the scope of a
function declaration, the string before the snippet is output, then the lisp
form is evaluated, and finally the string after the snippet is output. There
is no macro to expand. Consequently, the idea of expanding HTML into a
function is rather slippery. I hope that I have in fact answered your
question here...
> Anyway, I don't really care, it's just that it would be a shame to have two
> very similar yet different systems trying to flower at once for representing
> HTML as Lisp code.
Not if they give the author substantially different abilities :-)
>> Another question that arises here is one of engineering practice. Is it a
>> good idea to keep code and HTML so separate? While programming, such
>> modularization is of course a good thing. While documenting, on the other
>> hand, I tend to think that having the documentation near the code is
> better.
>> So, is writing dynamic methods (in lisp or any other language) to work with
>> a given HTML document more like writing two parts of a given program, or is
>> it more like annotating the HTML with some executable code?
>
>
> You could treat it as some kind of literate programming thing, but as I've
> painfully found out, modern GUI HTML editors are particularly unkind to
> embedded languages. The extra tags either get mashed by the editor, or they
> spew little bits of garbage all over the "WYSIWYG" display. I'm currently
> fighting one where the editor converts some text with % and & within an HREF
> (later to be used within a printf, roughly) into a nice horrible meaningless
> filename. This "feature" renders the entire tool not only useless, but
> destructive as well.
Hmmm... We have had *some* experience with frontpage 2000, and it doesn't
seem to mangle the HTML that badly. This is one of the issues we will have
to resolve in the evolution of LSP.
> If you think about modern GUIs, almost all of them have two pieces: the
> layout and the code backing up the layout. Now, of course, code could be
> used to create the screen layout, but for many tasks there's no real gain in
> doing so. It's faster and easier to use a screen painter and then tie your
> code into the assorted IDs and tags within the form.
>
> Most of the Lisp GUI tools I've seen "write your code" for you. I suppose
> the Java ones do as well.
>
> But look at many screen painters and report writers over a variety of
> platforms, and you'll find that seperating the code from the layout is not
> particulary uncommon.
>
> Also, web designers, in general, just flat out are not coders. And
> vice-a-versa with coders to web designers. Keeping the code seperated lets
> each person work in their own domain, with their own tools. A coder can come
> up with a quick, simple screen that contains all of the desired
> functionality, and then ship it off to the designers to pretty it all up. If
> the code is removed from the pages, then the coder can continue to test and
> work on the logic side without conflict with the designer. With embedded
> code, there's nothing more exicting than shipping off a page to the designer
> only having to roll in new functionality and bug fixes when you get it back.
> By hand.
On the other hand, the co-location of the source and the HTML, if chosen
carefully, makes it a lot easier to keep the two in sync. Especially if the
two can coexist in a well defined structure. That is the reason for LSP's
existence. If this thesis turns out to be completely misguided, it takes
away the reason for the existence of every HTML scripting language out
there. Too many people have worked with such scripting languages for me to
believe that this is a complete waste of time.
> My current project works with JSPs. It's a fine idea, all of the embedded
> languages are a fine idea. But in my project, everything comes to a
> screeching halt when the pages head on over to the web guys. They are more
> artists than coders, so they struggle with the basic logic. They struggle
> because their tools won't work well in the environment. The back end guys
> try to shroud as much of the logic as is necessary so that it can be kept
> out of the web page, and kept in classes. But still, there's some
> complicated navigation code stuff into the JSPs, and its all a jumbled mess.
>
> Of course another problem is since the coders aren't the ones fighting the
> HTML and page problems, they're not thinking about the problem. Like, "Gee,
> maybe if we had an entity to encapsulate the navigation login, and then the
> web page just needs a couple of 'Go' buttons, feeding a state machine". HTML
> designers don't think in those terms of abstraction, mostly because it's not
> in their background. A coder would write that code twice and say "There has
> GOT to be a better way".
And this is the essence of the problem. Coders and designers live in
different worlds, use different tools, and think differently. The best we
can do, IMHO, is to come up with the best possible mechanism for
communicating between the two. Which may come down to combining the tools
available as seemlessly as possible.
Sunil
Sunil Mishra wrote in message ...
>The way I see it, both LSP and htmlgen have their places. I would not try
to
>replace either one with the other, but keep both available for their unique
>strengths.
I actually got a chance to glance at the LSP pages, and I understand better
what you're trying to do. Done properly, you never see the actual generated
code from the HTML pages. I know I broke a major USENET covenant by actually
educating myself on the topic and transforming my view rather than
continuing to argue in ignorance, only with more CAPITAL letters, and
personal slurs.
>> You could treat it as some kind of literate programming thing, but as
I've
>> painfully found out, modern GUI HTML editors are particularly unkind to
>> embedded languages. The extra tags either get mashed by the editor, or
they
>> spew little bits of garbage all over the "WYSIWYG" display. I'm currently
>> fighting one where the editor converts some text with % and & within an
HREF
>> (later to be used within a printf, roughly) into a nice horrible
meaningless
>> filename. This "feature" renders the entire tool not only useless, but
>> destructive as well.
>
>Hmmm... We have had *some* experience with frontpage 2000, and it doesn't
>seem to mangle the HTML that badly. This is one of the issues we will have
>to resolve in the evolution of LSP.
>
*snip*
>> Also, web designers, in general, just flat out are not coders. And
>> vice-a-versa with coders to web designers. Keeping the code seperated
lets
>> each person work in their own domain, with their own tools. A coder can
come
>> up with a quick, simple screen that contains all of the desired
>> functionality, and then ship it off to the designers to pretty it all up.
If
>> the code is removed from the pages, then the coder can continue to test
and
>> work on the logic side without conflict with the designer. With embedded
>> code, there's nothing more exicting than shipping off a page to the
designer
>> only having to roll in new functionality and bug fixes when you get it
back.
>> By hand.
>
>On the other hand, the co-location of the source and the HTML, if chosen
>carefully, makes it a lot easier to keep the two in sync. Especially if the
>two can coexist in a well defined structure. That is the reason for LSP's
>existence. If this thesis turns out to be completely misguided, it takes
>away the reason for the existence of every HTML scripting language out
>there. Too many people have worked with such scripting languages for me to
>believe that this is a complete waste of time.
The embedding scripting languages are popular, and I think you'll agree that
they're not that difficult to do. They are a small step down the
evolutionary path from server side includes (it can be argued that they're
the same thing, just more general).
I also think that they're fine if your designer and coder are the same
person.
But I also think that they can be a faustian bargain...They sure look good
in the beginning, but long term they can turn on you.
On the other hand, though, I feel it constrains the designers, and I think
that it constrains the developers as well. Perhaps my complaints could be
resolved with a better tool suite that hides whatever the user wants hidden.
In the designers case, they can lay out a table that has, oh say, stock
quotes. Now a stock quote is, what, 10 to 12 characters long. But, the
snippet of code to fetch that quote a) is probably longer than the stock
quote, and b) doesn't look anything like a stock quote. So, the designer
can't use his tool to visualize and format his table properly, because the
data in the table cell is too big. Either he has to select the code, cut it
out, replace it with IBM +123.4, tweak until perfect, then paste the code
back in, or he has to save the page, launch the browser, run the code, hit
the back end, etc, see what it's REALLY going to look like. Of course, they
have to do this anyway with the different browsers, but in this case it's
not just a simple matter of viewing the page, they also have to drag it
through the entire development cycle before they can see their results.
Seems to defeat the entire purpose of a WYSIWYG HTML editor.
Meanwhile, on the developers side, they can't use a Lisp emacs mode on their
code, nor can they really use an HTML mode on their code. In fact their code
isn't either Lisp or HTML, it's a hybrid. Worse, the coder and designer can
not make progress on the same page at the same time, they need to move it
back and forth, yet in reality one can have very little to do with the
other. One is purely cosmetic to the others logic.
Perhaps it bothers me more because I've had a background working with code
snippets seperated from the front end, and it works out pretty well. The
folks who work with me know that I do a crappy job of laying out screens,
reports, and what not. Beyond the simplest of designs, I always task it out
to someone much more capable at it than me.
>> Of course another problem is since the coders aren't the ones fighting
the
>> HTML and page problems, they're not thinking about the problem. Like,
"Gee,
>> maybe if we had an entity to encapsulate the navigation login, and then
the
>> web page just needs a couple of 'Go' buttons, feeding a state machine".
HTML
>> designers don't think in those terms of abstraction, mostly because it's
not
>> in their background. A coder would write that code twice and say "There
has
>> GOT to be a better way".
>
>And this is the essence of the problem. Coders and designers live in
>different worlds, use different tools, and think differently. The best we
>can do, IMHO, is to come up with the best possible mechanism for
>communicating between the two. Which may come down to combining the tools
>available as seemlessly as possible.
To me, merging the scripting into the HTML slams these two worlds together,
and makes each side come to a screeching halt once they've been combined.
Once they're fused, both sides start walking on eggs so they don't break
"the other guys" work. Certainly there has to be some crossover. The coders
will HAVE to emit program generated HTML, but by using a high level
facility, in their language of choice, means they don't necessarily have to
work in an environment that's foreign to them.
Again, perhaps if the tools were better, then this wouldn't be as much of an
issue. WebObjects does an OK job as an HTML editor, but it's no DreamWeaver.
Separating the HTML from the code, with little to bind them but a list of
names, and an expected visual result from the storyboard, and by using a
blend of stylesheets and such, the designers can have free reign over how
their site looks and feels, while the coders can have flexibility to use all
the capabilities of their environment to further the application. The
designer works in pure HTML, while the coder works in pure Lisp. The coder
will probably have a rough, ugly HTML file that acts as a test bed for his
work, and the coder and designer will need to get together to make sure that
what HTML the coder needs to spit out will be compatible, but beyond that
(and most of that discussion will happen as the first few pages roll out
rather than every time), they are essentially free to go on their merry way,
at their own pace with their own tools.
I'll know more in a few months, as I intend to do this kind of thing as my
project moves forward. I'm just particularly underwhelmed by embedded
scripting for larger projects with larger groups. For the soloist, internet
renaissance man, they're super duper, but turning artists into coders and
vice-a-versa seems like a particular waste of the projects time so far.
Will Hartung
(······@home.com)
in article ·······················@news1.alsv1.occa.home.com, Will Hartung
at ······@home.com wrote on 6/1/00 7:43 AM:
>
> I actually got a chance to glance at the LSP pages, and I understand better
> what you're trying to do. Done properly, you never see the actual generated
> code from the HTML pages. I know I broke a major USENET covenant by actually
> educating myself on the topic and transforming my view rather than
> continuing to argue in ignorance, only with more CAPITAL letters, and
> personal slurs.
:-)
> *snip*
*ditto*
>
> The embedding scripting languages are popular, and I think you'll agree that
> they're not that difficult to do. They are a small step down the
> evolutionary path from server side includes (it can be argued that they're
> the same thing, just more general).
>
> I also think that they're fine if your designer and coder are the same
> person.
>
> But I also think that they can be a faustian bargain...They sure look good
> in the beginning, but long term they can turn on you.
>
> On the other hand, though, I feel it constrains the designers, and I think
> that it constrains the developers as well. Perhaps my complaints could be
> resolved with a better tool suite that hides whatever the user wants hidden.
The biggest problem I had when taking over LSP development was understanding
the requirements that the system was attempting to fulfill. Merely writing a
scripting language, or even turning an HTML page into a lisp program, is
indeed relatively straightforward. The challenge was in preserving the
semantics of HTML and lisp to the extent that each party could essentially
ignore the existence of the other. In other words, a somewhat sophisticated
authoring system should be able to ignore the lisp, and the lisp programmer
should largely be isolated from the details of processing the HTML/HTTP. I
think we have done a relatively good job on this.
>
> In the designers case, they can lay out a table that has, oh say, stock
> quotes. Now a stock quote is, what, 10 to 12 characters long. But, the
> snippet of code to fetch that quote a) is probably longer than the stock
> quote, and b) doesn't look anything like a stock quote. So, the designer
> can't use his tool to visualize and format his table properly, because the
> data in the table cell is too big. Either he has to select the code, cut it
> out, replace it with IBM +123.4, tweak until perfect, then paste the code
> back in, or he has to save the page, launch the browser, run the code, hit
> the back end, etc, see what it's REALLY going to look like. Of course, they
> have to do this anyway with the different browsers, but in this case it's
> not just a simple matter of viewing the page, they also have to drag it
> through the entire development cycle before they can see their results.
This is someting that is certainly difficult to resolve. Wish I could give
a better answer than that. LSP does make this process easier, as the lisp
programmer has lexical scoping to work with as well. In this case, it is
possible to turn the row in question into a function that merely does
variable substitution. The values of the variables can be calculated outside
the row function, and supplied to it as arguments. This makes it easy to
develop LSP pages that are more meaningful to both the programmer and the
designer.
In some situations what you have described may indeed be unavoidable. We may
have to develop additional paradigms when using LSP to handle them properly,
but I do believe it can be done. It's lisp, after all :-)
>
> Seems to defeat the entire purpose of a WYSIWYG HTML editor.
>
> Meanwhile, on the developers side, they can't use a Lisp emacs mode on their
> code, nor can they really use an HTML mode on their code. In fact their code
> isn't either Lisp or HTML, it's a hybrid. Worse, the coder and designer can
> not make progress on the same page at the same time, they need to move it
> back and forth, yet in reality one can have very little to do with the
> other. One is purely cosmetic to the others logic.
That is not true. I have used lisp mode when inserting expressions into LSP
pages. The only thing I had to do manually was set up the indentation of the
opening form, and everything else followed.
[*snip*]
>>
>> And this is the essence of the problem. Coders and designers live in
>> different worlds, use different tools, and think differently. The best we
>> can do, IMHO, is to come up with the best possible mechanism for
>> communicating between the two. Which may come down to combining the tools
>> available as seemlessly as possible.
>
>
> To me, merging the scripting into the HTML slams these two worlds together,
> and makes each side come to a screeching halt once they've been combined.
> Once they're fused, both sides start walking on eggs so they don't break
> "the other guys" work. Certainly there has to be some crossover. The coders
> will HAVE to emit program generated HTML, but by using a high level
> facility, in their language of choice, means they don't necessarily have to
> work in an environment that's foreign to them.
>
> Again, perhaps if the tools were better, then this wouldn't be as much of an
> issue. WebObjects does an OK job as an HTML editor, but it's no DreamWeaver.
>
> Separating the HTML from the code, with little to bind them but a list of
> names, and an expected visual result from the storyboard, and by using a
> blend of stylesheets and such, the designers can have free reign over how
> their site looks and feels, while the coders can have flexibility to use all
> the capabilities of their environment to further the application. The
> designer works in pure HTML, while the coder works in pure Lisp. The coder
> will probably have a rough, ugly HTML file that acts as a test bed for his
> work, and the coder and designer will need to get together to make sure that
> what HTML the coder needs to spit out will be compatible, but beyond that
> (and most of that discussion will happen as the first few pages roll out
> rather than every time), they are essentially free to go on their merry way,
> at their own pace with their own tools.
LSP, I believe, can come close to this ideal. But then that is something for
the users to decide. Any time you have two people collaborating on a single
file, inconsistencies are going to arise. It is doubly challenging when the
two are attempting to accomplish orthogonal tasks, as is the case with HTML
and a scripting language. The designer, IMHO, must necessarily work on
entire pages, or at least large rectangular chunks of them. It therefore
becomes the responsibility of the programmer to ensure that they are in the
way of the designer as little as possible. We are generally much better
accustomed to modular thinking, and should certainly bring our skills to
bear upon this problem. The best we can do is *encourage* the designers to
make this job easier for us.
There is no easy way out here, as far as I can see.
Sunil
Sunil,
Regarding this issue, have you developed an emacs mode that is aware
of the lisp/html tags in the LSP pages?
-Jonathan
On Thu, 01 Jun 2000 12:51:26 -0700, Sunil Mishra
<·······@firstworld.net> wrote:
>>
>> Seems to defeat the entire purpose of a WYSIWYG HTML editor.
>>
>> Meanwhile, on the developers side, they can't use a Lisp emacs mode on their
>> code, nor can they really use an HTML mode on their code. In fact their code
>> isn't either Lisp or HTML, it's a hybrid. Worse, the coder and designer can
>> not make progress on the same page at the same time, they need to move it
>> back and forth, yet in reality one can have very little to do with the
>> other. One is purely cosmetic to the others logic.
>
>That is not true. I have used lisp mode when inserting expressions into LSP
>pages. The only thing I had to do manually was set up the indentation of the
>opening form, and everything else followed.
>
Jonathan Siegel <···@scorekeep.com> writes:
> Sunil,
>
> Regarding this issue, have you developed an emacs mode that is aware
> of the lisp/html tags in the LSP pages?
There is a two-modes.el (or something with a very similiar name) that
will allow you to have two major modes in a buffer at the same time.
It's seems reasonable that if this works, you could use psgml and lisp
mode in the same buffer.
--
Craig Brozefsky <·····@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
Craig Brozefsky <·····@red-bean.com> writes:
> Jonathan Siegel <···@scorekeep.com> writes:
>
> > Regarding this issue, have you developed an emacs mode that is
> > aware of the lisp/html tags in the LSP pages?
>
> There is a two-modes.el (or something with a very similiar name)
> that will allow you to have two major modes in a buffer at the same
> time. It's seems reasonable that if this works, you could use psgml
> and lisp mode in the same buffer.
I do this every day, with JSP (Java & HTML) pages. The key is
multi-mode.el, then this little bit in my .emacs:
;;jsp/html multi-mode
(autoload 'multi-mode
"multi-mode"
"Allowing multiple major modes in a buffer."
t)
(defun jsp-mode () (interactive)
(multi-mode 1
'html-mode
'("<%" java-mode)
'("%>" html-mode)))
(setq auto-mode-alist
(cons '("\\.jsp$" . jsp-mode)
auto-mode-alist))
When I open a JSP file, the default is html-mode. When the point is
inside a code fragment (delimited by <% and %>) emacs switches to
java-mode.
John Wiseman
Craig Brozefsky <·····@red-bean.com> writes:
> Jonathan Siegel <···@scorekeep.com> writes:
>
> > Sunil,
> >
> > Regarding this issue, have you developed an emacs mode that is aware
> > of the lisp/html tags in the LSP pages?
>
> There is a two-modes.el (or something with a very similiar name) that
> will allow you to have two major modes in a buffer at the same time.
> It's seems reasonable that if this works, you could use psgml and lisp
> mode in the same buffer.
And if that doesn't work, there's an elisp file originally written to
support switching a minor mode on and off, but it's usable for
switching majors too.
http://www.algonet.se/~gruk/src/elisp/minors.el
//Ingvar (the docs with it probably suck badly...)
--
Ingvar Mattsson; ····@algonet.se;
(defun f (a) (format () "Will ~a for food." a)) (print (f "propose"))
Alas, no... I have no clue how I would go about mixing lisp mode with lsp
(html) mode. It has turned out to be sufficient to start with an HTML page,
and insert lisp code (in lisp mode) as needed. It is not too difficult to
switch modes back and forth. But in the long run I'm sure a better solution
will be needed.
My first priority is to wrap up the missing form input fields, then to
expand upon the publisher functionality.
Sunil
in article ····························@4ax.com, Jonathan Siegel at
···@scorekeep.com wrote on 6/2/00 11:24 PM:
> Sunil,
>
> Regarding this issue, have you developed an emacs mode that is aware
> of the lisp/html tags in the LSP pages?
>
> -Jonathan
>
> On Thu, 01 Jun 2000 12:51:26 -0700, Sunil Mishra
> <·······@firstworld.net> wrote:
>>>
>>> Seems to defeat the entire purpose of a WYSIWYG HTML editor.
>>>
>>> Meanwhile, on the developers side, they can't use a Lisp emacs mode on their
>>> code, nor can they really use an HTML mode on their code. In fact their code
>>> isn't either Lisp or HTML, it's a hybrid. Worse, the coder and designer can
>>> not make progress on the same page at the same time, they need to move it
>>> back and forth, yet in reality one can have very little to do with the
>>> other. One is purely cosmetic to the others logic.
>>
>> That is not true. I have used lisp mode when inserting expressions into LSP
>> pages. The only thing I had to do manually was set up the indentation of the
>> opening form, and everything else followed.
>>
>
Sunil Mishra <·······@firstworld.net> writes:
> Alas, no... I have no clue how I would go about mixing lisp mode with lsp
> (html) mode. It has turned out to be sufficient to start with an HTML page,
> and insert lisp code (in lisp mode) as needed. It is not too difficult to
> switch modes back and forth. But in the long run I'm sure a better solution
> will be needed.
An indirect buffer might do (part of) the trick.
The problem is, that if your HTML guys can't understand some simple
dynamic concepts well enough to avoid screwing them up, they won't
understand the significance or structure of the IDs either, and will
screw that up as well. In fact, the ID version might be worse in this
regard, because at least the script-embedded version is readable on its
own while the ID version would I imagine be pretty much opaque. Not to
mention the difficulties of keeping the two in synch.
I made invalid assumptions about how you envisioned this being used.
I assumed that the developers were defining the IDs and the associated
functionality before the designers began work. The developers would
either provide the IDs and definitions to the designers, or perhaps they
would (as I usually do) provide a set of plain but functional pages for
the designers to base their work on. Now you see where my concerns came
from?
Allowing the designers to start the thing, and insert their own IDs that
mean "insert this data here" or "repeate this row for each row in the
set" as they design, then shipping that back to the developers avoids
the problems that I immediately saw. It's an interesting approach and I
hope you'll follow up here with a description of your results in a few
months.
Anyway, as everybody keeps saying, what's needed are better tools for
the designers, regardless of approach. My experience with visual editors
was so dismal that within a day or two of starting to use HTML I
switched to BBEdit ;-)
Sunil,
It seems to me that one can integrate both web designer based HTML
forms alongside dynamic HTMLGEN produced data. Is this possible under
the LSP publication scheme (under AllegroServe)? Can you please post
an example that would accomplish this?
I guess the main question is really whether LSP redefines the
*HTML-STREAM* so that one can no longer use the HTMLGEN facilities.
Thanks in advance,
Jonathan
···@scorekeep.com
On Mon, 29 May 2000 20:07:35 -0700, "Sunil Mishra"
<·······@arslogica.com> wrote:
>Lisp Server Pages (LSP)
>Release 0.5d
>
>
>
>Home page: http://lsp.sourceforge.net
>Project page: https://sourceforge.net/project/?group_id=6252
>Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
>Contact email: ···@everest.com
>
>
>
>We are pleased to announce Lisp Server Pages, or LSP, as an open source
>project. LSP is a Common Lisp based technology for dynamic HTML
>generation that transforms LSP documents embedded with Common Lisp into
>executable HTML generation functions. Unlike many other dynamic content
>packages, LSP succeeds in simultaneously providing the author with SGML
>and lisp semantics while composing an LSP document.
>
>LSP has two primary components-- an LSP page compilation facility, and a
>server independent publishing facility. The page compilation facility is
>nearly complete. It currently lacks support for tags TEXTAREA and
>SELECT. The server independent site publishing facility is currently
>less evolved. AllegroServe is well supported, and CL-HTTP is not so well
>supported. We would like to also see support for Apache and so on, but
>we neither have the time nor the knowledge for such an endeavor. Hence,
>this LSP release is to be regarded as a developer release. We would
>welcome developers that have an interest in using and extending LSP.
>
>Documentation for LSP is included in the directory lsp-doc. This
>directory also serves as a minimal demonstration of LSP's abilities. In
>lsp-doc/lsp-intro.html, we describe how this directory can be easily
>published to an available web server. Loading start.lisp (after loading
>in AllegroServe or CL-HTTP) automatically does this for you.
>
>Please send any bug reports, feature requests, comments, success stories
>and so on to ···@everest.com. LSP is available at Sourceforge at
>lsp.sourceforge.net.
>
>Many thanks to our employer, Everest eCommerce Inc., in providing the
>resources that have made it possible for us to develop this package, and
>the encouragement to make it an open source project. More information
>about Everest can be found at www.everest.com.
>
>-- Sunil Mishra
>
>
I have never attempted this myself, but I don't see any reason why this
would not be possible. An LSP function (which results from compiling an LSP
page) requires two input arguments, the request object and the response
stream. If the macroexpansion of an htmlgen function can take an arbitrary
stream as input, then the response stream can be easily given as input to
the htmlgen expansion.
I thought I had made explict what happens at expansion time. If this is
unclear, please let me know, and I shall elaborate on this in the
documentaiton.
Here's a simple example of how one can access the request object and the
reply stream. The bindings request and reply-stream are implicitly set when
the lisp code is generated.
<html>
<head><title>Request and response</title></html>
<body>
<p>We explicitly output the request object to the response stream using the
<lisp> tag rather than the <eval> tag. The difference between
the two tags, to reiterate, is that <eval> sends the result value of
the lisp expression to the response stream.</p>
<p>
<lisp>(print request reply-stream)</lisp>
</p>
</body>
</html>
in article ····························@4ax.com, Jonathan Siegel at
···@scorekeep.com wrote on 6/3/00 3:20 PM:
> Sunil,
>
> It seems to me that one can integrate both web designer based HTML
> forms alongside dynamic HTMLGEN produced data. Is this possible under
> the LSP publication scheme (under AllegroServe)? Can you please post
> an example that would accomplish this?
>
> I guess the main question is really whether LSP redefines the
> *HTML-STREAM* so that one can no longer use the HTMLGEN facilities.
>
> Thanks in advance,
> Jonathan
> ···@scorekeep.com
>
> On Mon, 29 May 2000 20:07:35 -0700, "Sunil Mishra"
> <·······@arslogica.com> wrote:
>
>> Lisp Server Pages (LSP)
>> Release 0.5d
>>
>>
>>
>> Home page: http://lsp.sourceforge.net
>> Project page: https://sourceforge.net/project/?group_id=6252
>> Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
>> Contact email: ···@everest.com
>>
>>
>>
>> We are pleased to announce Lisp Server Pages, or LSP, as an open source
>> project. LSP is a Common Lisp based technology for dynamic HTML
>> generation that transforms LSP documents embedded with Common Lisp into
>> executable HTML generation functions. Unlike many other dynamic content
>> packages, LSP succeeds in simultaneously providing the author with SGML
>> and lisp semantics while composing an LSP document.
>>
>> LSP has two primary components-- an LSP page compilation facility, and a
>> server independent publishing facility. The page compilation facility is
>> nearly complete. It currently lacks support for tags TEXTAREA and
>> SELECT. The server independent site publishing facility is currently
>> less evolved. AllegroServe is well supported, and CL-HTTP is not so well
>> supported. We would like to also see support for Apache and so on, but
>> we neither have the time nor the knowledge for such an endeavor. Hence,
>> this LSP release is to be regarded as a developer release. We would
>> welcome developers that have an interest in using and extending LSP.
>>
>> Documentation for LSP is included in the directory lsp-doc. This
>> directory also serves as a minimal demonstration of LSP's abilities. In
>> lsp-doc/lsp-intro.html, we describe how this directory can be easily
>> published to an available web server. Loading start.lisp (after loading
>> in AllegroServe or CL-HTTP) automatically does this for you.
>>
>> Please send any bug reports, feature requests, comments, success stories
>> and so on to ···@everest.com. LSP is available at Sourceforge at
>> lsp.sourceforge.net.
>>
>> Many thanks to our employer, Everest eCommerce Inc., in providing the
>> resources that have made it possible for us to develop this package, and
>> the encouragement to make it an open source project. More information
>> about Everest can be found at www.everest.com.
>>
>> -- Sunil Mishra
>>
>>
>
Sunil,
How would one use the LSP tools to publish a function that returns a
non-text/html content type? I did not see this explained in the LSP
documentation.
-Jonathan
···@scorekeep.com
On Mon, 29 May 2000 20:07:35 -0700, "Sunil Mishra"
<·······@arslogica.com> wrote:
>Lisp Server Pages (LSP)
>Release 0.5d
>
>
>
>Home page: http://lsp.sourceforge.net
>Project page: https://sourceforge.net/project/?group_id=6252
>Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
>Contact email: ···@everest.com
>
>
>
>We are pleased to announce Lisp Server Pages, or LSP, as an open source
>project. LSP is a Common Lisp based technology for dynamic HTML
>generation that transforms LSP documents embedded with Common Lisp into
>executable HTML generation functions. Unlike many other dynamic content
>packages, LSP succeeds in simultaneously providing the author with SGML
>and lisp semantics while composing an LSP document.
>
>LSP has two primary components-- an LSP page compilation facility, and a
>server independent publishing facility. The page compilation facility is
>nearly complete. It currently lacks support for tags TEXTAREA and
>SELECT. The server independent site publishing facility is currently
>less evolved. AllegroServe is well supported, and CL-HTTP is not so well
>supported. We would like to also see support for Apache and so on, but
>we neither have the time nor the knowledge for such an endeavor. Hence,
>this LSP release is to be regarded as a developer release. We would
>welcome developers that have an interest in using and extending LSP.
>
>Documentation for LSP is included in the directory lsp-doc. This
>directory also serves as a minimal demonstration of LSP's abilities. In
>lsp-doc/lsp-intro.html, we describe how this directory can be easily
>published to an available web server. Loading start.lisp (after loading
>in AllegroServe or CL-HTTP) automatically does this for you.
>
>Please send any bug reports, feature requests, comments, success stories
>and so on to ···@everest.com. LSP is available at Sourceforge at
>lsp.sourceforge.net.
>
>Many thanks to our employer, Everest eCommerce Inc., in providing the
>resources that have made it possible for us to develop this package, and
>the encouragement to make it an open source project. More information
>about Everest can be found at www.everest.com.
>
>-- Sunil Mishra
>
>
There are no facilities for this. LSP was intended to publish dynamic HTML,
so I had not considered non-html content. Currently, one would have to use
the server specific mechanisms for publishing dynamic content. In the case
of aserve that would be publish, while in cl-http it would be export-url. I
shall make the publish function part of the server abstraction layer in LSP
on the next release.
Sunil
in article ····························@4ax.com, Jonathan Siegel at
···@scorekeep.com wrote on 6/5/00 1:04 AM:
> Sunil,
>
> How would one use the LSP tools to publish a function that returns a
> non-text/html content type? I did not see this explained in the LSP
> documentation.
>
> -Jonathan
> ···@scorekeep.com
>
> On Mon, 29 May 2000 20:07:35 -0700, "Sunil Mishra"
> <·······@arslogica.com> wrote:
>
>> Lisp Server Pages (LSP)
>> Release 0.5d
>>
>>
>>
>> Home page: http://lsp.sourceforge.net
>> Project page: https://sourceforge.net/project/?group_id=6252
>> Latest version: http://download.sourceforge.net/lsp/lsp-0.5-dev.tgz
>> Contact email: ···@everest.com
>>
>>
>>
>> We are pleased to announce Lisp Server Pages, or LSP, as an open source
>> project. LSP is a Common Lisp based technology for dynamic HTML
>> generation that transforms LSP documents embedded with Common Lisp into
>> executable HTML generation functions. Unlike many other dynamic content
>> packages, LSP succeeds in simultaneously providing the author with SGML
>> and lisp semantics while composing an LSP document.
>>
>> LSP has two primary components-- an LSP page compilation facility, and a
>> server independent publishing facility. The page compilation facility is
>> nearly complete. It currently lacks support for tags TEXTAREA and
>> SELECT. The server independent site publishing facility is currently
>> less evolved. AllegroServe is well supported, and CL-HTTP is not so well
>> supported. We would like to also see support for Apache and so on, but
>> we neither have the time nor the knowledge for such an endeavor. Hence,
>> this LSP release is to be regarded as a developer release. We would
>> welcome developers that have an interest in using and extending LSP.
>>
>> Documentation for LSP is included in the directory lsp-doc. This
>> directory also serves as a minimal demonstration of LSP's abilities. In
>> lsp-doc/lsp-intro.html, we describe how this directory can be easily
>> published to an available web server. Loading start.lisp (after loading
>> in AllegroServe or CL-HTTP) automatically does this for you.
>>
>> Please send any bug reports, feature requests, comments, success stories
>> and so on to ···@everest.com. LSP is available at Sourceforge at
>> lsp.sourceforge.net.
>>
>> Many thanks to our employer, Everest eCommerce Inc., in providing the
>> resources that have made it possible for us to develop this package, and
>> the encouragement to make it an open source project. More information
>> about Everest can be found at www.everest.com.
>>
>> -- Sunil Mishra
>>
>>
>
"Sunil Mishra" <·······@arslogica.com> writes:
> We are pleased to announce Lisp Server Pages, or LSP, as an open
> source project. LSP is a Common Lisp based technology for dynamic
> HTML generation that transforms LSP documents embedded with Common
> Lisp into executable HTML generation functions.
I realize that the purposes of the two systems are somewhat different,
but it might be worth looking into fitting LSP into the JSP model.
Despite the name (Java Server Pages), JSP is meant to be
language-independent. As far as I know, the following is completely
legal JSP:
<·@ page language="lisp" %>
<h1>The first 10 natural numbers</h1>
<%
(dolist (i 10)
(format out "~&~A~D" (p-tag) (+ i 1)))
%>
<%= (concatenate 'string "<p>This is" " lisp too" %>
<%!
(defun p-tag ()
"<P>")
%>
Using the JSP surface syntax might be worthwhile just because you then
might be able to leverage existing tools that already understand it.
And if you care about such things, there might also be advantages to
making lisp fit into an existing, popular standard for mixing HTML +
program logic rather than doing it in some incompatible way (unless
there are good reasons for the incompatibility).
John Wiseman
in article ··············@localhost.localdomain, John Wiseman at
·······@localhost.localdomain wrote on 6/5/00 3:10 PM:
> "Sunil Mishra" <·······@arslogica.com> writes:
>
>> We are pleased to announce Lisp Server Pages, or LSP, as an open
>> source project. LSP is a Common Lisp based technology for dynamic
>> HTML generation that transforms LSP documents embedded with Common
>> Lisp into executable HTML generation functions.
>
> I realize that the purposes of the two systems are somewhat different,
> but it might be worth looking into fitting LSP into the JSP model.
> Despite the name (Java Server Pages), JSP is meant to be
> language-independent. As far as I know, the following is completely
> legal JSP:
>
> <·@ page language="lisp" %>
> <h1>The first 10 natural numbers</h1>
>
> <%
> (dolist (i 10)
> (format out "~&~A~D" (p-tag) (+ i 1)))
> %>
Rather than introduce new markup, we deliberately decided to stay within the
realm of SGML semantics. This theoretically gives us the advantage of being
able to apply standard SGML tools to process a given LSP document, for
verification or whatever else. Moreover, LSP does not merely embed code into
an HTML document. It can also selectively transform portions of the input
LSP document into executable code. Consider:
<html>
<head>...</head>
<body>
<table lsp-fn-name="this-table-printer">
...
</table>
</body>
</html>
This simple modification encapsulates the content of the table into a
callable function *within the scope of <body>*. Preserving lisp and SGML
semantics in this sense is one of the strong points of LSP, which I would be
hard pressed to find in an approach that does not take the semantics of SGML
into account in any way. And this is only the simplest example of the
abilities one may potentially introduce into LSP. We have introduced
constructs that enable us to treat form controls as variable bindings, which
makes the manipulation of values substantially simpler. There are
potentially many other needs that may be expressible only if SGML semantics
are taken into account, and LSP can potentially be extended to cover them as
well.
>
> <%= (concatenate 'string "<p>This is" " lisp too" %>
>
> <%!
> (defun p-tag ()
> "<P>")
> %>
>
> Using the JSP surface syntax might be worthwhile just because you then
> might be able to leverage existing tools that already understand it.
> And if you care about such things, there might also be advantages to
> making lisp fit into an existing, popular standard for mixing HTML +
> program logic rather than doing it in some incompatible way (unless
> there are good reasons for the incompatibility).
We looked upon our choices in a different way. It was between treating HTML
as data to be interspersed with code, and treating HTML as a structured
language which may be transformed into more interesting structures (such as
programs). In our implementation, the host and the script languages coexist
rather nicely, and we believe this is a very useful feature. We shall have
to see if we can convince others of this logic.
Sunil
in article ····························@4ax.com, Jonathan Siegel at
···@scorekeep.com wrote on 6/8/00 7:10 PM:
> Sunil,
>
> I have attempted to load your LSP package into a running AllegroServe
> server and received the following error:
>
> USER(13): :ld start.lisp
> ; Loading /home/jonathan/lsp-0.5-dev/start.lisp
> ;;; Compiling file /home/jonathan/lsp-0.5-dev/defsystem.lisp
> ;;; Writing fasl file /home/jonathan/lsp-0.5-dev/defsystem.fasl
> ;;; Fasl write complete
> ; Fast loading /home/jonathan/lsp-0.5-dev/defsystem.fasl
> ; Loading /home/jonathan/lsp-0.5-dev/plist/config/plist.system
> ; Loading
> /home/jonathan/lsp-0.5-dev/tokenizer/config/tokenizer.system
> ; Loading
> /home/jonathan/lsp-0.5-dev/html-parser/config/html.parser.system
> ; Loading /home/jonathan/lsp-0.5-dev/lsp/config/lsp.system
> ; Loading
> /home/jonathan/lsp-0.5-dev/publisher/config/publisher.system
> Publishing lsp-doc directory to localhost:8080/...
>
> Error: Package "PUBLISHER" not found. [file position = 3179]
> [condition type: READER-ERROR]
>
> Restart actions (select using :continue):
> 0: retry the load of start.lisp
> 1: skip loading start.lisp
> 2: Abort #<PROCESS Initial Lisp Listener>
> [1] USER(14): :zo
> Evaluation stack:
>
> (ERROR READER-ERROR :STREAM ...)
> ->(LOAD "start.lisp")
> (TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP)
> (TPL:START-INTERACTIVE-TOP-LEVEL #<BIDIRECTIONAL-TERMINAL-STREAM
> [initial terminal io] fd 0/1 @ #x40036ea> #<Function
> TOP-LEVEL-READ-EVAL-PRINT-LOOP> ...)
>
> Do you know what can be causing this?
>
> Thanks,
> Jonathan
> ···@scorekeep.com
In my enthusiasm for trimming down the loader, I think I deleted one line
too many. I'll send you a correction via email, and fix the distribution at
work tomorrow.
Thanks for pointing out the problem.
Sunil