my body has been sucked into my head
stepcut
With the following page:
page :: Web XML
page = <html>
<head>
<% return () :: HJScript () %>
</head>
<body>
<h1>Where is my mind?</h1>
<p>It's in the script tag</p>
</body>
</html>
The generated xhtml looks like:
<html
><head
><script language="JavaScript"
/></head
><body
><h1
>Where is my mind?</h1
><p
>It's in the script tag</p
></body
></html
specifically, the expected contents of the <body> tag end up in the
<script> tag instead. Commenting out, the <% return () :: HJScript ()
%>, results in the body contents going where they belong.
j.
stepcut
in the script tag (which may be how firefox is interpreting it), but
in the xhtml I posted that is not actually the case. I believe the
real problem is that empty script tags *must* be shown as <script></
script> not <script />, or some browsers (such as firefox and IE) will
render the page blank.
I believe the xhtml spec states that you can not minimize the script
tag. See this blog for more info:
http://piecesofrakesh.blogspot.com/2005/03/script-tag-in-internet-explorer.html
Another question is, should the script tag be generated at all in this
instance. That is a matter of taste though.
j.
ps. The same is true for the textarea tag btw. If you put <textarea />
in your page function, the remainder of the page shows up inside the
textarea in firefox.
Niklas Broberg
Hi Jeremy,
I'm not sure I understand - I see nothing wrong with the output.
What's the error again?
Btw, is the Web monad something to do with happs-hsp? I haven't had a
chance to look at that closely yet, but it seems promising.
Cheers,
/Niklas
stepcut
> I'm not sure I understand - I see nothing wrong with the output.
> What's the error again?
guidelines for creating xhtml documents which can be parsed as valid
html.
http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines
One of the requirements is that an empty script tag must be rendered
as:
<script></script> instead of <script />
The restriction applies to a number of other elements, such as
<textearea>, <title> and <p>.
However, it appears to me that hsp always minimizes elements when
possible -- and therefore is not html backwards compatible.
Currently, the happs-hsp stuff serves the pages as 'text/html' which
forces browsers to interpret the output as html, and consequently, the
pages render incorrectly. In the example I initially pasted, the
browser will treat the <script /> as an open tag without a close tag,
and so the rest of the document is read in as if it appeared inside
the script tag.
One fix is to modify happs-hsp so that it serves the pages with the
mime-type, 'application/xhtml+xml' instead of 'text/html'.
Unfortunately, this has some major drawbacks -- for example, IE 6 does
not support application/xhtml+xml. Also, javascript for xhtml is
different in someplaces. For example, it does not support write,
writeln, document.applets, and a number of other things. Firefox < 3
does not support incremental rendering of application/xhtml+xml.
Additional differences are detailed here:
http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
It is my understanding that the current best practice is to generate
valid xhtml, but follow the guidelines in Appendix C, and serve the
page as text/html. HSP is, to a degree, in no man's land right now.
It does not generate backwards compatible html, and none of the
examples are valid xhtml. For them to be valid xhtml, they need to
open with something like:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
instead of plain old:
<html>
because, xmlns is a required attribute. Without it, firefox (and
possibly other browsers) will treat the document as a plain old xml
document instead of xhtml.
> Btw, is the Web monad something to do with happs-hsp? I haven't had a
> chance to look at that closely yet, but it seems promising.
(though open to change). All data communicated from HAppS->HSP is
passed in as JSON data. The HAppS portition holds your database and
'business logic' stuff. The access to it is uniform, you basically
make get/post requests to HAppS and it gives you back JSON data. So,
you have the same interface for the templating stuff (HSP), client-
side javasrcipt/ajax stuff, or 3rd party access to your APIs (for
mashups, etc).
That said, you don't have to use JSON for everything, HAppS is very
flexible in that regard. You don't even have to use it for making web
applications -- the web stuff is just one of the libraries built on
top of the HAppS core. You could use HAppS to build a MUD that you
access via telnet, or even just a way to save data in a single-user,
locally run application (such as an iTunes clone).
HAppS currently has 3 supported ways of generating html:
1. Use Text.XHtml (or a similar library) to generate the html
2. Use HAppS-Data to automatically derive XML for your data types,
and use xsltproc/saxon to turn the XML into html.
3. Use RJson to automatically derive JSON for your data types, and
use HSP to turn the the JSON into html.
Of course, you can also just do, ok (toResponse
"<html><head><title>hahahah</title></head><body>Do not do this.</
body></html>"), but I would not recommend it.
I have used all three methods a fair bit now, and so far HSP seems the
quickest, easiest, and (pontentially) most robust. Using Text.XHtml is
very tiresome, because you have to rebuild the entire web application
just to make a tiny change on a single page. This can take 5-15
seconds, even on a fast machine. Also, I find Text.XHtml hard to read,
and I often end up with my attributes attached to the wrong element.
It also encourages people to mix the html and business logic together
-- which then makes your life difficult when you want to get at the
information via javascript, etc.
Using xslt is lame because xslt 1.x is not very powerful, and the
syntax is very verbose. I often find that I have to try to spend a lot
of effort tweaking the XML that will be passed to xslt to make up for
the fact that xslt is so lame.
HAppS+HSP is nice, because it forces you to keep the business logic
and display layer separate. The syntax and power of HSP blow xslt
away. Plus, you get the advantages of type checking, etc. Also, HAppS
uses HSP by compiling the pages and loading them via hs-plugins. It
uses inotify to automatically determine when the pages have changed.
So, my changes are compiled and loaded before I even have time to
switch to the web browser.
j.
Niklas Broberg
> Here is my understanding. In the xhtml spec, appendix C, there are
> guidelines for creating xhtml documents which can be parsed as valid
> html.
>
> http://www.w3.org/TR/2000/REC-xhtml1-20000126/#guidelines
>
> One of the requirements is that an empty script tag must be rendered
> as:
>
> <script></script> instead of <script />
>
> The restriction applies to a number of other elements, such as
> <textearea>, <title> and <p>.
>
> However, it appears to me that hsp always minimizes elements when
> possible -- and therefore is not html backwards compatible.
Sigh. :-)
Don't you just hate it when they have to go and mess up a good idea
with legacy like that? The whole point of switching from HTML to XHTML
was that everything should be uniform! You can't make things uniform,
and then say they shouldn't be uniform after all. Double sigh. ;-)
> One fix is to modify happs-hsp so that it serves the pages with the
> mime-type, 'application/xhtml+xml' instead of 'text/html'.
I like this. Sounds like The Right Thing To Do.
> Unfortunately, this has some major drawbacks -- for example, IE 6 does
> not support application/xhtml+xml. Also, javascript for xhtml is
> different in someplaces.
This sounds like something I would care less about. I'm sure that
there are some who care about total backwards compatibility, but I'm
frankly not one of them. The fact that document.write no longer exist
is to me a BIG PLUS, since the whole idea behind HSP is to get away
from treating the page as an output stream of characters. And our
nifty literal syntax used in client-side code should take care of all
the hassle. Etc...
(Yes, I know I live in an idealized world, but so be it ;-))
I read that page you linked to, and I can't help notice that it's from
2003. Sure, some still use IE 6 of course - but the less pages IE 6
can serve, the faster it will disappear for good. IE 6 is pure evil.
That said, if someone were to send a patch to hsp that adds a
renderAsLegacyHTML :: XML -> String function, I would of course apply
it. Or if someone were to make a really good case for it (such as
promising to use HSP in a large-scale public application if this
existed), I might even write it myself. ;-)
> HSP is, to a degree, in no man's land right now.
> It does not generate backwards compatible html, and none of the
> examples are valid xhtml. For them to be valid xhtml, they need to
> open with something like:
>
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
>
> instead of plain old:
>
> <html>
>
> because, xmlns is a required attribute. Without it, firefox (and
> possibly other browsers) will treat the document as a plain old xml
> document instead of xhtml.
Hmm, that's interesting, and definitely a problem - and not too hard
to fix I guess. The literal syntax even supports passing a list of
extra attributes, so I guess we could define e.g.
reqHtmlAts = ["xmlns" := "http://www.w3.org/1999/xhtml",
("xml", "lang") := "en", "lang" := "en"]
and use that like
page = <html reqHtmlAts>... </html>
I guess that will go in the HSX.XHTML module, once I get it completed.
This weekend seems like a good target, but I've said that for three
weeks now... The combinators in HSX.XHTML that generate elements will
of course do that automatically.
> HAppS+HSP is nice, because it forces you to keep the business logic
> and display layer separate. The syntax and power of HSP blow xslt
> away. Plus, you get the advantages of type checking, etc. Also, HAppS
> uses HSP by compiling the pages and loading them via hs-plugins. It
> uses inotify to automatically determine when the pages have changed.
> So, my changes are compiled and loaded before I even have time to
> switch to the web browser.
You can't even begin to imagine how happy it makes me to hear you say
this, that you like it! :-)))
I've seen the first versions of happs-hsp but I haven't gotten to use
the later versions that Lemmih have done. But from what you say, it
truly sounds like it's nice and easy to work with, just like we've
always envisioned!
Please keep on reporting the ups and downs of your experiences, so we
can keep improving our system! :-)
Cheers,
/Niklas
stepcut
> Hi Jeremy,
> > One fix is to modify happs-hsp so that it serves the pages with the
> > mime-type, 'application/xhtml+xml' instead of 'text/html'.
>
> I like this. Sounds like The Right Thing To Do.
support application/xhtml+xml. So, setting that mime-type will ensure
than people using any version of IE can not view your website. They
will instead be prompted to download the page and save it to disk :(
http://realtech.burningbird.net/standards/ie8-standards-mode-by-default/
I'll have to do some more research and figure out how to get IE 8 to
take xhtml, and what it takes to get IE 7 to take xhtml. But, it seems
like serving as application/xhtml+xml is not a practical solution if
you expect any IE users to visit your site.
Assuming you did only care about non-IE users there are some other
fixes required to serve proper XHTML. In xhtml, < and & inside the
script tag are treated as markup. So, for example, if you write:
<% functionDecl "oops" $ \() -> return ((int 1) .<. (int 1)) ::
HJScript JBool %>
you will get a parse error like:
XML Parsing Error: not well-formed
Location: http://localhost:8000/
Line Number 7, Column 32: >function oops(){return 1 < 1;};</script
You need to wrap the script data inside CData as described here:
http://www.w3.org/TR/xhtml1/#h-4.8
However, if you do that, then it definitely won't work if served as
text/html instead of application/xhtml+xml.
This page shows an alternative that will work with either 'text/html'
or 'application/xhtml+xml',
http://hixie.ch/advocacy/xhtml
of course, he shows it to show why serving xhtml as text/html is a bad
idea :)
So, I guess I will do some more research and get back to you.
j.
stepcut
>
> Don't you just hate it when they have to go and mess up a good idea
> with legacy like that? The whole point of switching from HTML to XHTML
> was that everything should be uniform! You can't make things uniform,
> and then say they shouldn't be uniform after all. Double sigh. ;-)
1. No version of IE supports xhtml (include IE8 which is currently in
beta).
Every version of IE less than 8 has absolutely no support for xhtml.
IE8 has some support for xhtml, but not when served as application/
xhtml+xml. So, if you set up a true xhtml site today, no IE users will
be able to view your site, and IE8 will not help this.
2. XHTML 1.1 can not be served as text/html
It won't work, and is not recommend.
3. XHTML 1.0 loose can sometimes be served as text/html, but in
practice does not work well
4. XHTML 2.0 and xhtml 1.1 are not forwards or backwards compatible.
A browser that supports xhtml 2.0, won't automatically support xhtml
1.x -- they are completely different.
5. HTML 5 is in the works, and possibly more favored than xhtml
Support is already being added to opera, firefox, safari and ie, and
is backwards compatible with html 4.
6. w3c originally declared html dead in 1999 in favor of xhtml, but
html is still the clear winner on the web today
In fact, the w3c revived the html committee and created html 5. Only a
tiny portion of the web is served as html instead of xhtml, and many
sites which claim to be xhtml are in fact not.
7. xhtml and html are not subsets of each other
You can not convert all html->xhtml nor can you convert all xhtml-
>html. Each language allows you to specify things which can not be
specified in the other.
8. CSS and javascript for xhtml and html are different
It you create a nontrivial site in xhtml and convert it to html, you
are likely to also have to adjust your CSS and javascript as well as
they are not identical for html vs xhtml.
9. IE may support xhtml someday
There are developers on the IE team who would like to see real xhtml
support in IE, but they also want to make sure it is done correctly,
so that they don't create the IE6 fiasco all over again. However, it
is not clear when this will happen -- they have been talking about it
since IE6, and it definitely will not be in IE8. So we are talking
about at least IE9 or IE10.
10. HTML 5 might actually be pretty awesome
HTML 4 and XHTML 1.x/2.x are defined in terms of the syntax. HTML 5 is
defined in terms of the DOM. It can be serialized to either html *or*
xml (but they discourage xml). It has much better support for
integrating media, and better markup for creating page sections.
http://www.alistapart.com/articles/previewofhtml5
http://xhtml.com/en/future/conversation-with-x-html-5-team/
11. Conclusions
In theory you might be able to create some generalized version of x/
html+css+javascript, which can then be targeted specifically to html
or xhtml. But, you would be limited to the lowest common denominator,
and in practice might end up having to use non-compatible constructs
which force you to end up targeting only one or the other anyway. And
it would probably be a lot of work for dubious gain.
A better option would be to design your site to target only one
specific language (html, xhtml 1.x, or xhtml 2.x). So, at the HSP
level, it would make the most since to support those languages
directly.
There are basically 3 incompatible languages for creating a webpage:
i. html
ii. xhtml 1.x
iii. xhtml 2.x
The only one that is currently supported by all browsers and sure to
be support in the future is html. People have been pushing for xhtml
since 1999, but almost a decade later it has still gained very little
traction despite much jumping up and down. Whether xhtml 1.x, xhtml
2.x, or HTML 5 will win out seems to be up in the air still, but I
need to do more research. My initial investigation leads me to believe
that HTML 5 is a sure thing...
So, it may be the case that HSP needs a 'first-class' mode
specifically targeted towards creating html documents in addition to
an xml/xhtml mode. I will continue researching.
On the upside, one of the goals of HTML 5 is to describe how to
uniformly render 'invalid' html documents. So, xhtml *requires* that
you die horribly if there is the slightest error on the page. HTML 5
will instead specify exactly how every possibility should be rendered.
So, there is at least some kind of uniformity there.
j.
stepcut
http://www.digital-web.com/articles/html5_xhtml2_and_the_future_of_the_web/
Niklas Broberg
I've been so sure for so long that XHTML is the future, but it seems I
may have to reconsider. And if XHTML is not the future, then we need
to make sure that we support whatever is.
Where do we start? :-)
I guess an easy starting point is to write the renderAsHTML
(renderAsTagsoup?) function that takes care to be compatible as
specified in Appendix C. That would go a long way towards supporting
"reality", right?
In fact, since we never need to bother about actually *parsing* the
tagsoup, we don't need to care so much that the beautifully simple XML
model will be replaced by an ugly beast of HTML5 tagsoup (but inside I
cry blood).
We should of course continue to support XML in general, as well as
XHTML specifically. But if the DOM is different in XHTML and HTML,
exactly *how* we support HJScript for both is not quite so clear. Any
good suggestions on that? What are the major differences here?
Also, there is absolutely no reason why our own syntax should not
continue to be XML. In fact, that's the only way we could ever hope to
mix XML syntax and Haskell code. But that doesn't mean we have to
render it the same way we write it of course.
Cheers,
/Niklas
stepcut
> This is all very interesting.
>
> I've been so sure for so long that XHTML is the future, but it seems I
> may have to reconsider. And if XHTML is not the future, then we need
> to make sure that we support whatever is.
> I guess an easy starting point is to write the renderAsHTML
> (renderAsTagsoup?) function that takes care to be compatible as
> specified in Appendix C. That would go a long way towards supporting
> "reality", right?
done a lot more reading, I thinking that render xhtml as specified an
appendix C is not all the great either -- but is it better than the
current situation, and would be the fastest way towards some level of
html compatibility today.
> In fact, since we never need to bother about actually *parsing* the
> tagsoup, we don't need to care so much that the beautifully simple XML
> model will be replaced by an ugly beast of HTML5 tagsoup (but inside I
> cry blood).
is based around DOM instead of syntax, I don't know enough about HTML
5 or the HSP internals yet to tell.
> We should of course continue to support XML in general, as well as
> XHTML specifically. But if the DOM is different in XHTML and HTML,
> exactly *how* we support HJScript for both is not quite so clear. Any
> good suggestions on that? What are the major differences here?
properties are available. As I suggested in a different thread, we
might be able to do something with type classes to indicate what
environments support which methods/properties. I need to do more
research on this still.
> Also, there is absolutely no reason why our own syntax should not
> continue to be XML. In fact, that's the only way we could ever hope to
> mix XML syntax and Haskell code. But that doesn't mean we have to
> render it the same way we write it of course.
sounds reasonable. I also got the impression that HTML 5 was going to
extend the xhtml 1.x syntax to include the extra markup needed to
represent all of HTML 5. If so, then it would be quite logical for HSP
source code to stay pure XML syntax, which gets parsed in, but output
as HTML sgml-style when served. It sounded like the WHATWG recognized
that people were going to want to represent HTML 5 using XML, so
rather than have a bunch of ad-hoc implementations, they are providing
a canonical method of doing that. But, the discourage using the XML
syntax for serving the pages.
I will see what I can find in regards to HTML 5 and the XML syntax.
Targeting HTML 5 using XML as the input syntax and HTML as the output
format might be the most future proof and backwards compatible
solution. One question is whether the code should be parsed into the
HTML 5 DOM internally before being output as HTML (or XML), or if the
HTML output routine should work directly from the incoming XML. It's a
bit too early to worry about that though.
I'll continue with the research and let you know what I dig up.
j.
Joel Björnson
web standards. Seems like a common approach is to generate XHTML
documents still using the text/html MIME-type. But as explained in
http://hixie.ch/advocacy/xhtml it comes with some drawbacks.
>
> > We should of course continue to support XML in general, as well as
> > XHTML specifically. But if the DOM is different in XHTML and HTML,
> > exactly *how* we support HJScript for both is not quite so clear. Any
> > good suggestions on that? What are the major differences here?
>
> Right. I think the differences mostly revolve around what methods and
> properties are available. As I suggested in a different thread, we
> might be able to do something with type classes to indicate what
> environments support which methods/properties. I need to do more
> research on this still.
Maybe it's possible to find a nice way of encoding this using type
classes and if done properly it sure would be a cool feature. On the
other hand I think it's of great importance to keep the core
interfaces as simple as possible.
The simplest approach would be to provide DOM methods, even the ones
not supported by all browsers/standards, leaving it the user to decide
which platform to support. In some sense this would be analogues to
the HSP XML type that guarantees that the generated XML is well formed
but not that it's actually valid HTML/XHTML.
Another possibility (I've talked about it before) is to create wrapper
methods to some (suitable) third part JavaScript library letting it
take care of the browser/standard issues.
Off course all ideas are worth exploring and can co-exist in different
libraries. The main battle I guess is of how to design the core
library.
On a completely different subject, since you are using HAppS, have you
experimented with the HAppS-IxSet and if so, do you think it's
comparable to using relational data bases? What I'm really asking is
if non-trivial data base driven applications could be "easily" ported
to HAppS removing the need of an external data base server? (Just out
of curiosity).
- Joel
Niklas Broberg
> classes and if done properly it sure would be a cool feature. On the
> other hand I think it's of great importance to keep the core
> interfaces as simple as possible.
I'm of the same mind. While I think it would be possible to code this
up with type classes, I don't see it as desirable. I'd rather take an
approach similar to ByteString, i.e. having different versions with
identical interfaces and just switch between them using different
imports. We would of course not have *exactly* identical interfaces,
only for the parts that are common to both worlds. The rest would live
in one module or the other, and you'd get type errors if you tried to
use e.g. document # applets while using the xhtml module. So in a
sense you'd get the best of type classes without cluttering up the
interface.
> Another possibility (I've talked about it before) is to create wrapper
> methods to some (suitable) third part JavaScript library letting it
> take care of the browser/standard issues.
I think we could have that too, and I think that will be an important
part of HSP development, but I would prefer to have the core HJScript
support all the basics for the quick and dirty hacks. ;-)
Cheers,
/Niklas
stepcut
> On a completely different subject, since you are using HAppS, have you
> experimented with the HAppS-IxSet and if so, do you think it's
> comparable to using relational data bases? What I'm really asking is
> if non-trivial data base driven applications could be "easily" ported
> to HAppS removing the need of an external data base server? (Just out
> of curiosity).
applications to use IxSet, but I'm not sure if you would want to. It
might be a bit like 'porting' a python application to Haskell -- you
could do a fairly straight-forward port, but you might end up with
something that is a bit ugly and does not take good advantage of what
Haskell has to offer.
The really cool thing about HAppS is that you can use whatever Haskell
data structure you want in your database. If your data is naturally
tree structured (like a threaded message board), you don't have to try
to figure out how to convert your nice tree into a relational
database. (Putting trees in relational databases sucks no matter how
you do it.) Additionally, there is no divide between the parts of the
data processing you do in the language you like (Haskell) and the
language the database engine understands (SQL) -- you just work with
Haskell data types in their full glory all the time.
The HAppS transactional data store stuff is quite nice by itself, and
might be all you use in some applications. However, you might also
like a nice collection type beyond Data.Map or Data.Set. IxSet is a
nice data type in that regard. It's similar to Data.Map, except that
it allows you to have more than one key per value. It also comes with
some nice query operators.
Let's say you defined a some types like:
data Person = Person LastName Age
newtype LastName = LastName String
newtype Age = Age Integer -- ok, Word8 is probably saner, but better
safe than sorry
newtype Description = Description String
newtype Word = Word String
You could make a collection of people a bit like:
$(inferIxSet "People" 'calcWords [''LastName, ''Age, ''Word])
calcWords :: Person -> [Word]
calcWords person = map Word (words (gFind' person :: Description))
the inferIxSet function will create an new type, People, which is an
IxSet. It will be indexable by LastName, Age, or Word. The calcWords
function generates extra indexes from the input datatype. In this
case, it allows you to search for individual works in the Description
fields.
You can then query the set using various operators like:
(Age 10) @> people
Which will return a new ixset of people who are older than 10. Or,
(Word "shy") @= people
To get all the people who have the word, shy, in their Description. If
you want all the shy people older than 10 you would do:
(@> Age 10) . (@= Word "shy") $ people
(Note: I have not tested any of this code, so it may not actually
compile).
There are also union and intersection operators (which is how you
might opt to do SQL-like joins, etc).
So, in summary, I think you could reasonably use HAppS instead of a
traditional SQL database for non-trivial applications -- and with a
lot less screwing around. You probably could retrofit happs into an
existing SQL system, but not as a drop in replacement for mysql, etc.
For example, I don't think you would want to maintain a system which
could use MySQL *or* IxSet. You would have to have two versions of all
your SQL queries, stored procedures, etc. And, your design would be
constrained by the limitations of SQL, so you would miss out on the
stuff that makes HAppS+IxSet cool in the first place.
IMO, the easiest way to port an existing relational database to HAppS
and remove the dependency on an 'external' database server is to use
something like sqlite. On the other hand, your best long term plan
might be to rewrite the relevant parts of the system around the HAppS
model. I expect this will significantly reduce the size and complexity
of the code base compared to using sqlite -- which means less bugs,
easier to update, etc. Also, that would make it easier to take
advantage of sharding and other HAppS scaling technology.
And finally, I bet you could build an SQL compatibility layer on top
of IxSet, but I am not sure how useful that would be in practice. I
suspect many non-trivial applications use SQL server specific
features. And, I am not sure how that would be better than just using
sqlite.
j.
Joel Björnson
definitely play with this when having the time (always the time :-)).
- Joel