Is it considered bad practice to pass whole objects to meteor methods and should I stick to just passing the ID, and then using the passed Id to fetch the document from within the meteor method instead?
The main consideration here is security: if your method is expecting to be passed an object, a Meteor-savvy user can call it from the console, passing any object of their choosing as the argument, whether it's in your DB or not, thereby bypassing any DB schema/validation you have set up. In order to avoid that, you need to be looking the object up in the DB in your server-side method code, which rather defeats the point of passing in the whole object rather than just the id in the first place. So, in summary, pass the id rather than the object.
If the user should be able to call your method with an arbitrary object, then I'd argue that you absolutely should be passing the whole object rather than just the id as otherwise you're necessitating storing a document in the database purely so that you can call a method on it, which is ugly. However, I think that would be a fairly unusual situation.
Related
I need a help for while creating the collection the below error is came in server console.How to solve the error ?
Error:
Warning: creating anonymous collection. It will not be saved or synchronized over the network. (Pass null for the collection name to turn off this warning.)
TLDR: you need to provide a collection name as an argument when you create a shared collection.
In most cases, you want to provide a name as a parameter when you define a collection:
Docs = new Meteor.Collection('docs');
When you don't, you create anonymous collection:
Items = new Meteor.Collection();
In the first case, the collection is shared and synchronized between client and server, and the name you've provided is used as a table name in order to store the collection in Mongo.
Anonymous collections are local in the place they've been created. Their contents are never synchronized. Therefore, even if you create such collection in a piece of code that will be run on the server and on the client, those two collections will be separate things: data created on the server won't be visible on client, data created on the client won't be visible on server, and both won't be stored in the database.
There are legitimate use cases for anonymous collections, mostly on the client side when you need to create some temporary data, but want to retain all the benefits of Minimongo and reactivity. However, it's one of those things that are needed rarely and you really do know when you need to do it. It's more probable that a beginner made a mistake and forget to provide the collection name when he wanted to create a typical shared collection. Therefore, the system issues a warning to make sure that you really wanted to do what you just did.
Therefore:
If your goal was to create an anonymous collection, and you know what you're doing, don't worry about that message. It's just a warning, the code will be functional and do what it's told to.
If you wanted to create a normal collection, or are just starting out and don't know what's this all about, just add a parameter to your collection definition.
Skimming through the nodejs docs I see options objects being passed to configure features in the http library. However I don't see a quick way to access the original options that were used in a http.request(options, callback) call to construct a http.ClientRequest object, after the fact. Are original options available through the request object and not deemed private, or should I instead hold my own reference to the original options in case I want to use them later?
I assume the options are composited inside the http.ClientRequest object, but that could be wrong.
I could probably try going either way with this (dig into composited info, or pass around an external reference to it), but am new enough to nodejs that I want some sage advice first, to find out what I should do if the option object's available, and by using best practice.
You should always keep your own reference. Most of the time you have no way of telling what's going to happen to that object after you pass it to a constructor. Almost everybody leaves it alone, but some libraries/modules may have side-effects on it. For example, you may see source code doing:
options.foo = options.foo || 'bar';
...modifying your object. So you may even have to clone your object before passing it to a constructor if you want to keep a reference to it.
As for ClientRequest in particular, it doesn't hold a public reference to the options object, but it has properties that match some of the options like req.path or req.port.
Basically I want to make my script service only serialise properties that are not null on an array of object I am returning... So this..
{"k":"9wjH38dKw823","s":10,"f":null,"l":null,"j":null,"p":null,"z":null,"i":null,"c":null,"m":0,"t":-1,"u":2}
would be
{"k":"9wjH38dKw823","s":10,"m":0,"t":-1,"u":2}
Does anyone know if this is possible?
Basically the reason for this is because null values are for unchanged properties. A local copy is kept in the javascript that is just updated to reduce traffic to the server. Change values are then merged.
You can create a custom JavaScriptConverter class for the JSON serialization process to use to handle your object, and then put the necessary logic in the Serialize method of that class to exclude the properties that are null.
This article has a clear step-by-step discussion of the process involved in creating it.
You probably would not need to actually implement the Deserialize method (can throw a NotImplementedException) if you are not passing that type of object in as an input parameter to your web services.
I have an existing web application that uses EF and POCO objects. I want to improve the client experience by exposing some of my objects through WCF(JSON). I have this working fine but where I am unsure is how to handle derived objects(not sure if that is the correct term) or IEnumerable anonymous objects if you will.
Let's say I have 3 tables structured like so:
Templates
ID
Template
Groups
ID
Group
Instances
ID
TemplateID
GroupID
This is obviously a one-to-many type relationship. I have my navigation properties setup correctly and getting strongly typed object properties works great. However, how do I send serialized anonymous type object(s) over the wire. Like an object that sends all instances that are equal to groupid=1 and include the names of the template and the object.
Am I missing something or do I have to create another class object for WCF that would look like this:
WCF Object
InstanceID
TemplateID
TemplateName
GroupID
GroupName
I guess I could alter my tables to account for this but that seems wrong too. I know that IEnumerable objects can't be serialized and I know that throw away objects are probably not the way to go either. I want to do this the right way but I am not sure how to go about it.
Your suggestions are appreciated.
Regards
Based on what you're doing, I'd suggest looking at OData with WCF Data Services. You state that you want to be able to send all instances where the groupid=1 - OData is great at this type of filtering.
If you're want to stick with your current approach and not use OData, then my first question is why are you sending back anonymous types at all? You can do what you are seeking (all instances with a groupid=1) without sending back an anonymous type. In your select clause you just create new instances of your concrete objects rather than newing up anonymous types. If your query is really just filtering and not executing any meaningful projection with the selct to anonymous type, then I don't see any reason to send back your anonymous type at all.
I am building a site in which we are making moderate use of email templates. As in, HTML templates which we pass tokens into like {UserName}, {Email}, {NameFirst}, etc.
I am struggling with where to store these, as far as best practice goes. I'll first show the approach I took, and I'd be really excited to hear some expert perspective as a far as alternate approaches.
I created HTML templates in a folder called /Templates/.
I call a static method in my service layer, which takes in the following arguments:
UserName
UserID
Email
TemplatePath ("~/Templates")
Email Subject
Within the service layer I have my static method SendUserEmail() which makes use of a Template class - which takes a path, loads it as a string, and has a AddToken() Method.
Within my static SendUserEmail(), I build the token list off of the method signature, and send the email.
This makes for a quite long method call in my actual usage, especially since I am calling from the web.config the "TemplatePath", and "Email Subject". I could create a utility that has a shorter method call than the ConfigurationManager.AppSettings, but my concern is more that I don't usually see method signatures this long and I feel like it's because I'm doing something wrong.
This technique works great for the emails I have now, which at the most are using the first 3 tokens. However in the future I will have more tokens to pass in, and I'm just wondering what approach to take.
Do I create methods specific to the email needing to be sent? ie. SendNewUserRegistration(), SendMarketingMaterial(), and each has a different signature for the parameters?
I am using ASP.NET Membership, which contains probably the extend of all the fields I'll ever need. There are three main objects, aspnet_User, aspnet_Mebership and aspnet_profile. If it was all contained in one object, I would have just passed that in. Is there performance concerns with passing in all 3, to get all the fields I need? That is versus just passing in aspnet_User.UserID, aspnet_User.Email, etc?
I could see passing in a dictionary with the token entries, but I'm just wondering if that is too much to ask the calling page?
Is there a way to stick these in a config file of it's own called Templates.config, which has tags like -
<Templates>
<EmailTemplate Name="New User Registration">
<Tokens>
<UserName>
<UserID>
<Email>
</Tokens>
<Message Subject="Hi welcome...">
Hi {UserName}...
</Message>
</EmailTemplate>
</Templates>
I guess the main reason I'm asking, is because I'm having a hard time determining where the responsibility should be as far as determining what template to use, and how to pass in parameters. Is it OK if the calling page has to build the dictionary of TokenName, TokenValue? Or should the method take each in as a defined parameter? This looks out of place in the web.config, because I have 2 entries for and , and it feels like it should look more nested.
Thank you. Any techniques or suggestions of an objective approach I can use to ask whether my approach is OK.
First of all I would like to suggest you to use NVelocity as a template engine. As for main problem I think you can create an abstract class MailMessage and derive each one for every needed message (with unique template). So you will use this like following:
MailMessage message = new UserRegistrationMessage(tokens);
//some code that sends this message
Going this way you force each concrete XXXMessage class to be responsible for storing a template and filling it with the given tokens. How to deal with tokens? The simpliest way is to create a dictionary before passing it to the message, so each concrete message class will know how to deal with passed dictionary and what tokens it should contain, but you also need to remember what tokens it should contain. Another way (I like it more) is to create a general abstract type TokenSet and a derived one for every needed unique set of tokens. For example you can create a UserMessageTokenSet : TokenSet and several properties in it:
UserNameToken
SomeUserProfileDataToken
etc. So using this way you will always know, what data you should set for each token set and
UserRegistrationMessage will know what to take from this tokenSet.
There are a lot of ways to go. If you will describe you task better I think I will try suggest you something more concrete. But general idea is listed above. Hope it helps =)