Re: [patch] Add plain HTML generation

[Sent directly to Drew by mistake.]

Hi Drew,

On Fri, Jan 30, 2009 at 00:19, Drew Crampsie <drewc <at> tech.coop> wrote:
> This is a good idea, but the execution (run time parameter checks) is
> not at all right.. it should be done at compile time.
>
> I'll accept the patch if you want to rework it so that the logic is
> all finished by run-time, but i can't possibly keep it like this ..
> there is no need to do the work every time a page is rendered :).

The reasoning behind it was that otherwise it becomes a nightmare to
maintain two seperate versions of everything in the case where one
Lisp image needs to generate both HTML and XHTML (or both HTML and any
XML format, for that matter).  This might happen if you run an
HTML-based site and an XHTML-based site in the same image; if you use
content negotiation to serve up XHTML to capable browsers, HTML to
others; if you use HTML everywhere on your site except in those cases
where you need to use XHTML features (e.g. specific pages with
embedded MathML or SVG); if you use YACLML to generate static HTML as
well as static XHTML; or if, indeed, you have a completely HTML-based
site and you generate any sort of XML output (RSS, Atom come to mind).

If the decision is made at compile-time as to which version to
generate, then each time you make a change to your template, you need
to first recompile every file under yaclml/src/tags/, then recompile
your own template, since the decision is made when you compile those
files rather than your template.

Re: [patch] Add plain HTML generation

Aankhen <aankhen <at> gmail.com> writes:

> [Sent directly to Drew by mistake.]
>
> Hi Drew,
>
> On Fri, Jan 30, 2009 at 00:19, Drew Crampsie <drewc <at> tech.coop> wrote:
>> This is a good idea, but the execution (run time parameter checks) is
>> not at all right.. it should be done at compile time.
>>
>> I'll accept the patch if you want to rework it so that the logic is
>> all finished by run-time, but i can't possibly keep it like this ..
>> there is no need to do the work every time a page is rendered :).
>
> The reasoning behind it was that otherwise it becomes a nightmare to
> maintain two seperate versions of everything in the case where one
> Lisp image needs to generate both HTML and XHTML (or both HTML and any
> XML format, for that matter).  This might happen if you run an
> HTML-based site and an XHTML-based site in the same image; if you use
> content negotiation to serve up XHTML to capable browsers, HTML to
> others; if you use HTML everywhere on your site except in those cases
> where you need to use XHTML features (e.g. specific pages with
> embedded MathML or SVG); if you use YACLML to generate static HTML as
> well as static XHTML; or if, indeed, you have a completely HTML-based
> site and you generate any sort of XML output (RSS, Atom come to mind).

Why would you want to generate HTML4? The xhtml produced by yaclml is
valid html (note things like "<empty />" and whatnot). 

--

-- 

Re: [patch] Add plain HTML generation

On Wed, Feb 4, 2009 at 02:44, Clinton Ebadi <clinton <at> unknownlamer.org> wrote:
> Why would you want to generate HTML4? The xhtml produced by yaclml is
> valid html (note things like "<empty />" and whatnot).

Actually, the XHTML produced by YACLML is *well-formed* (i.e. there
are no syntactical errors) XHTML (i.e. not HTML).  Producing invalid
code with YACLML is easy.  Observe:

  (:span (:div "Hi")) ⇒ <span><div>Hi</div></span> ; invalid because
`span' is an inline element; it is not allowed to contain block-level
elements like `div'

Of course, that's a *good* thing, IMO.  YACLML generates markup.  It
should not be enforcing validity.

