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.
>> 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.
> 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.
Cheers,