search

NancyFx / Nancy

Lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono
http://nancyfx.org
MIT License
7.16k stars 1.47k forks source link

Nancy.ViewEngines.Razor.HtmlHelpers #1648

Open phillip-haydon opened 10 years ago

phillip-haydon commented 10 years ago

Sooooo @davidwhitney has created some helpers for Nancy/Razor, which can currently be found here:

https://github.com/davidwhitney/Nancy.ViewEngines.Razor.HtmlHelpers

He's put in a huge effort which is great.

I figured I would open this up for @NancyFx/owners and @NancyFx/most-valued-minions to discuss possibly pulling the main repo into NancyFX and making David an owner, and pulling the docs into the main docs, and basically adopting the helper library plugin.

It would be a huge bonus, I know a lot of people have asked for helpers over the last year or so.

Thoughts?

jchannon commented 10 years ago

Do we think this should be bundled with the Razor viewengine or as a seperate package? Just wondering what uses may say. Why do we need a seperate package to get HTML helpers? I'm fine with either TBH

phillip-haydon commented 10 years ago

I'm all for a separate package, I prefer opt-in.

Personally I would never use the helpers, I don't use them in MVC and I would never use them in Razor. So my personal opinion is that it should be opt in.

davidwhitney commented 10 years ago

For what it's worth - I'm easy! I think an additional library follows the current pattern in the framework - so it's no more of a leap than "oh I need a view engine"

jchannon commented 10 years ago

Just wondering those users that come from MVC etc may find it odd that they have Razor installed but when they type @Html. they don't see the extensions but then have to find out they need to opt-in??

davidwhitney commented 10 years ago

To support that - it'd help users fall into the pit of success, and it doesn't have any external dependencies, so it'd certainly be low-impact - just means more code in core assemblies. Don't have a real strong opinion. It wouldn't bother me that it was an additional library, but it is obviously easier if you're just expecting "mvc-like" behaviour.

jchannon commented 10 years ago

Yup its tricky cause helpers are built in with MVC/Razor but Nancy uses the opt-in approach

davidwhitney commented 10 years ago

The question "are HTML helpers core to using Razor" seems relevant.

They aren't core, but they are a huge help if you're doing UI driven mvc-style web things - which leads me to believe they're a web-framework level concern, rather than a view engine one. If as a consensus, the feeling is lowering the barrier to entry for doing web-ui-mvc-stuff is of higher importance - they should probably be in the core. Otherwise, they are optional add-ins. There's a good case for both.

So an issue of "accessibility to migrating users" vs. "framework design principles".

Which is more important?

jchannon commented 10 years ago

Lets leave @thecodejunkie to decide that one :laughing:

davidwhitney commented 10 years ago

Ha! Indeed!

philcleveland commented 10 years ago

Please take this with the knowledge that I am a complete newb in web dev. I haven't ever worked on a production site. It was a little frustrating/annoying when I typed @Html and didn't get intelliisense on my initial Nancy prototype.

From a pit of success stand point I think that having it part of the Nancy Razor ViewEngine assembly is a good thing. I can understand opt-in as well. The down side I see with the opt in solution is that it forces me to read documentation to find it. My typical workflow with new tech usually is to read as little doc as possible, attempt to use the tech (delightful if I can get ti to work without reading more doc), then go back and read the fine print if needed. Maybe that's atypical, but I am guessing not :)

Also consider that there is a lot of documentation out there for Razor, not Nancy razor....MVC Razor. Making Nancy's engine feel as close as possible means that you inherit a lot of free documentation.

What about a hybrid solution, which includes David's helpers by default, but also has an injection point to override with another set of helpers?

damianh commented 10 years ago

Nice work. Agree with pulling it under the umbrella). If it has external dependencies (other than Nancy releated) or will be released on a separate schedule then separate package, otherwise import. (I don't feel that strongly either way). On 6 Aug 2014 17:01, "Jonathan Channon" notifications@github.com wrote:

Do we think this should be bundled with the Razor viewengine or as a seperate package? Just wondering what uses may say. Why do we need a seperate package to get HTML helpers? I'm fine with either TBH

— Reply to this email directly or view it on GitHub https://github.com/NancyFx/Nancy/issues/1648#issuecomment-51346805.

jchannon commented 10 years ago

You might want to reopen it though :)

xt0rted commented 10 years ago

This past week I've been working on the exact same thing so this gets my vote to be pulled in.

I think it might be worth moving some of the stuff into Nancy's core even if the Html helpers themselves are in their own project. Things like the TagBuilder and RouteValueDictionary (I called this AttributeDictionary) could be useful across view engines and other add-ins.

My implementation was going to take this a bit farther though. I wanted the client-side validation and markup generators to be swappable. This way you could use the default ones that didn't do anything special or have ones for libraries like Bootstrap, Foundation, Parsley, or jQuery Unobtrusive Validation.

horsdal commented 10 years ago

:panda_face: Oops didn't mean to close it. Doh..

Deilan commented 7 years ago

Any news on the topic?

maxinfet commented 7 years ago

Is this still something that may get merge in Nancy proper? This would make using Nancy so much easier. When I first started using it I figured I was just missing something since I was using the Razor engine but couldn't use all the methods I was used to in the cshtml. I have gone back to Nancy a few times now and finally found this today. At the very least it might be worth mentioning in the documentation that the htmlhelper is not implemented. Mentioning the htmlhelper in the documentation will prevent people from spending lots of time trying to find a missing nuget package or checking their configuration.

I suppose I should say though that this project is still really awesome. I am using it for a web page for monitoring my UI automation on our virtual machines. This is really great since I know the web server is running from a logged in user who has a desktop instead of having to guess whether IIS will have access to run the UI automation. Thank you for the work on this.