As for your question, the choice between XHTML and HTML is (at this
point) rather philosophical, hence why I avoided getting into the
"why" of it in my original post.  Suffice to say that there is nothing
to be gained from using XHTML unless you're actually making use of the
fact that it's XML, by integrating other vocabularies or parsing it
using XML tools in a way that you couldn't if it were HTML.  All that
requires you actually serve it as `application/xhtml+xml'—which
Internet Explorer, happily enough, doesn't support—or else the browser
just takes it to be regular HTML tag soup.

…I'll stop here rather than clutter up the list with more in that vein. 

Aankhen

_______________________________________________

Re: [patch] Add plain HTML generation

Hi Drew,

Here's a reworked patch that implements the static processing flag I
mentioned earlier.  Sorry it took so long.

Aankhen

_______________________________________________
bese-devel mailing list
bese-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel

Minor Arnesi and UCW Fixes for CCL

Greetings,

I have a small (total of ten characters changed!) patch to arnesi in my
branch at http://darcs.unknownlamer.org/arnesi_dev_closer-mop/ that
makes call/cc work with at least CCL. I'm not sure if this is /right/;
is there any particular reason `closure/cc' was only a
`funcallable-standard-class' on SBCL? I am potentially missing something
here... but did the code work at all on any other implementations?

My branch also has a (large, but straightforward) patch to remove MOPP
in favor of Closer
MOP. http://unknownlamer.org/darcsweb/browse?r=arnesi_dev_closer-mop;a=commitdiff;h=20090209034308-44524-b9334b5e7612ffa659f4d87cb0160e3ad37776b2.gz
shows the two spots where I removed the #+sbcl to make things work with
CCL.

A couple of minor fixes to UCW Core are in my branch
(http://unknownlamer.org/darcsweb/browse?r=ucw-core_clinton;a=commit;h=20090209033623-44524-e2df0861e544e62590e723df4362fa8595bcff72.gz)
that make things run on CCL. I did a quick test and everything seems to
be OK.

--

-- 
"Karen loved animals. Unfortunately the cheetahs betrayed her trust,"
Libot said.

Re: New tutorial typos

Hi again, sorry for the long delay in this reply. I've been slowly
hacking (on other things too) and reading UCW's source...

>2009/1/15 szergling <senatorzergling <at> gmail.com>:
>> Some further questions:
>>
>> In the YACLML section,
>>
>> *** YACLML: Yet another common lisp markup language.
>>
>> (defun render-message-form (name)
>>  (<:form
>>   (<:as-html "Enter a new message:")
>>   (<:input
>>    :type "text" :name (string-downcase name))
>>   (<:submit)))
>>
>> What does the form submit to? That is, what gets generated in the
>> <form> html tag?  <form action='??' action='??'>
>
>The <:FORM tag is identical in every way to the HTML <FORM/> tag. HTML
>specifies where this form is submitted, not UCW or YACLML.

Actually, I was wondering about something like

<form method="post" action="post_message.ucw">

or some such. An examination of the html produced (see example) shows
that this is not necessary. I wasn't aware (my own ignorance) that a
form without the html method & html action fields will still work

Follow up to "New tutorial typos"

Sorry if my previous email did come through, but I've been getting no
end of trouble from common-lisp.net mailing lists. Lost emails, no
"own posts" (yes, it's ticked in the "mailing list membership
configuration" panel), etc. This time, it looks as if my last post was
truncated, so I'm including it again as an attachment. Very sorry for
the mess. (but I don't think it's my fault). Any tips on managing
using all these mailing lists? I don't even subscribe to that many...

Apologies if this seems like a rant. I'm frustrated. You don't even
deserve this... it's not your fault.

Hi again, sorry for the long delay in this reply. I've been slowly
hacking (on other things too) and reading UCW's source...

>2009/1/15 szergling <senatorzergling <at> gmail.com>:
>> Some further questions:
>>
>> In the YACLML section,
>>
>> *** YACLML: Yet another common lisp markup language.
>>
>> (defun render-message-form (name)
>>  (<:form
>>   (<:as-html "Enter a new message:")
>>   (<:input
>>    :type "text" :name (string-downcase name))
>>   (<:submit)))
>>
>> What does the form submit to? That is, what gets generated in the