Skip to content
This repository was archived by the owner on Dec 19, 2018. It is now read-only.

Support full lambda expression parameters #53

Closed
schotime opened this issue May 15, 2014 · 7 comments
Closed

Support full lambda expression parameters #53

schotime opened this issue May 15, 2014 · 7 comments

Comments

@schotime
Copy link

It would be great if you could use lambdas in Razor, without just having the one Func<string,string> which takes one parameter item.

Here is an example syntax:

@Form.For(..., @=> builder {
        @builder.EditorFor(m => m.Name)
})

or

@Form.For(..., @=> (builder,i) {
        @builder.EditorFor(m => m[i].Name)
})

More info can be found here:
http://hammett.castleproject.org/index.php/2011/07/mr-3-update-castle-blade/

@yishaigalatzer yishaigalatzer added this to the Backlog milestone Jul 23, 2014
@yishaigalatzer
Copy link
Contributor

Thanks for reporting it, we are not quite sure what is the use case for this, and would appreciate if you can provide more use cases.

@schotime
Copy link
Author

No problems.

  1. Loops.
@foreach (var item in Model.list) {
    @Html.TextBoxFor(x=>x.List[i].Name)
}

The problem is that you don't have an "i" reference. so then you have to put a variable outside of it and increment it at the end, which becomes very ugly.

Instead this would be way better.

@Model.List.Each(@=> (i) {
    @Html.TextBoxFor(x=>x.List[i].Name)
})
  1. Context
    The only real way to provide context at the moment is to use a using statement that doesn't work for most cases and you have use the using statement which looses its meaning.
    We use a lot of html conventions and we have the ability to apply certain conventions for certain parts of the page. Some sudo code looks like this.
@Html.Form<UserInputModel>(@=>(builder, i) {
    @builder.Input(x=>x.List[i].Name)
}

This builder can then have the conventions applied to it for its scope and all Inputs might then have a particular class or what ever the convention may be. At the moment this may have to be stored in the context.Items collection then removed when a using statement disposes or something. Its much easier to close the

tag, at the end of the Form call.

Hope this provides you with some more context. This style of functional programming makes it super easy to do powerful layouts in Razor.

Let me know if you need and more info...or to test a spike or help out with the syntax or some dev.
Adam

@yishaigalatzer
Copy link
Contributor

Adam - Thanks for the info. Just to let you know where we stand at the moment with Razor.

We are working on another approach to improve Razor, which is where we plan to spend most of the time in the near future that will make razor more fluent by using what we call taghelpers. See #75 and similar bugs in the Razor and MVC Repos.

We will eventually get back to this, though we might also add the support for Generic helpers for supporting the strongly typed ViewComponents (which is related but not exactly what you are asking for here) aspnet/Mvc#612

@danroth27 danroth27 removed this from the Backlog milestone Aug 17, 2014
@danroth27 danroth27 added this to the Backlog milestone Oct 17, 2014
@schotime
Copy link
Author

schotime commented May 6, 2015

Hey guys,
Just wondering where we stand with this?
It seems Tag helpers might have worked but you can't pass variables to the nested context (unless i'm missing something) and view components are just method partials it seems.
Cheers,
Adam

@yishaigalatzer
Copy link
Contributor

As you can tell this is in the backlog milestone. That means post RTM.

@Eilon
Copy link
Member

Eilon commented Jan 9, 2017

Closing because there are no plans to implement this.

@Eilon Eilon closed this as completed Jan 9, 2017
@Eilon Eilon added the wontfix label Jan 9, 2017
@schotime
Copy link
Author

Boo.
Seems like razor has just become spark without the power.

@rynowak rynowak removed this from the Backlog milestone Dec 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants