[web-devel] Hoogle Advice

[Michael Snoyman]

On Tue, Jan 25, 2011 at 8:53 PM, Bardur Arantsson <spam at scientician.net> wrote:
> On 2011-01-25 09:49, Michael Snoyman wrote:
>>
>> On Tue, Jan 25, 2011 at 9:33 AM, Bardur Arantsson<spam at scientician.net>
>>  wrote:
>>>
>>> On 2011-01-25 02:14, Jeremy Shaw wrote:
>>>>
>>>> On Mon, Jan 24, 2011 at 4:38 PM, Neil Mitchell<ndmitchell at gmail.com>
>>>>  wrote:
>>>
>>> [--snip--]
>>> The thing I'd like to see is really more *framework-independent* code for
>>> things like session handling, cookie handling, etc. I really like the
>>> 'http'
>>> package for this reason. It does exactly one thing and (mostly) doesn't
>>> get
>>> in the way of whatever else you're trying to do.
>>>
>>> Maybe some of this 'generic' stuff could be put in WAI middleware -- then
>>> at
>>> least Neil and I could share that code :).
>>
>> I've been making a big push to get framework-agnostic code separated
>> out into separate packages wherever possible. For your case you may
>> want to look at the cookie and clientsession packages. Additionally,
>> you may want to consider using blaze-html for the HTML generation, or
>> even Hamlet.
>
> I've already settled on blaze-html... a lot less fidgeting with string
> concatenation, etc. plus it seems to perform extremely well.
>
> Hamlet isn't really useful for my purposes -- I really want *ALL* the
> client-side HTML/JS/etc. to be generated by widgets/components and my
> framework users shouldn't write any HTML directly. This HTML will also be
> injected into the page dynamically as the user interacts with the UI, so
> blaze-html is great.

For your use case, blaze-html *does* sound like the way to go. And I
agree: it's an awesome package.

>> I'd be interested in hearing more about how you are planning on
>> implementing this framework.
>
>> Yesod already provides built-in support
>>
>> for widgets, though so far I have been very conservative about
>> including direct Ajax features. For the most part, it is used for
>> providing form controls that do validation. However, there's no reason
>> it *couldn't* be used for Ajax.
>>
>
> I've actually implemented a little demo app in Yesod and have looked a
> little at the widget type/module, but as far as I can tell they don't go
> anywhere close to where I want to go. I don't have an actual design doc
> anywhere at the moment, so the only thing I can use to illustrate what I
> want to do is by way of pointing to Vaadin. You basically program as if you
> were programming an old-school graphical UI (Swing, SWT, GTK+, Tk, whatever)
> and the framework takes care of "translating" that to a browser application.
> Essentially the user should not have to write *ANY* html, JavaScript or CSS
> at all.
>
> All the state transfer will happen through callbacks to the server and/or
> Comet-style push updates to the browser. I'm still investigating reasonable
> ways to implement proper state handling.

I could be wrong here, but I have the feeling that it *should* be
possible to build up such a solution based on the what Yesod provides
in widgets. Obviously, such a solution would add much more power than
what Yesod provides, but I think it already provides enough of the
low-level details to get what you need. I'm not trying to convince you
to use Yesod for this, but I would be very appreciative to hear what
Yesod's widgets are lacking to get the functionality you want.

>> Following my normal sets of advice, I would recommend that any
>> component that you build that is not intrinsically tied to your
>> framework be released as a separate package so we can all benefit and
>> share resources where relevant. And if you have questions/requests on
>> the WAI side, just let me know.
>>
>
> Sure.
>
> One thing I am looking for is a convenient way to autogenerate JavaScript. I
> could use the "blaze" string builders (or builders for Text or whatever),
> but if there is some library for building JS in a safer way than just string
> concatenation. As with the HTML, I'm also going to be generating this JS
> extremely dynamically. I know about Julius, but what I (think) I really need
> is a sort of AST datatype for JavaScript with a toText/toBS printer.

Alan Zimmerman put together a Javascript minification package[1], and
in the process created a full-blown Javascript lexer/parser/AST
package[2]. That may be somewhere do start.

Michael

[1] http://hackage.haskell.org/package/hjsmin
[2] http://hackage.haskell.org/package/language-javascript-0.4.2