On 5/30/11 4:54 PM, Simon Michael wrote:

I sent some experience notes on these earlier today, but it doesn't seem to want to show up on this list and I got no bounce. Let's see if this one gets through ?

Ha! Quickly, now: (Fourth attempt to cc web-devel .. moderator, please reject the previous if they show up in your queue) Hi all, if you watch the hledger repo or #ledger irc channel, you'll have noticed that hledger-web was upgraded from yesod 0.6 to 0.8. Also I adopted the organization of yesod's scaffold template app, then simplified that in a way that I like, and finally moved all the inline hamlet templates to files (in hledger-web/.hledger/web/templates). I updated the hamlet syntax by hand; if I did it over, I would try harder to move to files first and then use the conversion tool provided by hamlet. For interest, all this took about 20 hours. Learning yesod, it sometimes feels over-intricate and obstructive (like when learning haskell..) However all the problems I've hit so far had solutions, everything has its place and once you fit the pieces together it all works really well. And all the necessary pieces exist. And many of them have great documentation. BIG thanks to Michael and the yesod team! I'm still learning how best to do things but developing the web app has become quite pleasant - I invite you to join in and build some really useful financial uis. Here are some notes on running the app: - The default build, aka yesod's "debug mode", reacts immediately to changes in static files and lucius/cassius/julius templates, but not hamlet templates. To see hamlet changes you need to also touch the affected hs files (or all of them) and rebuild. Or, use "yesod build" which touches the hs files for you (but doesn't work for me on mac yet.) - "yesod devel" runs the app in "devel mode", which should quickly rebuild and restart when any template or code file changes. I haven't got this to work yet ("Testing files.." repeatedly, nothing running) but this will be the way to go. - The wai-handler-devel package provides an alternate (deprecated ?) devel mode, which reacts to code changes (but not hamlet changes, so touch the hs files for those). I heard it's slower than yesod-devel but it's quicker than a normal rebuild/restart. I've got it working with some hardcoded values, let me know if you need that code. - The "production mode" build (cabal configure -fproduction) has all templates embedded. It still needs to serve the static files from disk though, so my write-out-files-on-startup hack is still needed (see EmbeddedFiles.hs). We'll probably figure out how to embed the static files too, and then production mode won't need anything from disk. Next steps: now it's easier to move the web ui forward, and I've been forming some plans (see http://twitter.com/#!/simonkwmichael/status/74966725057191936). FYI http://demo.hledger.org will keep running the latest release, for new visitors, and there's now http://demo.hledger.org:5001 which runs directly out of the trunk repo; this will be the place to preview and experiment. Finally, a random brainstorming question: I'd like to be able to push a button to save the current filtered view as a named favourite, and link these in the navigation area for quick access. What's the best scope for these "canned reports" - current (top-level) journal file, current directory, current user, ... ? And related but orthogonal: where to store them - embedded in the journal, saved in a separate db (using yesod's persistent), attached to the authenticated user's settings, ... ? Best, -Simon

On Tue, May 31, 2011 at 7:39 AM, Greg Weber wrote:

On devel mode- I have contacted the maintainer of the Shaker package in hopes of getting it to build with ghc7 so that using Shaker can be better investigated- it seems to already take the approach that we want, so it may have already solved some of our problems. I have also requested a cabal-dev library api (instead of just a command line interaction), which would make it easier to use cabal-dev in development mode.

Wow, I didn't realize how much Shaker looks like exactly what we need. Good find!

As for storing rendered web pages- if you are displaying a link to them it seems that you need a database entry. This kind of entry doesn't seem like it makes sense in an hledger journal unless there is a section for configuration. I don't know if you already have config files- seems like it could be there. Otherwise a sqlite database could be used. Normally database entries point to external files rather than embed the file directly for performance reasons that may not concern you. An approach for external files could be a directory structure within a config directory. I think the community is in need of some re-usable file attachment code that makes it easy to save a file and switch between the local file system or Amazon S3, etc.

That *does* sound like a very good idea. If anyone's interested in undertaking something like this, let me know. I think Aristid's aws package[1] in particular would be good for the S3 backend. Michael [1] http://hackage.haskell.org/package/aws

On Wed, Jun 1, 2011 at 11: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). 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. 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. 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.

out of curiosity, which frameworks have you worked with that have some or all of these features (particularly the complicated validation)?

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

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

-- -barkmadley sent from an internet enabled device

Hi Justin, It is great to have feedback from an F# perspective. For custom form design, do you just want a different html structure (paragraphs instead of table rows)? If so, it is easy enough to create a new form renderer for a different structure. Easier css manipulation should help to design custom forms. It seems that the main problem would be if you want to insert some extra structure, like a paragraph, in between some form fields. You can build custom forms with the monadic form builder, but it doesn't handle error propagation automatically. We should see how your example translates here. As another example of validations, Rails supports complex validation logic by placing it entirely in the model instead of the form (but it gets fed back to the form). There is at least one project now to extend that validation logic to the client side. In Rails, like the F# example, it is easy to build custom forms because they are placed in your view. However, this along with Rails mass attributes updates (assign every form field to the model instead of listing out every attribute to assign) is a major cause of security problems- now you have to block a malicious user from submitting fields that you didn't want to expose in your form. By building the form outside of the view, we automatically have a data structure that determines which fields can be assigned. I didn't see a full controller example in your F# code- how do you securely update your model? Thanks, Greg Weber On Wed, Jun 1, 2011 at 6:57 AM, Justin Greene wrote:

The custom form design and variable length list stuff is default asp.netmvc.

The validation stuff I ended up writing myself using F# quotations, it goes a couple steps farther than what I even mentioned as it converts the F# to javascript so you get server side validation and client side validation for free. Here's the github project: https://github.com/jgreene/FSharp.Javascript.Mvc and you can read more about it here: http://justsimplecode.com/

