The current request for action 'HighlightsIndex' on controller type 'HighlightsController' is ambiguous between the following action methods:
System.Web.Mvc.ActionResult HighlightsIndex() on type mne.Controllers.HighlightsController
System.Web.Mvc.ActionResult HighlightsIndex(System.String) on type mne.Controllers.HighlightsController

My theory, obviously wrong ... HighlightsIndex() and HighlightsIndex(System.String) are two different signatures; so I surprised at the ambiguity.

I'd assumed first invokation via the menu would be to HighlightsIndex() and then anything via the page would chose HighlightsIndex(string showHideALL).

Can anyone explain this?

        public ActionResult HighlightsIndex()  // Highlights Controller "Index"
        {
            // default is only display highlights marked as showHide == true  =. "show me"
            return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                           .Where(a => a.showFrom < DateTime.Now
                                    && a.showUntil > DateTime.Now
                                    && a.showHide).ToList());
        }
        public ActionResult HighlightsIndex(string showHideAll)  // Highlights Controller "Index"
        {
            if (showHideAll == "show")
            {
                return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                               .Where(a => a.showFrom < DateTime.Now
                                        && a.showUntil > DateTime.Now
                                        && a.showHide).ToList());
            }
            if (showHideAll == "hide")
            {
                return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                               .Where(a => a.showFrom < DateTime.Now
                                        && a.showUntil > DateTime.Now
                                        && !a.showHide).ToList());
            }
            if (showHideAll == "ALL")
            {
                return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                               .Where(a => a.showFrom < DateTime.Now
                                        && a.showUntil > DateTime.Now).ToList());
            }
            // default is only show
                return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                               .Where(a => a.showFrom < DateTime.Now
                                        && a.showUntil > DateTime.Now
                                        && a.showHide).ToList());
        }

How is this different from two Edit requests or two Create requests as shown in Movie database tutorial?

Thank you.

Gerry (Lowry)

Action methods cannot have the same name unless some other differentiator helps to disambiguate between the two. The two most common ways would be with [HttpMethod] and [ActionName] attributes.

In your case, a single method is fine. The string, when not present in the URL, will be passed in as null, and you can just check in the action method whether the value is null.

Thank you, Brad

bradwils:

Action methods cannot have the same name unless some other differentiator helps to disambiguate between the two. The two most common ways would be with [HttpMethod] and [ActionName] attributes.

Brad, how would I know this if I was not lucky enough to have you to mention it?  Please, can you point me to where this is documented? 

bradwils:

In your case, a single method is fine. The string, when not present in the URL, will be passed in as null, and you can just check in the action method whether the value is null.

Yes, it was working with just the "public ActionResult HighlightsIndex(string showHideAll)" form.

I added the "public ActionResult HighlightsIndex()" form because it seemed to make the code look cleaner.

Since I use many different programming languages, I sometimes mix things up.

From my imperfect understanding, I thought that "HighlightsIndex(string showHideAll)" and "HighlightsIndex()" are two different function signatures and therefore could not be ambiguous.  What did I miss here?

Good News, Bad News
----------------------
Here is the corresponding markup for "public ActionResult HighlightsIndex(string showHideAll)":

<% using (Html.BeginForm()) {%>
<select name="showHideALL">
<option value="show">display where show = true</option>
<option value="hide">display highlights where show = false</option>
<option value="ALL">display ALL highlights</option><input type="submit" value="Refresh Highlights list" />
</select>
<% } %>

<% using (Html.BeginForm()) {%>
<select name="showHideALL">
<option value="show">display where show = true</option>
<option value="hide", selected="selected">display highlights where show = false</option>
<option value="ALL">display ALL highlights</option><input type="submit" value="Refresh Highlights list" />
</select>
<% } %>

Thank you.

Regards,
Gerry (Lowry)

 Sorry Brad, the new forum editor mangles source code when I try to highlight it even though everything looks okay in "Preview".

