I've just have a little curiosity about this two code.. Both of them is working but what is the difference?
Html.BeginUmbracoForm() vs Html.BeginForm()
The BeginUmbracoFrom method helps with determining the correct paths honoring the Umbraco routing conventions, for example you can give it a strongly typed Controller class and it creates the path to the surface controller. This also allows you to refactor more easily
Html.BeginUmbracoForm<TestSurfaceController>("PostVals")
It has a bunch of different overloads, check them out here
Related
I've been trying to implement a Front Controller on a VBScript (ASP Classic) based system for a couple of days. I come from a ASP.NET MVC and Java background, where MVC implementations are kind common and mostly done by existing frameworks. On VBScript, however, there's almost nothing done in this area, so it is the reason why I'm trying to do it by myself. I used this and this article as a guide on how to implement it.
I believed at first that I'd need to define some constant parameters for each request, so I created 3:
class_command 'which command responsible to execute the correct class handler
action 'which method of the class handler to execute
action_params 'which parameters the action will need
Next, I defined a generic controller handler for treating the request:
Public Function Controller_Handler(action_params)
Its task is to extract the constant parameters (class_command, action, action_params) and treat any errors (I'll add later a filter to process it) that might come like absence of the constant parameters or authentication problems.
But soon I realized a problem: how will the handler know which command to call, since the request is a string? I can't simply converting it to class using reflection, because VBScript (I think) doesn't have a reflection library or built-in feature.
So I thought I could create a Switch Case like this:
Select action_Params.Item("action_params")
Case "command_A"
' Call Command A
Case "command_B"
' Call Command_B
.
.
.
Case "Command_X"
' And so on
End Select
But that would kinda procedural way to do it. Next I thought of creating a XML file which would map all the commands and other stuff.
So my question is: is this a good way of implementing a Front Controlller pattern, considering VBScript limitations? If not, could you provide a guidance (hopefully with some example, even a simple one) on how can I do it?
Moving from classic to .net/mvc I can share what I did in classic asp to try to emulate this behavior as closely as possible without making it too much of a maintenance issue.
Using URL Rewrite in IIS are my routes. I usually just make one route and direct/rewrite all inbound requests to one controller.asp page to simplify things and not have a bunch of rules and controller redirects directly in my URL Rewrite settings for maintaining it easier (for me).
Using Request.ServerVariables("HTTP_X-ORIGINAL-URL") in controllers.asp you can grab the actual URL that was entered, which return something like.. /real/url
In controllers.asp programatically call the view based on the entered url using Server.Execute("view1.asp")
I have one class file called routes.asp that is included in each model/class file, and helps me gather the URL properties oRoute.GetPath_FirstDirectory() and so on. The model/class file then uses this data to create its property values that can be consumed by the view. Using CLASS_INITIALIZE in each model/class to populate itself from the route/url, or it could also be done directly in the view.
In the respective view I include my class/model file (if even needed) using <!--#include file="class.asp"--> then simply open Set Model = new cModelClass to initialize and start using it in the view. I don't include the class in the controllers.asp because the view will not inherit any of the variables from controllers.asp when using Server.Execute() to the view. So I include it directly in the view.
Error handling can be at multiple levels here, but ideally its in the controllers.asp. Specific error handling is usually at the actual model/class CLASS_INITIALIZE to avoid redundant use of the class in the controller, since it's already going to be initialized in the view.
Now this is not exactly what goes in in .Net mvc, but it's the best way I've come up with, and easiest to maintain for me. Maybe others have other implementations, but this is mine and solely based on my experience. And so far, it's been working out pretty well.
Playing around with the Web.API 2.0 stuff- in particular Attribute Routing. The docs state that you can have attribute routing AND the 1.0 routing by convention... but these two don't seem to play that well together. For example, given these two methods:
public override HttpResponseMessage PutModel(SampleForm form)
[HttpPut("approvesampleform/{form}")]
public string ApproveSampleForm([FromBody]SampleForm form)
While I can call http://localhost/api/sampleform/approvesampleform just fine, a PUT to http://localhost/api/sampleform/ generates a Multiple actions were found that match the request error.
Is there any way that if a method is marked with the attribute routing it is ignored by the convention? This would be ideal... but I don't see any way to accomplish this in the docs.
Note: I don't see a asp.net-web-api-2 tag. Perhaps someone with more than 1500 rep can create it?
Right, RC (Release Candidate) did not have the logic where conventional routes cannot access attributed controller/actions. This change came post-RC. The scenario you are trying would work fine in post-RC bits.
Probably the docs you mentioned aren't very clear, but I think they mean that you could have attributed and convention based controllers work side-by-side and not particularly about mixing both attributed and conventional semantics in the same controller.
For time being you could probably use only attribute routing for your controller mentioned above.
We have been using ExtJs for a long time, and now, with the advent of MVC pattern in it we are facing a critical question of whether to use it or not in the times ahead given the approach we had been following so far.
In our application, we have similar screens, like 40 similar screens for generating the reports and so on. These report screens would be having a form with buttons - PDF, CSV, EXCEL. All the buttons would be having same functionality at every screen, that is, submit the form to a url and generate the specific report.
The approach which we had been following was to create a custom class, say reportscreen class, which extends the window class of ExtJs.
This custom report screen class would already have buttons with their handlers defined (given the fact that the functionality is similar for them for all the screens) and will also have a form present with a function setFormItems(). Any instance of this class would provide the items for the form using setFormItems() and the url for generating the report.
This approach not only helps us in reducing the development effort to a great extent, but also allows even a new member of the team to use the class & create a new screen.
Now comes in MVC, the most advised pattern, and the approach shared above is definitely not as per MVC pattern. But then, do we need to really move to MVC pattern here?
Using the above approach, we are not only able to save the effort, but also have a greater control over things.
The purpose of asking this questions is to know about the exact advantages we shall get if we implement the above scenario using MVC pattern and move away from our current approach.
Thus, what extra things would MVC bring to the table in the context above? And also, what would be the best way to implement such a thing in MVC pattern?
Thanks for any help in advance.
Do you need to use MVC? No. Assuming you've already got a structure that works well for you, if it's not broke, don't fix it. If you were starting a new project I'd recommend using MVC, but I wouldn't refactor a whole bunch of code for the sake of it. If you did use MVC, you would follow a similar approach. You'd have a base view class where you dynamically push on the items in the subclass. You'd have a base controller to handle all the custom events, then subclass controllers to implement custom functionality on a "per module" basis.
It's hard to explain the advantages of using MVC to someone who had no experience with it. As someone who developed with both ExtJs 3 and 4 (with MVC), I think one of the greatest advantages of MVC is that it forces you to think right - whether you want it or not, using MVC is likely to result in code base that is more reusable and better encapsulated. But if you boys and girls are good programmers/designers, this will be the case anyway.
If you do choose to move to MVC, I believe that the main change will be in that now instead of handling user interaction within your custom class, you will have a single controller to do the same job - leaving your custom class to realize the view only. Controllers in ExtJs4 are global - meaning that the same controller may control 40 similar views. So no duplication of controllers here.
It's important to mention that even within an MVC design you will find non-MVC code. For example, I have a custom record editor which is a form - the component knows how to handle user actions and update the records accordingly (the form is not submitted as it's mostly dealing with associations). This component takes the equivalent role of both the controller and the view within an MVC design. It seems to me more than reasonable to encapsulate things this way, rather than split this to a view and a controller. But the (non-reusable) user screens are implemented using MVC. So maybe just another reason not to rush to MVC.
While I agree with Evan that if it aint broken don't fix it, had I been your development leader and given time and money is not an issue, I would actually request the gradual migration to MVC - overall I think that 3 years down the line you won't regret this decision. I would at least attempt it.
When ExtJs 4 came out I scraped 2 months of work to rewrite from scratch a system using MVC - I don't regret this for a second now (I did at the beginning, but not for MVC - rather for the amount of bugs in the early versions of 4).
I'm building a site using CodeIgniter that largely consists of static content (although there will be a relatively small CMS backend, and there's code to handle localization/internationalization based on the domain used to access it). Typically, in a situation like this, I'd use a Pages controller that is in charge of rendering static content, but as there are a fair number of pages on the site (30+) it'd quickly end up containing lots of methods (assuming one per page).
Should I break my Pages controller into multiple controllers (that perhaps inherit from it) according to different sections of the site? Should I organize methods differently in the Pages controller? What's the best practice here?
Thanks!
Justin
I'd say split your controller into multiple. Not only it becomes easier to find whatever you need to work on in the file, probably there is a relation between the methods that "belong" to the same section. The end result is a more organized project,
Alternatively, why not have one single method that serves a static page, and work out which page to serve based on url ($id)? You'd have to play with CI routes a bit, in order to still have "site.com/pages/static_page_x" instead of "site.com/pages/view/static_page_x", but if you have a consistent way of accessing your static pages, it would save some typing, give you a way of adding new pages without touching the controller code, and might also come in handy if you want to apply to all the static pages something that you didn't think you'd need before.
Why dont you try to use a helper to detect your URL with the base_url() method and then process it. set a session variable to define the language in the controller...
When using the MVC pattern, should I implement a seperate controller for each view?
Create a new one if you need to. Don't if you don't.
Patterns are not about data structures, they're about organizational patterns among communicating components. If the same controller is appropriate for more than one view, great - especially if you can use it without modification.
If you have to change it, then you have a case for two separate controllers. If there is shared code between them, then consider moving it to another class - either a base class or (my personal preference) shared via aggregation.
The easiest way to think about MVC is a command-line program. The program is the Model. The Controller is STDIN. The View is STDOUT.
I believe there is no 'the' MVC pattern. There are almost as many MVC patterns as there are users of a MVC architecture. That being said, in my opinion, the answer to your question is 'no'.
I use to implement a controller for each module of my application, not for each view. A controller can call methods of other controller. I'm not sure if this is the better way to do it, but I think It's working well for me.
the idea is to separate/decoupling M, V and C, its not a problem if you want a single controller control multiple view, as long as the view and controller is decoupled