some refactoring of hsx and hsp

[stepcut]

Hello,

I would like to propose moving the following modules out of HSP (and
into HSX perhaps?):

HSP.XML
HSP.PCDATA
HSP.HTML

These three modules define an XML type and provide functions to render
it as XML or HTML 4.01 strict. These modules do not depend on anything
else in HSP. They provide functionality that is useful with monads
other than the HSPT monad.

The rest of the code in HSP provides an HSPT monad that has it's own
Request type, etc. When using hsx with Happstack, I don't need any of
that stuff..

Making this change means that I can just use 'hsx', instead of having
to install hsx, hjscript, hjavascript, and HSP.

While making this change, we might also consider adding some other XML
types, such as ones based around Text or blaze-builder. And perhaps a
XMLGenerator instance for IdentityT.

The moved modules could go in hsx, or into a new package, like hsx-
xml. I think that will depend, in part, on how many new dependencies
that adds to hsx. For what I have proposed so far blaze-builder might
be the only need dependency.

- jeremy

[Niklas Broberg]

Hi Jeremy,

I've actually had quite a lot of thoughts about refactoring the structure of the whole HSP/HSX family. What you say is a step in that direction, but there's more to it. Let me try to paint the whole picture as I see it:

The support for the XML-in-Haskell extension is built up by four different layers:

1: trhsx (depending *only* on haskell-src-exts) provides *syntactic* support for XML inlined in Haskell code. This is really just syntactic sugar.

2: HSX.XMLGenerator provides a semantic framework to use with the syntax, but could (in theory) be used without trhsx and the XML syntax.

3: HSP.XMLGenerator and the HSPT monad provides a contextual framework that is an instance of the semantic framework of HSX.

4: HSP.XML (and the other modules you note) provides an implementation of the base type to be used with HSX, and HSP's implementation of HSX.

To make a crude analogy, 1 would correspond to the do-notation, 2 would be the Monad class and 3 would be a particular monad (and 4 doesn't fit the analogy, it would be like the values of a monad that always produced the same kind of values). 

Right now the hsx package implements 1 and 2, and the hsp package implements 3 and 4. What you suggest is to separate 3 from 4, which I definitely sympathize with. However, I would hesitate to then lump 4 together with 1 and 2 - that sounds to me like solving one problem by creating another.

I am more thinking along the lines of, what possibilities could we get by separating all four? Especially 1 and 2 seem interesting to separate, in the same line of thinking as rebindable syntax for e.g. the do-notation. For example, I recall that Neil Mitchell used an early version of trhsx solely as a syntactic preprocessor, and used his own home-rolled library that provided the (then-equivalents of the) 'genElement' et al functions.

Doing this split would allow us to look at support for other systems on many different level. E.g., could we provide integrated blaze-builder support in the HSX.XMLGenerator framework, or is there a more natural model that just reuses the syntax?

One possible downside of this is (an even larger extent of) package proliferation madness. I think the right solution there is clear documentation though, not artificial lumping. 

Thoughts?

Cheers,

/Niklas

--
You received this message because you are subscribed to the Google Groups "Haskell Server Pages" group.
To post to this group, send email to haskell-se...@googlegroups.com.
To unsubscribe from this group, send email to haskell-server-p...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haskell-server-pages?hl=en.

[Jeremy Shaw]

Sounds promising. I have no objections to creating more packages :)

Splitting things up like that might make it easier to support the use
of QuasiQuotes in addition to the external trhsx tool. For example,
this is what hamlet looks like now:

getHomeR = defaultLayout [$hamlet|
<h1>Hello World!
<p>Here are some of my favorite links:
<ul>
<li>
<a href=http://www.yesodweb.com/>Yesod Web Framework Docs
<li>
<a href=http://www.haskell.org/>Haskell Homepage
<p>Thanks for visiting!
|]

I like the fact that trhsx does not require extra markup like,
[$trhsx| |]. But being able to support both ways could be cool.

- jeremy