<% using (Html.BeginForm()) {%>   

<select name="showHideALL">   

<option value="show">display where show = true</option>   

<option value="hide", selected="selected">display highlights where show = false</option>   

<option value="ALL">display ALL highlights</option><input type="submit" value="Refresh Highlights list" />   

</select>   

<% } %> 

Gerry

gerrylowry:

From my imperfect understanding, I thought that "HighlightsIndex(string showHideAll)" and "HighlightsIndex()" are two different function signatures and therefore could not be ambiguous.  What did I miss here?

There is "ambiguous to the language", which they are not, and there is "ambiguous to the routing system, which has to pick an action method based on the URL", which they are. A URL is not a method call, and therefore you can't just apply the same logic that your compiler can to pick between the two methods.

Since we don't have the compiler to help us, MVC enforces some rules about mapping URLs to action methods, and they have nothing to do with the parameters to those methods; rather, we rely on attributes to disambiguate the usage.

gerrylowry:

Bad News: because there is no selected="selected" the end user's selection does not persist.

I'm having a problem figuring out the correct way to pass this back to my HTML markup ...

Assuming you're using Html.DropDownList and SelectList, you need use the constructor of SelectList which lets you tell it what the currently selected item is, so that the renderer can render the "selected='selected'" properly.

gerrylowry:

Brad, how would I know this if I was not lucky enough to have you to mention it?  Please, can you point me to where this is documented?

Can you point to where it is documented that you can have method overloads without a disambiguator? :)

Every time there is a sample with method overloads, there is always an attribute accompanying at least one of the methods.  Being able to differentiate methods based on signature alone is something we looked at, but the end result is that the design would have been unimaginably complex and the behavior too unpredictable.  Which is a shame, since developers who are used to C# or VB are already familiar with this syntax. :(

bradwils:

gerrylowry:

Bad News: because there is no selected="selected" the end user's selection does not persist.

I'm having a problem figuring out the correct way to pass this back to my HTML markup ...

 

Assuming you're using Html.DropDownList and SelectList, ...

Hi Brad, I'm not using Html.DropDownList.

It's hand code html ......... I think the solution "could" be something like this but I've no idea about the correct syntax:

<% using (Html.BeginForm()) {%>   

<select name="showHideALL">   

<option value="show",<% if ~~~some condition A~~~ selected="selected" %>>

display where show = true</option>   

<option value="hide",<% if ~~~some condition B~~~ selected="selected" %>>

display highlights where show = false</option>   

<option value="ALL",<% if ~~~some condition C~~~ selected="selected" %>>

display ALL highlights</option><input type="submit" value="Refresh Highlights list" />   

</select>   

<% } %> 

I know how to get the value of showHideALL from  "HighlightsIndex(string showHideAll)";

I can not figure out how to send that value back to the "HighlightsIndex.aspx" so that I can somehow use as per the pseudo if statements above.

Sadly, Google is now very useful when search for words like "if".

Thank you.

Gerry

Hi Levi,

levib:

gerrylowry:

Brad, how would I know this if I was not lucky enough to have you to mention it?  Please, can you point me to where this is documented?

Can you point to where it is documented that you can have method overloads without a disambiguator? :)

Short answer:  no.      B-(

Almost every day, I get a small gain in my understanding.  Sometimes the MSDN library information is useful to me.  Often, it's way too sparse.

Examples:

  http://msdn.microsoft.com/en-us/library/system.web.mvc.actionresult.aspx

  http://msdn.microsoft.com/en-us/library/system.web.mvc.actionresult_members.aspx

Sometimes, if I'm lucky, I can read between the lines.

levib:

Can you point to where it is documented that you can have method overloads without a disambiguator? :)

I'm not suggesting silliness such as "you can not bake a cake with ASP.NET MVC".  Rather, I'm suggesting things that members of the ASP.NET MVC team take for granted but other developers do not yet understand.

levib:

Every time there is a sample with method overloads, there is always an attribute accompanying at least one of the methods.

