This article (http://dweldon.silvrback.com/guards) describes that the helpers of a template are evaluated again after a subscription (which was defined in a iron-router waitOn function) is ready / the client-side collection gets a new item.
My question is, how can I get the same behaviour for a subscription that was defined inside the template (i.e. in the created or rendered function)?
Ok, thanks for this information! I removed the fields in subscribtion which I used in the query on the client... It is working now. Thank you.
Related
I am using Meteor and FlowRouter, and I would like to force my page to reload when I change the url (or alternatively one of the parameters of my route). Would anyone know a way to do so?
There has been a few debates over this, but I haven't found a satisfactory answer yet.
PS:
I know one suggested method is to put FlowRouter.watchPathChange() inside a Tracker.autorun() but this doesn't seem very satisfactory for what I want to do (changing css classes based on the route parameter), plus I'd like to have the effect of having a page reload.
FlowRouter has a few reactive APIs for accessing the URL state very efficiently:
FlowRouter.getParam("paramName")
FlowRouter.getQueryParam("queryParamName")
FlowRouter.getRouteName()
FlowRouter guide
Putting FlowRouter.watchPathChange() inside a Tracker.autorun() is not the only option. You can put in autorun some of functions listed above.
I'm learning so if this is a silly question feel free to let me know. My question relates to subscription and where you should subscribe. Let me be more specific with an example.
files
template.html
templatePieceOne.html
templatePieceTwo.html
In this example we have a template.html that will render using two separate template pieces. The template pieces might be used else where on the website. Is it better to subscribe at the top level template.html, template.js, or should the template pieces each have their own subscription.
If this doesn't make sense please let me know.
You definitely shouldn't subscribe in every template. Instead, you should decide which templates correspond to an independent part of the application, i.e. a view, modal or widget. Those templates should be responsible for subscribing to, managing and passing down their data.
This way you'll be able to see easily which part of the application is active at any given moment and what it subscribes to.
I recommend the following article on
presentation and container components.
Even if you're using Blaze instead of React the idea is still valid.
why does twig's render function create a subrequest ? Why dont they just render the response and send it as part of the response ?
Also I can see that the rendered response appears in the browser just after the main template shows up. How does it happen ?
I created an answer on Stackoverflow which basically goes through the different alternatives of the render function.
It also explains why you should be using the render function over a regular include.
I'd advise you to read the chapter about embedding controllers in Twig. An interesting quote from the doc about when you should consider using the render function:
Whenever you find that you need a variable or a piece of information that you don't have access to in a template, consider rendering a controller.
TL;DR
By default, the render function only takes a URL (either absolute or relative).
By analogy it is like getting HTML through ajax and injecting it in the page: one request that queries a controller to get some HTML which get injected it into the page.
There are different render calls like render_esi (for support of the ESI tags) that have their own rendering strategies. If you start with the inline rendering (through the default render function) you will have the opportunity later on to use other rendering strategies without refactoring your code.
The render function is meant to scale your application.
For more details about its usefulness, let's look at the render_esi function.
With the render_esi function you can implement ESI tags to use with Varnish.
(There are other solutions than Varnish but it's among the most popular ones)
Varnish is a caching solution that is located between your web servers and the users. Varnish will filter the response from your web servers, cache the entire page then look for these ESI tags.
If Varnish cached your page for a day but the render_esi function are set to be cached for 2 hours, Varnish will only query (through a URL when the cache expired) for these specific render calls instead of the entire page (which is why render_esi do sub-requests) and replace parts of the template with the sub-requests' response.
Caching in general is very interesting and very broad so it's hard to go over every details in my answer but I hope my answer will help you.
Caching (or cache) according to Wikipedia:
In computer science, a cache (/ˈkæʃ/ kash)[1] is a component that transparently stores data so that future requests for that data can be served faster.
Render is used when you not just want to include another template snippet, but also want to execute specific businesslogic, that belongs to this template. Or in other words: When include just isn't enough, you use render.
Because render doesn't only include a template, but also executes controller logic, it is encapsuled as a subrequest.
Imagine you want to display the latest news in a box on every page of your website. If you want to solve this with an include, you would have to fetch the latest news in each of your actions and pass it to your template.
But if you use render, you just write one action for this, and put a render tag everywhere in your templates where you would like to have that news box. The render tag executes the associated controller action, renders the response, and injects it into your current template.
Because I suck at explaining, you might also want to read this part of the symfony doc: http://symfony.com/doc/current/book/templating.html#embedding-controllers
In my opinion, answer should sound like this:
Controller is pretty simple "unit" which receives request and sends response.
Creating sub request for rendering controller gives you more power (flexibility).
About flexibility. Look at your controller, just like it just receives request and sends response and for example, you want to somehow filter request or decorate response? Where will you put this logic? Of course, at event listeners which can use other services to solve this task.
For example, I often use parameter converters for my controllers (it's not about good design, just for example). So how can I use "render", with specifying just id of my entity, to render only controller without creating sub request?
If you really want just to render some data you can use "include" or create an extension. Or you can create extension to render controllers without sub request, but think about it carefully, because further you can add more logic to filtering response and so on.
I can be wrong, it's just my opinion ;)
Every tutorial/example i can find for meteor shows a single view application. I would like to build something a little more complex. I'm unclear how to approach multiple views...preferably in a way that's somewhat scalable?
The iron-router package lets you access different views (layouts) by nice, REST-ful human-friendly clean URLs. It supports parameters in the URL, "loading" templates, waiting for subscriptions to finish loading, before and after hooks etc.
At this point you can only create Single Page applications with Meteor. Note that Single Page, doesn't mean you can't have several views - use iron-router for that.
But by design, Meteor serves a big fat unique JavaScript/HTML/CSS application down to the browser, though there's a feature request to allow incremental loading. It is then up to the application (or more precisely, the JavaScript framework), to dynamically render its views in order to display different "pages".
I was wondering the same thing and it took me way too much time getting something started. I finally got a paged app working solidly by using Backbone views and routes, so I created a simple boilerplate project to make setting up an app like this easier in the future.
Live demo here: backbone-boilerplate.meteor.com
Source code here: github.com/justinmc/meteor-backbone-boilerplate
Have you looked at madewith.meteor.com?
A bunch of apps there have multiple views using Backbone also Jonathan Kingston who created britto has started simple meteor framework called Stellar
At this stage of the game not sure if there really are best practices. But these two seem to be the current flow.
You can also make a tabbed interface for multiple views. There is a package project "Smart package for generating a tabbed interface with pushState" github project here: https://github.com/possibilities/meteor-tabs
The best solution right now is using a routing package (router is basic but works). The workflow is something like this:
declare routes; return a template name for each route
place the reactive helper provided by the package in your body tag
the reactive helper will return the template associated to that route
you create a template for each route and optionally set custom publish functions
Router will give you browser history (client side).
Note that at this time there are some limitation on the way Meteor handles html/js. They are load all at the same time. The bright side is that once the app is loaded, page transitions will be instant.
Is there a module that allows me to log all the searches made on a view ?
Thanks !
I think you will need to write custom code to achieve that! I'm assuming you know some basics about writing Drupal custom code. You will need to use a hook that gets called before your view is displayed. In the hook you should log whatever information you want e.g. the keyword that was entered in the exposed filter.
Please see http://drupalcontrib.org/api/group/views_hooks/6 for the hooks that are available to you in Views.
I'm guessing you would probably use something like hook_views_pre_render