I am developing a simple farming game backend using meteor.
So Server needs to check all players farm data and based on that for example increment
production:0
field each second if player has a farm.
What is the best way to do that ?
Should i use Meteor.setTimeout()
You should use Meteor.setTimeout if you don't manually want to bind fibers to the callback function.
Related issues:
What's going on with Meteor and Fibers/bindEnvironment()?
Meteor wrapAsync or bindEnvironment without standard callback signature
However, you can also use the native JS setTimeout but you will have to manually bind a fiber to the callback (if you aim to use for example Mongo) using Meteor.bindEnvironment or Meteor.wrapAsync.
Another interesting tool is Meteor.defer which is similar to Meteor.setTimeout(func, 0) and allows to execute code in the background. Beware of several layers of callbacks when mixing with Meteor.setTimeout.
Ans yet another tool when executing complex services in a method is this.unblock.
Applying these tools in an appropriate way will make your timer based update possible.
Related
I want to attach YUI modules synchronously.
Given the YUI modules are already on the page
When I run: console.log YUI().use('base').Base
Then I get `undefined`
However,
When I run: YUI().use('base', (Y) -> console.log Y.Base)
Then I eventually get the Y.Base ctor function
It looks like loader is attaching async as it works fine using the callback method. IIRC the first method is supposed to work too though. What am I missing?
If you're using YUI in a controlled environment like Node.js, then you should be able to use useSync configuration:
YUI({ useSync: true }).use('base').Base
But in a browser, or any other client runtime you should stick to the asynchronous nature of Y.use so loader can do its job of computing the proper list of modules to be attached based on the feature detections etc. Having the modules included manually in the pase is just not enough. Imagine the scrollview-base in IE, which requires an special module called scrollview-base-ie, unless you do detection when building the initial markup that includes that module only when running in IE, you will have a missing module. Again, stick to the asynchronous pattern when loading stuff.
YUI modules really want to be called through a Y object in a callback. If you know for sure that all the code you need is loaded on the page, you can attach them all synchronously with a use *. See https://github.com/evangoer/yui3-cookbook/blob/master/examples/loading/use_synchronous.html for an example.
In Meteor 0.5.8 the following change was introduced:
Calls to the update and remove collection functions in untrusted code
may no longer use arbitrary selectors. You must specify a single
document ID when invoking these functions from the client (other than
in a method stub).
So now if you want to push arbitrary updates to the db from the client console, you have to do something like:
People.update({_id:People.findOne({name:'Bob'})['_id']}, {$set:{lastName:'Johns'}});
Instead of:
People.update({name:'Bob'}, {$set:{lastName:'Johns'}});
I thought that this security issue controlled by setting the Meteor.Collection.allow and .deny functions in conjunction with the autopublish and insecure packages. I liked being able to interact with the db from the Chrome JavaScript Console.
What is the motivation for the changes in Meteor 0.5.8?
From the Meteor blog:
Changes to allow/deny rules
Starting in 0.5.8, client-only code such as event handlers may only update or remove a single document at a time, specified by _id. Method code can still use arbitrary Mongo selectors to manipulate any number of documents at once. To run complex updates from an event handler, just define a method with Meteor.methods and call it from the event handler.
This change significantly simplifies the allow/deny API, encourages better application structure, avoids a potential DoS attack in which an attacker could force the server to do a lot of work to determine if an operation is authorized, and fixes the security issue reported by #jan-glx.
To update your code, change your allow and deny handlers to take a single document rather than an array of documents. This should significantly simplify your code. Also check to see if you have any update or remove calls in your event handlers that use Mongo selectors (this is quite rare), and if so, move them into methods. For details, see the update and remove docs.
So basically, from my point of view, you almost never want the behavior to be able to update and delete arbitrary sets of documents from the client without any more specific knowledge (like the id of the document).
When prototyping—which I'm guessing is what you're doing—I suppose it can get in the way, but then if you ever want to get your code into production, I believe the pros outweigh the cons. This also comes down to the security declarations (allow and deny) being easier to specify after this change.
Hope that gave you some more information.
We are developing a Metro-style app in C++ and JavaScript. The C++ side provides us with IObservableVector<T> instances. The JavaScript side uses the WinJS.UI.ListView control.
List views are normally hooked up to WinJS.UI.IListDataSource instances. Most typically, one takes a WinJS.Binding.List and uses its dataSource property.
However, it seems very natural to want to hook up an IObservableVector<T> to the list view. Is there any way to do this? For example, is there any adapter for turning IObservableVector<T>s into Lists or IListDataSources?
One route we could go down is to write our own custom WinJS.UI.IListDataAdapter implementation that hooks up to an IObservableVector<T>, then go through the whole game with the poorly-documented WinJS.UI.VirtualizedDataSource and so on. But, has anyone done this already? It seems like it should be in the framework.
WinJS 1.0 doesn't support the WinRT change notification interfaces (INotifyPropertyChanged, IObservableVector). If you want to hook them together, you'll need to write an adapter/data source.
Based on #Chris Tavares's helpful, if discouraging, response, I wrote such an adapter:
https://github.com/NobleJS/WinningJS/blob/master/lib/ObservableVectorDataSource.js
It is currently read-only (so you cannot update the data source and expect changes to propagate to the observable vector), but works great in our app.
What is the best practice for calling autosubscribe client side in a Meteor app?
Should it always be in Meteor.startup?
If so, why?
If not, why?
If sometimes, why?
In summary, what is the best practice and what are the trade offs based on the options of putting autosubscribe in the meteor.startup versus not? I think this is very important at this time for application developers because it significantly affects our application design decisions.
Autosubscribe has been deprecated and I suspect you want to use autorun now,. It's documented at http://docs.meteor.com/#meteor_autorun
When you want to automatically update the subscription whenever the session variable changes.
Source: From the comment in the example at Meteor.autosubscribe.
From tests I have done it does seem that putting your autosubscribe in Meteor.startup is the safest solution if you need those collections to have some kind of data population or start populating before view rendering. I experienced similar issues that #matb33 has reported with empty data on load and placing autosubscribe in Meteor.startup on the client solved the problem.
Note that autosubscribe is now gone, and replaced with autorun.
I'm working with an application which was originally designed to make heavy use of static-variables and functions to impose singleton-style access to objects. I've been utilizing Parsley to break apart some of the coupling in this project, and I'd like to start chiseling away at the use of static functions.
I will explain the basic architecture first, and then I'll ask my questions.
Within this application exists a static utility which sends/receives HTTP requests. When a component wishes to request data via HTTP, it invokes a static function in this class:
Utility.fetchUrl(url, parameters, successHandler, errorHandler);
This function calls another static function in a tracking component which monitors how long requests take, how many are sent, etc. The invocation looks very similar in the utility class:
public static function fetchUrl( ... ):void {
Tracker.startTracking(url, new Date());
...
Tracker.stopTracking(url, new Date());
}
Any components in this application wishing to dispatch an HTTP request must do so via the web utility class. This creates quite a bit of coupling between this class and other components, and is just one example of several where such reliance on static functions exists. This causes problems when we're extending and refactoring the system: I would like to decouple this using events.
Ultimately, I'd like each component to instantiate a custom event which is dispatched to a high-level framework. From there, the framework itself would relay the event to the correct location. In other words, those components which need to perform an HTTP request would dispatch an event like this:
dispatchEvent(new WebRequestEvent(url, parameters, successHandler, errorHandler));
From there, Parsley (or another framework) would make sure the event is sent to the correct location which could handle the functionality and perform whatever is necessary. This would also allow me a stepping-stone to introducing a more compartmentalized MVC architecture, where web request results are handled by models, injected by the framework into their own respective views.
I'd like to do the same with the tracking functionality.
Are there drawbacks from using an event-based mechanism, coupled with a framework like Parsley? Is it better to stick with static functions/variables and use the singleton-style access? If so, why? Will this end up causing more trouble in the future than it's worth?
So, short answer on Events drawbacks:
Slightly more weight on the system to use the events. Listeners, bubbling, capture, etc.. all have to be managed by the system. Much less of an issue when you're outside the display hierarchy, but still more expensive than straight functions. (then again, avoid pre-optimization, so get it right, then get it fast).
"Soft" circular dependencies can occur in complicated asynchronous systems. This means you end up with a case where A triggers an event. B notices A has changed, so updates C. C triggers an event. D notices C has changed and updates A. Doesn't usually max the CPU, but is still a non-terminating loop.
Sometimes you need to have forced buffering / locking of functions. Say component A and B both trigger the same event. You might not want C to be triggered twice (e.g., fetching new data from server) so you have to make sure C is marked as "busy" or something.
From personal experience, I haven't seen any other issues with event systems. I'm using the PureMVC framework in a relatively complicated system without issue.
Good luck.