Please compare, for example, the movie database tutorial* with my annotations at http://forums.asp.net/t/1401522.aspx.

  * Creating a Movie Database Application with ASP.NET MVC (C#)   http://www.asp.net/learn/mvc/tutorial-21-cs.aspx

Phil, the two Scott's, Rod, and others in your league do not need these annotations.  They are already etched in the experience fountain within your fine minds.  OTOH, the gerry lowrys of the world deeply need the kind of documentation that people in your league often know intuitively.

levib:

Being able to differentiate methods based on signature alone is something we looked at, but the end result is that the design would have been unimaginably complex and the behavior too unpredictable.  Which is a shame, since developers who are used to C# or VB are already familiar with this syntax. :(

Levi, I wish I understood the complexities that you mention here.  I also wish I understood the compilition process better.  In my 40+ years of programming, I've spent way too much time programming in way too many languages and way too little time programming in just one language.

I was blown away when the compiler told me that my two signatures were ambiguous because they did not look abiguous to me.

bradwils:

There is "ambiguous to the language", which they are not, and there is "ambiguous to the routing system, which has to pick an action method based on the URL", which they are. A URL is not a method call, and therefore you can't just apply the same logic that your compiler can to pick between the two methods.

Levi, Brad:  so, is the compiler actually somehow applying rules that are ASP.NET MVC rules to the compilation?

(I'm not certain, but, if my recollection is correct, it was "the compiler" that told me my two signatures were ambiguous.)

bradwils:

Since we don't have the compiler to help us, MVC enforces some rules about mapping URLs to action methods, and they have nothing to do with the parameters to those methods; rather, we rely on attributes to disambiguate the usage.

? does this mean that the attributes are communicating with the compiler to extend the compiler? 

Gerry

P.S.:  Levi, Brad, anyone ~~ please see my previous post to this thread.

I still can not figure out how to round trip the selected list value back to the "HighlightsIndex.aspx" so that I can somehow use as per the pseudo if statements in my previous post.

Any ideas? 

 OK, I'll take a stab at the showHideAll question.  I may not be understanding your intent, but as I understand it, you have a VIEW called HighlightsIndex.aspx (and possibly others).  You want your controller to return a view based on the selected item in the dropdown. 

Basically, your controller will get back the value of that select as a post value, which you can get from the Request, from the FormCollection, or from a custom object in the params via model binding (as normal). 

Once you ahve that value (e.g. string showhideall = form["showHideAll"].ToString(); ), you just use your own custom logic to map that to a string name of a view (switch statement, for example) and then pass that to the View function as the first parameter (e.g. return View (viewName, model); )

Is that what you were looking for?

gerrylowry:

? does this mean that the attributes are communicating with the compiler to extend the compiler? 

No, attributes don't communicate with anything directly, and definitely not the compiler (not other than when they get compiled, of course, since they're ultimately just classes themselves).  They're metadata that describe something about the type or function you're defining (class, struct, method, interface, whatever).

Something somewhere has to reflect on that type in order and look for that metadata and then take some action based on it.  This is why ActionFilters dont' get executed by regular unit tests; because it's the Controller class that looks for them as part of its Execute method and fires them off in the right order before and after your Action and Result get executed. 

Hope that helps,

Paul

Hi Paul ... regarding the "showHideAll" ... the first part works, the second part I need to figure out the syntax.  Let me explain.

First part:  my .aspx page has a hand coded dropdown list.  Plain old standard HTML.

A user selects the  "show hidden" option, and then the "submit" button.

My controller via a parameter, uses this button to return the correct view (thanks to help from Brad and you on the lamda syntax).

Problem happens here:

Second part:       before the .aspx page is returned to the end user, I would like to have three hand coded if statements that each reference the value that the end user selected before clicking submit.  Note: the page returns okay, it is the dropdown list selection that currently is not persistent.

<% using (Html.BeginForm()) {%>   

<select name="showHideALL">   

<option value="show",<% if ~~~some condition A~~~ selected="selected" %>>

display where show = true</option>   

<option value="hide",<% if ~~~some condition B~~~ selected="selected" %>>

display highlights where show = false</option>   

<option value="ALL",<% if ~~~some condition C~~~ selected="selected" %>>

display ALL highlights</option><input type="submit" value="Refresh Highlights list" />   

</select>   

<% } %> 

For an initial post, nothing would be selected but that's okay because my default controller condition (shown earlier in this thread) shows non-hidden only.  This is because on the first rendering of the .aspx, "showHideALL" is null.

Thank you.

Gerry

 ah, I see.  well, you can just use Response.Write to push out the string, or make yourself a helper (to clean up your view).  obviuosly you have to pass the data down to the view somehow, so I'll assume you have it in the viewdata dictionary.   But basically, something like:

<option value='hide' <% if (ViewData["showHideAll"] != null && ViewData["showHideAll"].ToString() == "hide") Response.Write("selected='selected'"); %> />

Like I said, due to the length of it, you might be better off using a helper, or possibly just using the Html.DropDownList, which handles that logic for you.

Hi Paul, thank you.  c. 40 years ago, I was programming assember for IBM System\360 mainframe computers.  That was so easy!  Very little magic.  A line of code was a a line of code (with a gazillion lines of magic microcode behind it that we did not need to think about way back when).

With ASP.NET MVC v1.0 there is overwhelming magic.  They'd be burning Phil Haack et al at the stake for sorcery if this was a few centuries ago.

Example:

public class HighlightsController : Controller
{
   // Create an ObjectContext instance based on ArticleDBEntities.
   // Initialize the ObjectContext.
   private ArticleDBEntities _db = new ArticleDBEntities();

I'm guessing that the innocent looking statement above somehow is likely a Coca-Cola dispenser:  put in your money, get what you want, never out of Coke:

public ActionResult HighlightsIndex(string showHideAll) // Highlights Controller "Index"
{ 
   if (showHideAll == "show")
   {
      return View(_db.ArticleSet.OrderBy(a => a.showFrom)
                           .Where(a => a.showFrom < DateTime.Now
                                        && a.showUntil > DateTime.Now
                                        && a.showHide).ToList());

From the above, if showHideAll == "show", magically a subset of _db.ArticleSet gets sent to the View for rendering by

                              <% foreach (var item in Model) { %>

What I do not understand syntax wise, is how to also pass the pair of values ("showHideAll","show") back to the View to use with the <% if (... statement.

paul.vencill:

<option value='hide' <% if (ViewData["showHideAll"] != null && ViewData["showHideAll"].ToString() == "hide") Response.Write("selected='selected'"); %> />

Why the "ViewData["showHideAll"] != null &&" part?  It seems unnecessary to me.

Thank you,

Regards,
Gerry (Lowry)

 Ah, I see your problem now...

Ok, so even though you have a model object, you can still attach arbitrary values to the ViewData dictionary if you like.  I like that technique for items like this that aren't really part of the model, but are necessary for the view to work as expected.  So in the controller you can just do:

if (showHideAll == "show")
{
     ViewData["showHideAll"] = "show";
     /* the rest of your logic as-is */

}

I do the null checking with the dictionary in the view by habit.  If you're certain that it'll never be null, then you can ignore it.  The problem is that if it *is* null, then writing ViewData["showHideAll"].ToString() will throw a null reference exception because you're trying to call a method "ToString" on a null value, which isn't allowed.

 >>Please, can you point me to where this is documented?

In the Controller class. 

Controller action methods respond to requests that are sent to the controller. Controller action methods have the following restrictions:

• Action methods must be public.

• Action methods cannot be static.

• Action methods cannot have unbounded generic type parameters. An unbounded generic type parameter has an empty parameter list. An unbounded generic type is also known as an open generic type. For information about unbounded generic type parameters, see the section "Unbounded Type Parameters" in Constraints on Type Parameters (C# Programming Guide).

• Action methods cannot be overloaded based on parameters. Action methods can be overloaded when they are disambiguated with attributes such as NonActionAttribute or AcceptVerbsAttribute.