The best approach is to push as much functionality into the client as
possible. The ideal server-side framework consists of nothing more
than a permissions-based interface to persistence and network
services. That's it. Everything else is done on the client side, in
JavaScript.
Web designers can pretty easily style dynamically generated HTML, if
the semantics are good -- you just need to let them capture that HTML
in any given part of the application.
What this means is that effort is probably best directed at Yhc/
JavaScript and similar projects, which compile Haskell to JavaScript
for execution on the client. Sure, some server-side work needs to be
done, but it's extremely minimal. Far more needs to be done on the
client-side. There's not many people working on that and the
infrastructure is in need of more creative input and development
resources.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net | 877-376-2724 x 101
On Jan 25, 2009, at 10:54 PM, Michael Snoyman wrote:
I´m working in a web application rather than a web framework. But I
sometimes think about how a complete web application server should
be. For my case, I don´t care about the presentation, because HSP is
more than enough. However, I need active-active clustering,
distributed transactions and workflows. I have created the module
Workflow for the latter. For the former, I developped TCache, that
is a transactional cache using STM, with configurable persistence. It
´s like hibernate for Java and (the data part of) Rails for Rubi.
Now I´m working in a extension of TCache with distributed
transactions and remote clustering with some additonal interesting
characteristics.
That all sounds like something that would fit very nicely into this
framework that I'm addressing.
My own view about haskell and Web applications is that something
like " a web framework" is not in the philosophy of Haskell. What
is in the philosophy of Haskell is the creation of modules that the
people can combine to create their own web frameworks.
I agree to a certain extent. If you look at the code that I've
written so far, it's in "layers." The bottom layer defines a Request
and Response object, defines a service as "Request -> IO Response",
and a server as something as essentially "Service -> IO ()". The
next layer is a controller which is itself a service. View details
are built on top of this.
In your case, you could bypass all the controller logic if you like
and simply deal with the server definition. You would get the
advantage of having your app work as a standalone server, a CGI
program, FastCGI, or anything else that people write adapters for.
Someone else might decide to use the the controller and ignore the
specialized view code (they really like dealing with straight
Strings perhaps).
However, I think we should develop a full stack so that it is
available for those that want it. From my Django experience, I must
say that very few things are cooler than calling a script which
automatically generates all the boilerplate code inherent in every
web app. I think those features should be available to those who
want it (even if it's not in the spirit of Haskell), while those who
want to treat the "framework" as a set of libraries need not been
hindered by the extra features.
Michael
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
