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.
Related
Is it possible to mark fields as read only in a .proto file such that when the code is generated, these fields do not have setters?
Ultimately, I think the answer here will be "no". There's a good basic guidance rule that applies to DTOs:
DTOs should generally be as simple as possible to convey the data for serialization in a manner well-suited to the specific serializer.
if that basic model is sufficient for you to work with above that layer, then fine
but if not: do not fight the serializer; instead, create a separate domain model above the DTO layer, and simply map between the two models before serialization or after deserialization
Or put another way: the fact that the generator doesn't want to expose read-only members is irrelevant, because if you need something exotic, you shouldn't be using the generated type outside of the code that directly touches serialization. So: in your domain type that mirrors the DTO: make it read-only there.
As for why read-only fields aren't usually a thing in serialization tools: you presumably want to be able to give it a value. Serialization tools usually want to be able to write everything they can read, and read everything they can write.
Minor note for completeness since you mention C#: if you are using a code-first approach with protobuf-net, it'll work fine with {get;}-only auto-props, and with {get;}-only manual props if all public members trivially map to an obvious constructor.
There is a pattern or term that is used to avoid codes like
myObject.fieldA.fieldB.fieldC
something like this. I forgot what this term is called. Can anyone let me know about it?
It violates the Law of Demeter, which states that code should only access its own local variables, parameters, and instance members.
It could be a case of of feature envy, where a class calls a lot of getters or accesses a lot of data from another class.
If these are really fields, they are poorly encapsulated (i.e., not behind a function), and any change to these fields forces you to modify all code that's using them.
Testing such code becomes hard, as you will have to mock not only fieldA, but also that's fieldB, and in turn that's fieldC.
I think you are trying to create a new object and add certain properties to that object. If that is the case then it's Builder design patten where you seperate the construction and representation.
If you are trying to call a certain field with the above shown code then your design is very poor. An object should store only it's own properties.
From the Tapestry doc I seem to understand that a field annotated with #SessionAttribute and a field annotated with #SessionState work in the same way, except that #SessionAttribute stores the value by name (and the name can be specified), which means that different instances of the same class can be stored, while #SessionState stores the value by type so storing different instances of the same class will not work, the new instance will always overwrite the old one (even if the two are different fields with different name and from different classes).
So it seems that #SessionState doesn't offer any advantage over #SessionAttribute, only limitations, but I'm probably missing something. I'm not able to figure out any case where using #SessionState could be more advisable than #SessionAttribute for any reason.
Are there such cases ?
#SessionAttribute is largely intended for some interop cases, where some other, non-Tapestry code (another servlet) is expecting the data to be stored using an explicitly specified name.
#SessionState's advantage is that the name is automatically determined from the type ... one less thing to care about, and more amenable to refactoring.
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?
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.