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

1 Jun 2011

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