There are a set of common pages that I want to use in multiple projects. Hence, I want to build a class library with those pages. The problem is I am not able to pass objects using NavigationService.Navigate(new Uri("/Common;component/SomeName.xaml", UriKind.Relative)); method.
I know I can pass querystring. What I would like to know is...
Is there any limit to the number of strings you can pass in the querystring?
Is there any length limitation of the querystring?
Or better still,
Is there a better way of passing objects from an application to the pages inside a different class library?
About the question "is there a better way". In addition to the solution you've mentioned some people like to use the app's state to pass parameters between objects. For example:
PhoneApplicationService.Current.State["parameter"] = param;
var parameter = PhoneApplicationService.Current.State["parameter"];
Another option is to use a shared class. With complex objects I find it often easiest to use a static public member in a class which can be accessed from both of the projects.
Note that if you choose to use the query string navigation, some special characters in the query string may cause problems. If you can't control the content of the data which is passed between the pages, the shared class -solution is probably better for you. For example in one of our applications we're passing a web site's name in the query string. There's situations where those names can contain a '&' -character (like H&M) and if it does, the query string will break.
When navigating, if building the query strings gets cumbersome, you may check out the Caliburn.Micro and the Uribuilder class in it. It allows you to navigate with a rather nice (and fluent) syntax:
navigation.UriFor<CandidateDetailsPageViewModel>()
.WithParam(x => x.CandidateId, candidate.Id)
.Navigate();
After navigation, the TryGetValue-method can be rather useful when parsing the parameters:
String parameter;
NavigationContext.QueryString.TryGetValue("Parameter", out parameter)
More details for NavigationContext.QueryString is available from MSDN.
To answer your questions:
No there is no limit to the number of strings you can pass in a qyerystring
I believe the answer to this may be yes. I believe the standard is to have a url of < 2000 characters
For small items I usually just pass a query string to my pages. For more complex cases I have a shared static Domain class that both libraries reference. Then I can just access this variable statically really easily.
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.
If I want to handle many parameters from for example a web request and pass it between classes (layers) - what is the preferred way?
I know it is easy to pass optional numbers of parameters through the constructor as a map.
I can also pass a map directly and if the keys match the receiving objects property names it should work in a similar way
Or I could just pass the map and then instantiate for example domain classes from that
I could use a special class as data carrier with given number of properties
I have a domain class (not database domain but business domain) that needs data from the user interface.
What is the best way to pass data through the layers and how do I know that all required data is being passed if using a data structure - like a map - with key values? If I would have a more static constructor with a given number of parameters, then I would know that the parameters are being passed. But how do I secure this when using a more dynamic approach? With unit tests?
Well in Grails command objects are an excellent choice. You can pass them up to various layers without issues. They are pretty analogous to domain classes, only without the whole persistence functionality.
Otherwise I would recommend using plain old Groovy classes (POGOs). Groovy allows you to keep your code very short (compared to Java and many other languages as well) and offers very handy transforms for common design patterns you might need (e.g. Canonical, Immutable, IndexedProperty, DelegatesTo...).
Compared to command objects POGOs do require you to write e.g. validation code by yourself, but this can be as simple as
boolean isValid() {
name && lastName && countryCode in ['US', 'CA']
}
You can keep static factories in a POGO to help you construct them in the various circumstances. Plus you can define more than one class in a file so you can keep the POGO code wherever it makes most sense. I would definitely prefer this approach to simple maps because the code is better encapsulated, POGOs can be unit tested & documented.
It seems as though
Parse.Query("_User")
is canonical, but Parse.Query("User") and Parse.Query(Parse.User) work too. Are there differences in behaviour between these? Any reason besides consistency to stick to one over the other?
Parse.User seems nicest, since it doesn't rely on a string literal, but it's not what I've seen in the docs.
Using Parse.Query(Parse.User) is the preferred method, the actual class name for the internal User/Role/Installation classes are _User/_Role/_Installation, so you can use them.
Using Parse.Query("User") will not actually query the internal User class, and will instead look for your own User class. You can try by creating a new User object using "User" as the class name, and you'll see two User classes in your Data Browser, one with the special icon and one without.
Is there a Web API equivalent to the MVC ActionMethodSelectorAttribute?
My specific purpose is this: I have, for example, a ResourceController and when I POST to the controller, I'd like to be able to receive a single resource (Resource) or a list (IEnumerable<Resource>).
I was hoping creating two methods with different parameters would cause the deserialization process to do some evaluation but this doesn't seem to be the case (and frankly, I don't think it's efficiently realistic with the combination of content negotiation and the fact that many data formats, like JSON, make it difficult to infer the data type). So I originally had:
public HttpResponseMessage Post(Resource resource) {...}
public HttpResponseMessage Post(IEnumerable<Resource> resources) {...}
...but this gets the "multiple actions" error. So I investigated how to annotate my methods and came across ActionMethodSelectorAttribute but also discovered this is only for MVC routing and not Web API.
So... without requiring a different path for POSTing multiple resources vs. one (which isn't the end of the world), what would I do to differentiate?
My thoughts along the ActionMethodSelectorAttribute were to require a query parameter specifying multiple, which I suppose is no different than a different path. So, I think I just eliminated my current need to do this, but I would still like to know if there is an equivalent ActionMethodSelectorAttribute for Web API :)
I haven't seen a replacement for that method (there is an IActionMethodSelector interface but it is internal to the DLL). One option (although it seems like it might be overdoing it) is to overload the IHttpActionSelector implementation that is used.
But changing gears slightly, why not always expect an IEnumerable<Resource>? My first guess is that the collection method (that takes IEnumerable<Resource>) would simply loop and call the single value (just Resource) function?
I'm trying to make a dynamic menu function in an ASP.NET MVC 3 website - and I'd like to know if there is a built-in way to get all of the Controllers and Actions at runtime?
I realize that I can use reflection to find all public methods on my controllers, but this doesn't exactly give me the relative URL that I should put in the <a href="..."> tag.
Also, I'm going to be decorating some of the 'actions' with filter attributes that dictate whether the current user can see/goto those pages. So it would be best if I had access to the filters as well so as to be able to call the IsAccessGranted() method.
What are my options? What is the best option?
I actually just did that two weeks ago.
var q = from type in Assembly.GetExecutingAssembly().GetTypes()
where type.IsClass && type.Namespace != null && type.Namespace.Contains("Controller")
select type;
q.ToList().ForEach(type => doWhatYouNeedToDo(type)));
if you are using T4MVC, then this script will return double entries. To avoid this, work with
&& !type.Name.Contains("T4MVC")
In the method doWhatYouNeedToDo() you could transform the Type object into a DTO that suits your needs and add work further with it.
As far as your dynamic menu is concerned, you could use the MvcSiteMapProvider and implement your own dynamic sitemapprovider with it, so you are no longer bound to the static sitemap xml file.
But reflection is quite slow in .NET, so you might want to store representations of your controllers and method in the database.
There is no built in mechanism in MVC to enumerate over all of your controllers and actions. You would have to use reflection to inspect all the loaded types and look at their methods and the associated attributes. Of course this is assuming that you are using the default reflection-based action dispatching mechanism. Since MVC's pipeline can be replaced in a number of places its easy to inject a system for invoking action methods that is not based on CLR classes and methods. But if you have complete control over your application than you life is easier.
Try TVMVC. You'll still have to use reflection, but the t4 templates will generate a class that's easier to iterate over.