Towards 1.0
Niklas Broberg
I haven't had much time for HSP-related stuff the last month or so,
and the rest of June is looking pretty thick too. But after that I
hope to be able to put some more time into my favorite project
again. :-)
A question that's been going around in my mind for a while is this:
What are we lacking in HSP to make a 1.0 release?
Intuitively it feels like there's some way to go yet, but on the other
hand we already have something that's clearly useful. I think a 1.0
release should be a realistic goal, or at the very least a tangible
milestone to work against, and I would like to hear your opinions on
which areas of HSP that needs attention before that can come to be.
This could be anything from gritty implementation detail ("HTML
encoding fails when...") to more visionary stuff ("we really need
support for ...").
Some issues off the top of my head, that may or may not be important:
* HSP depends on other packages that themselves have version numbers
<1.0 (haskell-src-exts and now also utf8-string).
* HSP is not currently usable with any server other than HAppS, e.g.
Apache, other than in CGI mode.
* HSP currently doesn't provide anything in the spirit of session
management.
* HSP could provide better support for things like database
integration, user authentication, form validation, etc...
* HSP is still fairly untested in vivo.
* HJScript is still lacking in many areas, in particular relating to
encodings of the DOM (which would differ in HTML and XHTML).
What do you think about these things, and other things that I haven't
considered or remembered? Please speak up!
Cheers,
/Niklas
stepcut
> Hi all,
important to *me* ;)
> * HSP depends on other packages that themselves have version numbers
> <1.0 (haskell-src-exts and now also utf8-string).
> * HSP is not currently usable with any server other than HAppS, e.g.
> Apache, other than in CGI mode.
> * HSP currently doesn't provide anything in the spirit of session
> management.
> * HSP could provide better support for things like database
> integration, user authentication, form validation, etc...
> * HSP is still fairly untested in vivo.
I guess it will be test in vivo then ?
> * HJScript is still lacking in many areas, in particular relating to
> encodings of the DOM (which would differ in HTML and XHTML).
about in the next few weeks. Hopefully simple stuff, like additional
bindings to javascript.
> What do you think about these things, and other things that I haven't
> considered or remembered? Please speak up!
haskell in them. It would simply using happs-hsp-template a bit.
j.
Niklas Broberg
> important to *me* ;)
Of course, that's what I wanted to hear - but not just from you but
from anyone else listening too. :-)
> > * HSP depends on other packages that themselves have version numbers
> > <1.0 (haskell-src-exts and now also utf8-string).
>
> Doesn't bother me.
It *does* bother me to some extent, but if it's only these two then
it's probably no problem. I might do a 1.0 release of haskell-src-exts
soon enough, and utf8-string is a Galois package, bound to be
maintained.
> > * HSP is not currently usable with any server other than HAppS, e.g.
> > Apache, other than in CGI mode.
>
> I only plan to use HSP with HAppS.
That's probably the case for me too, but if we want to compete with
mainstream languages then an Apache binding seems inevitable.
*However*, since we already rely so much on HAppS, and put so much
functionality on the HAppS layer, it would make the most sense to make
the binding between Apache and HAppS instead of Apache and HSP
directly. But then the (questionable) win of using Apache over HAppS
is nullified since you'd have to use HAppS anyway...
> > * HSP currently doesn't provide anything in the spirit of session
> > management.
>
> I use HAppS for that.
Interesting! Would you care to show a simple example of how that's
done in HAppS? I'm still pretty unused to HAppS and what it can
provide, and I would be very interested to see this in action.
> > * HSP could provide better support for things like database
> > integration, user authentication, form validation, etc...
>
> HAppS.
Examples? I'd settle for links to them... :-)
> > * HSP is still fairly untested in vivo.
>
> I am using it in a number of projects which I hope to launch soon. So,
> I guess it will be test in vivo then ?
Indeed! I'd love to see the results of that. I was also thinking of
things like stress tests for performance, but I guess since we're
relying on HAppS then all we would be stress test would be HAppS
(which is arguably quite efficient already).
> > * HJScript is still lacking in many areas, in particular relating to
> > encodings of the DOM (which would differ in HTML and XHTML).
>
> This is the area I expect to make the most contributions/complaints
> about in the next few weeks. Hopefully simple stuff, like additional
> bindings to javascript.
Very nice.
> > What do you think about these things, and other things that I haven't
> > considered or remembered? Please speak up!
>
> It would be really nice if trhsx could parse files that have template
> haskell in them. It would simply using happs-hsp-template a bit.
Right, there's an open bug in haskell-src-exts for that. There used to
be working support for TH, but the syntax was changed for 6.4 iirc and
haskell-src-exts was never updated to fix that. It should be rather
easy though, I'll have a look when I get some time over.
More comments please!
Cheers,
/Niklas
Joel Björnson
<niklas....@gmail.com> wrote:
>
> Hi all,
>
> I haven't had much time for HSP-related stuff the last month or so,
> and the rest of June is looking pretty thick too. But after that I
> hope to be able to put some more time into my favorite project
> again. :-)
>
> A question that's been going around in my mind for a while is this:
>
> What are we lacking in HSP to make a 1.0 release?
Hi, unfortunately HSP has had to be low prioritized for me as well lately.
Anyway, I've recently started to have a look on Happs and must say I'm
quite impressed by the programming model offered using HSP as a
templating language. Therefore my personal interests is more aimed
towards the front-end part of HSP, that is the UI generation including
HTML, CSS, JavaScript and maybe XML transformation.
Trying to be a little more specific, heres a couple of ideas that I
think is worth considering for a 1.0 release:
* Complete HJavaScript DOM.
* Add-event functions for dynamically adding events in HJScript. (Type
classes needed)
* Bindings to third-part javascript libraries such as jQuery,
Prototype, script.aculo.us.
* Facilities for defining and specifying CSS properties and attach
them to elements.
* Improved AJAX facilities (accessing server functions, passing
parameters and handling data responses, timeouts).
* DOCUMENTATION (Installation guides, tutorials etc.)
And some of the more "visionary" stuff:
* Very high-level UI interface language built on top of HSP XML,
HJScript and CSS.
* Automatic form derivation.
This would include both the server-part (Happs) and the front end. The
(vague) idea is to define some data structure and then automatically
be able to derive html forms for adding or editing elements of this
data structure. To derive reasonable names for the fields etc, I guess
TH would be required. Additionally, functions should be generated for
constructing data from the post-request produced by the form as well
as functions (server-side and client-side) for checking the validity
of the form content. Well, lots of things to figure out but if doable
I think this would be a very useful feature, since there is normally
so much boilerplate code involved in creating web-interfaces for
editing data.
- Joel
stepcut
> > > * HSP depends on other packages that themselves have version numbers
> > > <1.0 (haskell-src-exts and now also utf8-string).
>
> > Doesn't bother me.
>
> It *does* bother me to some extent, but if it's only these two then
> it's probably no problem. I might do a 1.0 release of haskell-src-exts
> soon enough, and utf8-string is a Galois package, bound to be
> maintained.
needs to do is small, well-defined, and not likely to change much. So,
I expect most changes to utf8-string will be minor build issues due to
newer versions of GHC.
> > > * HSP is not currently usable with any server other than HAppS, e.g.
> > > Apache, other than in CGI mode.
>
> > I only plan to use HSP with HAppS.
>
> That's probably the case for me too, but if we want to compete with
> mainstream languages then an Apache binding seems inevitable.
> is nullified since you'd have to use HAppS anyway...
web-hosts which do not allow you to run your own server on port 80.
So, you need a way to run HAppS under Apache. Lemmih wrote a FastCGI
interface to HAppS last year, which I think is a pretty good solution.
If your host supports FastCGI, then you don't have to convince them to
do anything special to support a HAppS application. (I suspect the
HAppS FastCGI support has bitrotted, but should not be hard to bring
back).
So, I think the best question is, what would you want that FastCGI
+HAppS does not provide? HAppS is pretty complex to get started with
-- so having a lightweight alternative could be nice. Unless you get
feature creep and just end up with heavyweight HAppS alternative. One
use case to look at is sites that would use HSP, but *not* have server-
side state. HSP seems like it should work well as a 'templating'
language. For a site that has things like navigation bars, google
analytics, calls to google charts, etc, HSP can be a big win. None of
those features require any server-side state, and they are common to
many sites. (ok, some of them require server-side state, but that
state is maintained on google's servers).
> > > * HSP currently doesn't provide anything in the spirit of session
> > > management.
>
> > I use HAppS for that.
>
> Interesting! Would you care to show a simple example of how that's
> done in HAppS? I'm still pretty unused to HAppS and what it can
> provide, and I would be very interested to see this in action.
target date is July 4. My code for session management, users, etc is
located at:
http://src.seereason.com/HAppS/HAppS-Extra/
The basics of Session support are in:
http://src.seereason.com/HAppS/HAppS-Extra/src/HAppS/Data/Session.hs
I need to add the portion that deals with cookies, expiring sessions,
etc, still.
> > > * HSP could provide better support for things like
> database integration
is no reason you can't use existing database libraries like haskellDB
if that suits your fancy.
> user authentication
Also targeted for July 4,
http://src.seereason.com/HAppS/HAppS-Extra/src/HAppS/Data/User/Password.hs
> form validation
This is really hard problem (and one well worth solving). I don't have
any answers yet, but after July 4, I will be posting a blog entry
about what I would like to see.
> Examples? I'd settle for links to them... :-)
small demo site/tutorial. Maybe by the end of July.
> Right, there's an open bug in haskell-src-exts for that. There used to
> be working support for TH, but the syntax was changed for 6.4 iirc and
> haskell-src-exts was never updated to fix that. It should be rather
> easy though, I'll have a look when I get some time over.
issue. I do have a work around, but it is really ugly and annoying.
j.