Re: [web-devel] Kick-off discussion: Yesod 0.9

This is some good stuff, thanks. Some specific comments below. On Wed, Jun 1, 2011 at 4:32 PM, Justin Greene wrote:

...

* Forms package: It's been rewritten, but hasn't really had much input from others. Now's the time to speak up if you have any opinions on it. The code is available on Hackage.

List of things that should be inside a forms package in my opinion. Custom Design: Form layout should be simple to customize and not be based around auto generating tables (if both are possible then of course the later can be used).

This is a major component of the design of the package. It now supports both Applicative (auto generating tables/divs) and Monad (custom layout) approaches. (The third type of form is an Input form, intended for only receiving form submissions without generating HTML.) Though I'm sure there are ways that the monadic forms could be improved, given that they aren't used nearly as much as Applicative in my sites.

Variable length lists: It should be possible to add form elements on the client side and bind them on the server side.  An example of this would be a list of addresses.  A programmer should be able to add a new address widget client side without problems when binding server side.

Agreed, this needs to be added.

Validation:  Complex validation scenarios should be simple and should fit into the normal validation pipeline.  An example would be validating that if a checkbox is selected then a textbox becomes required. All validation errors should display around the same time, e.g. if a type validator fires it should not prevent other validators from firing after it unless those validators depend upon that type data.

Right now, you can apply whatever validation you want to an individual fields and display the error messages inline. For complex scenarios, I'm not quite certain what an interface (both programming interface and UI) would look like for assigning these error messages inline. Short of that, it seems outside the scope of the form package itself to validate such interactions. For example, you could always write code along the lines of: ((res, form), enctype) <- runFormPost ... case res of FormSuccess x -> case complexTest x of Left e -> showFormWithErrMsg form e Right y -> onSuccess y _ -> showFormWithoutErrMsg form

These are just my thoughts based upon my experiences writing forms.  I can't really utilize any framework that doesn't implement these features for the types of projects I do. If you need any more details/clarification I'd be happy to help.

If you are interested in getting into more of the API design, that would be awesome. Michael

On Mon, May 30, 2011 at 3:41 PM, Michael Snoyman wrote:

...

Hi all,

It's been about a month since the 0.8 release of Yesod. In the release announcement[1], we laid out some goals. Let's take a chance to analyze where we're at:

* Documentation: Still improving as always. In particular, the new Yesod site is making it much easier for me to write new content (I have a few things on my local system that can finally go up).

* Static file caching headers: Implemented by Greg Weber. We'll likely be making some API changes to handle embedded files, though that discussion deserves its own blog post.

* Other template types: For Hamlet 0.9, we're going to be splitting Julius/Coffeescript into their own package, and juggling the type signature for Coffeescript a bit. At that point, it should be straightforward to embed Coffeescript directly into a Yesod app, just like Julius is today.

* Something like require.js: This is something we haven't started on yet. I'll likely start looking into it this week. Additionally, I know that a lot of my sites (jQuery powered) have numerous onload calls per page; I think we can try to make that more efficient as well. I would especially like people's input on this point.

* i18n: The solution is written, and I'm using it in production. At this point, I'd call it beta quality, and I'd appreciate input.

* Embedded objects in MongoDB: No work done yet.

* Performance improvements: Nothing in particular. If you have any examples of Yesod performing badly, please let us know.

The goal is for Yesod 0.9 to be feature complete, and for 1.0 to be a fairly stable API. From the list above, my two priorities are better Javascript loading (require.js) and static file serving. However, there's one other major issue we need to address: the devel server. Unfortunately, it doesn't work very well at all right now. Thankfully, "yesod build" *does* work very well, and for my development I've fallen back to simply "yesod build && ./dist/build/myapp/myapp" on the command line. My guess is that we're 90% of the way there on "yesod devel". This is a project that isn't tightly bound to the rest of the API work, and would be very approachable for someone trying to get started on Yesod development. If you're interested in helping out here, please let me know.

I have no specific timeframe in mind for Yesod 0.9. As it stands now, it looks like the 0.9 release will involve almost no API breakage, which is a very good sign. But if you have any ideas you'd like to contribute, I'd recommend getting them in in the next week or two.

Michael

[1] http://www.yesodweb.com/blog/2011/4/announcing-yesod-0-8

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel