[Ur] Blog post

[Adam Chlipala]

David Snider wrote:
> http://www.davidsnider.net/2011/05/10/drupal-style-themes-with-urweb/
>
> Any thoughts would be appreciated.

My initial plan was to respond in a comment to your blog post, but I 
haven't been able to figure out how to do that, since you are requiring 
an account with your blog for comment posting, but I see no form for 
creating an account.

So, here's my response:

> I'm wondering if there is a way to make it so that when theme.urp 
> changes the site will recompile and /safely/ (as in, without 
> interrupting active user sessions) replace the old process with the 
> new one. Or, at least cleanly do it by informing the user that the 
> site has been updated and their old session is no longer valid.

It would be easy to do a seamless replace using a proxy that holds all 
connections while the old server process is closing and the new one 
starting.  I don't understand the focus on "safely" for a graphical 
theme.  All old URLs and so forth should just keep working; pages will 
just look different.

> One of the thoughts I've heard is wrapping the entire site in a 
> functor and passing each of these rendering modules in explicitly as 
> parameters.

Yes, that's what I assumed you were doing before I read the code!  IMO, 
that is a much cleaner approach (though I don't see a reason for giving 
each rendering function its own module; that just seems to bloat the 
interface).

> I like the sound of this idea but I'm not quite sure how to do it. 
> Part of the problem I'm having is declaring signatures for the HTML 
> that is supposed to be returned. If you explicitly define one then 
> won't the designer get locked into a certain rendering style?

I don't understand this question.  The whole point of modularity is to 
use well-defined interfaces.  Are you expressing doubt that you could 
write an interface that wouldn't leak too many implementation details?  
Given the code you have now, I wouldn't expect that to happen.

> Can a functor declare a return type of "let the compiler infer it"? 
> I'm guessing it can.

Yes, every declaration has a most general type/signature inferred for it 
by default.  Signatures can abstract these most general types and 
signatures, but you can always avoid that for a functor by, say, putting 
it in a .ur file by itself and creating no corresponding .urs file.

> (Side Note: I also put all the database definitions into one module. 
> Is there any reason for not doing it this way?)

By doing this, you lose out on all opportunities for encapsulation.  For 
instance, with your current code, you must worry that any theme could 
read and write the users table.  That would be provably impossible if 
you made the users table private to the authentication module.