What about coming up with some conventions?
So instead of:
[HttpGet]
public void Index() {}
[HttpPost]
public void Index(int id) {}
do something like:
public void Index() {}
public void Index_Get() {}
public void Index_Post(int id) {}
So if a GET request comes for Index we would execute:
1 - Index()
2 - Index_Get()
I'm proposing this because a lot of the times I tend to call Index_Get
from inside Index_Post because I'm still displaying the same view, do
you guys find this as well?
Also this makes it more clear I think.
Cheers
John
On Nov 19, 1:16 am, Henry Conceição <[email protected]> wrote:
> I see your point. The verb disambiguation is on the list.
>
> Cheers,
> Henry Conceição
>
>
>
>
>
>
>
> On Wed, Nov 17, 2010 at 10:24 PM, hammett <[email protected]> wrote:
> > I think so. There are semantics for PUT/DELETE, but browsers dont
> > support those verbs. So we usually accept POST for them using an oob
> > "method" parameter.
>
> > 2010/11/17 Krzysztof Koźmic <[email protected]>
>
> >> Would we ever want a single controller method to be accessible via more
> >> than one HTTP method?
>
> >> On 18/11/2010 9:00 AM, hammett wrote:
>
> >> What about this
>
> >> [HttpGet]
> >> public void Index() {}
>
> >> [HttpPost]
> >> public void Index(int id) {}
>
> >> The decision on which action to pick may be constrained by other factors
> >> (http verb in the example above). will we support overloading in this case?
>
> >> 2010/11/17 Henry Conceição <[email protected]>
>
> >>> Hi,
>
> >>> On my next step, I would like to approach the action data binding.
>
> >>> I see three distinct types of bindable parameters that we should support:
>
> >>> - simple form/querystring databinding
> >>> - complex form/querystring databinding (relaying on
> >>> Castle.Components.DataBinder)
> >>> - http context base object (context, request, response, session)
>
> >>> I'm not sure if we should support action overloading. Things can be
> >>> much simpler without it.
>
> >>> Any thoughts regarding this?
>
> >>> Cheers,
> >>> Henry Conceição
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Castle Project Development List" group.
> >>> To post to this group, send email to
> >>> [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected].
> >>> For more options, visit this group
> >>> athttp://groups.google.com/group/castle-project-devel?hl=en.
>
> >> --
> >> Cheers,
> >> hammett
> >>http://hammett.castleproject.org/
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Castle Project Development List" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group
> >> athttp://groups.google.com/group/castle-project-devel?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Castle Project Development List" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group
> >> athttp://groups.google.com/group/castle-project-devel?hl=en.
>
> > --
> > Cheers,
> > hammett
> >http://hammett.castleproject.org/
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group
> > athttp://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