https://github.com/jgreene/FSharp.Javascript.MvcThere is not much documentation, and there is some complexity to setting up a framework to do something like this, but it's very doable.

On Wed, Jun 1, 2011 at 8:44 AM, Mark Bradley 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

...

around auto generating tables (if both are possible then of course the later can be used). 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. Validation: Complex validation scenarios should be simple and should fit into the normal validation pipeline. An example would be validating

...

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

On Wed, Jun 1, 2011 at 11:32 PM, Justin Greene wrote: based that if the

...

types of projects I do. If you need any more details/clarification I'd be happy to help.

out of curiosity, which frameworks have you worked with that have some or all of these features (particularly the complicated validation)?

...

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

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

-- -barkmadley sent from an internet enabled device

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

Hi Justin,

From what I can tell, the form/view model is roughly the same as building up an applicative form. If you build a custom form, you have to declare a field both in your form/view model and in your view, which is the kind of insecure duplication we would like to avoid when possible.

You can already create custom form layouts with the monadic form creator. Honestly I haven't used the new version at all or the old version for anything that needs validation, so I am not sure if you can insert error messages for fields. Conditional validation logic is not really supported server side, let alone client side. There are already several javascript generators for haskell. At any rate it is probably a similar task to implementing reflection, quotation, and javascript generation in F#, except that more needs to be done at compile time. We value your opinions. These are definitely features that I have needed on occasion. We just have to think about how they best translate to haskell, and how they fit into our limited time to make Yesod better. Greg Weber On Wed, Jun 1, 2011 at 8:26 AM, Justin Greene wrote:

Hi Greg,

For custom form design, do you just want a different html structure

...

(paragraphs instead of table rows)?

No, having an auto generated structure will never be able to handle the various requirements I get for forms. Having a system that auto generates scaffolding for you is a nice to have, having a system that only gives you auto generated forms is about the same as painting yourself into a corner.

For security in asp.net mvc you would have a form model, or what is commonly referred to as a view model. This model only has fields that you wish to be exposed. On form submission you would then move the desired fields to your domain/data model (this can be simplified by using a project like automapper which uses reflection and configuration to copy fields). The validation is also associated with the form/view model.

I didn't see a full controller example in your F# code- how do you securely

...

update your model?

The full submit action sample is generally very small due to a lot of the plumbing of asp.net mvc being hidden.

In F# it would look something like this.

type MyController() = inherit Controller()

member this.MySubmitAction(form:MyFormModel) = if ModelState.IsValid = false then base.View("MyFormView", form) else let domainModel = moveFormModelToDomainModel form save domainModel redirectToThankYouPage ()

By the time you enter the above method you will already have your form validated with the ModelState being populated with your validation errors.

I don't really believe that a lot of this is transferable to haskell, due to the lack of reflection and general constraints that haskell puts on you. I've theorized about how I would go about creating much the same thing in haskell, but to get the javascript conversion you'd have to write a template haskell -> javascript converter (which would probably be quite a bit of effort). For custom layout you'd probably also have to use template haskell to specify where you want form fields to render.

Anyway, these are obviously just my opinions and you can take them or leave them. I'd really love to be able to use yesod and haskell for the type of work I do, but I can't see doing so until it has what i consider a robust forms solution that doesn't add a lot of friction to my development.

On Wed, Jun 1, 2011 at 9:58 AM, Greg Weber wrote:

...

Hi Justin,

It is great to have feedback from an F# perspective.

For custom form design, do you just want a different html structure (paragraphs instead of table rows)? If so, it is easy enough to create a new form renderer for a different structure. Easier css manipulation should help to design custom forms. It seems that the main problem would be if you want to insert some extra structure, like a paragraph, in between some form fields. You can build custom forms with the monadic form builder, but it doesn't handle error propagation automatically. We should see how your example translates here.

As another example of validations, Rails supports complex validation logic by placing it entirely in the model instead of the form (but it gets fed back to the form). There is at least one project now to extend that validation logic to the client side.

In Rails, like the F# example, it is easy to build custom forms because they are placed in your view. However, this along with Rails mass attributes updates (assign every form field to the model instead of listing out every attribute to assign) is a major cause of security problems- now you have to block a malicious user from submitting fields that you didn't want to expose in your form. By building the form outside of the view, we automatically have a data structure that determines which fields can be assigned. I didn't see a full controller example in your F# code- how do you securely update your model?

Thanks, Greg Weber

On Wed, Jun 1, 2011 at 6:57 AM, Justin Greene wrote:

...

The custom form design and variable length list stuff is default asp.netmvc.

The validation stuff I ended up writing myself using F# quotations, it goes a couple steps farther than what I even mentioned as it converts the F# to javascript so you get server side validation and client side validation for free. Here's the github project: https://github.com/jgreene/FSharp.Javascript.Mvc and you can read more about it here: http://justsimplecode.com/

https://github.com/jgreene/FSharp.Javascript.MvcThere is not much documentation, and there is some complexity to setting up a framework to do something like this, but it's very doable.

On Wed, Jun 1, 2011 at 8:44 AM, Mark Bradley 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

...

around auto generating tables (if both are possible then of course the later can be used). Variable length lists: It should be possible to add form elements on

...

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. Validation: Complex validation scenarios should be simple and should fit into the normal validation pipeline. An example would be validating

...

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

On Wed, Jun 1, 2011 at 11:32 PM, Justin Greene wrote: based the that if the

...

types of projects I do. If you need any more details/clarification I'd be happy to help.

out of curiosity, which frameworks have you worked with that have some or all of these features (particularly the complicated validation)?

...

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

...

...

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

...

...

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

...

...

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

release likely per 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

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

-- -barkmadley sent from an internet enabled device

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