Skip to content

[2.2] ResourceWatcher component (final?) #4605

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 69 commits into from

Conversation

everzet
Copy link
Contributor

@everzet everzet commented Jun 18, 2012

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -

This is final rebased version of #3961, which was a refactoring of #391

Short overview

This component is here for tracking filesystem changes. You're registering directory or file resources to track with specific track name (tracking_id) and start() watcher. Watcher checks for FS changes after specific timespan and if some change occur (file/directory create/update/delete) - watcher dispatches EventDispatcher event with resource_watcher.all, resource_watcher.tracking_id names and FilesystemEvent as argument.

Usage

Simplest possible way of FS tracking

Simplest tracking code would look like this:

<?php

$watcher = new Symfony\Component\ResourceWatcher\ResourceWatcher;

// track for any change inside `config` subfolder:
$watcher->trackByListener(__DIR__.'/config', function($event) {
    echo $event->getTypeString().': '.(string) $event->getResource();
});

// start listening
$watcher->start();

best suitable Tracker and EventDispatcher would be instantiated for you, implicitly

track() method

Extended usage looks like that:

<?php

use Symfony\Component\EventDispatcher\EventDispatcher;
use Symfony\Component\ResourceWatcher;
use Symfony\Component\Config\Resource;

$dispatcher = new EventDispatcher;
$tracker = new ResourceWatcher\Tracker\RecursiveIteratorTracker;
$watcher = new ResourceWatcher\ResourceWatcher($tracker, $dispatcher);

// track for any change in `view` subfolder to `twig.templates` tracker:
$watcher->track('twig.templates', __DIR__.'/view');

// track for `*.xml` files creations in `config` subfolder to `routing` tracker:
$watcher->track(
    'routing',
    Resource\DirectoryResource(__DIR__.'/config', '/\.xml$/'),
    ResourceWatcher\Event\FilesystemEvent::CREATE
);

// add `routing` track listener:
$dispatcher->addListener('resource_watcher.routing', function($event) {
    echo $event->getTypeString().': '.(string) $event->getResource();
});

// add all tracks listener (listens to every tracked event):
$dispatcher->addListener('resource_watcher.all', function($event) {
    echo $event->getTypeString().': '.(string) $event->getResource();
});

// start listening
$watcher->start();

addListener() method

If you don't want to deal with EventDispatcher, ResourceWatcher can hide this detail for you:

<?php

use Symfony\Component\ResourceWatcher;
use Symfony\Component\Config\Resource;

$tracker = new ResourceWatcher\Tracker\RecursiveIteratorTracker;
$watcher = new ResourceWatcher\ResourceWatcher($tracker);

// track for any change in `view` subfolder to `twig.templates` tracker:
$watcher->track('twig.templates', __DIR__.'/view');

// track for `*.xml` files creations in `config` subfolder to `routing` tracker:
$watcher->track(
    'routing',
    Resource\DirectoryResource(__DIR__.'/config', '/\.xml$/'),
    ResourceWatcher\Event\FilesystemEvent::CREATE
);

// add `routing` track listener:
$watcher->addListener('routing', function($event) {
    echo $event->getTypeString().': '.(string) $event->getResource();
});

// add all tracks listener (listens to every tracked event):
$watcher->addListener('all', function($event) {
    echo $event->getTypeString().': '.(string) $event->getResource();
});

// start listening
$watcher->start();

@travisbot
Copy link

This pull request fails (merged ba39a816 into 0b8b76b).

@travisbot
Copy link

This pull request fails (merged 22af887b into 0b8b76b).

"require": {
"php": ">=5.3.3",
"symfony/config": "self.version",
"symfony/event-dispatcher": "self.version"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can these versions be more specific? This component may be going into 2.2, but does it require the 2.2 version of these deps?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch. Nope for event-dispatcher, but yest for config, as PR provides couple of commits into Config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm. So, for symfony/config it should stay self.version, IMO.
But what constraint we should put for symfony/event-dispatcher? >=2.1.0, @stof @fabpot ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can use 2.0 unless you use $event->getName(), which was added in 2.1.

symfony/event-dispatcher@2.0...master

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, all Symfony2 components are requiring self.version for the other components to simplify the management of the composer.json files. As long as all components are released together, this works.

and for your suggestion, requiring >=2.1.0 is wrong anyway. It would mark it as compatible with Symfony 4.2 too, which is wrong as nobody can know what such version will be if it exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stof so, we should keep it as it is now (self.version), you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@everzet until we change the way it works for all components, yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok :) @kriswallsmith ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for moving away from self.version but I understand these things take time

@kriswallsmith
Copy link
Contributor

I'm very excited about this component. Thank you everyone who has worked on it.

@travisbot
Copy link

This pull request passes (merged 5cbb9e75 into 0b8b76b).

@fabpot
Copy link
Member

fabpot commented Jun 19, 2012

@everzet Can you make another PR for the Config component changes so that I can merge that part into Symfony 2.1? Thanks.

everzet added 22 commits June 20, 2012 10:08
this is a basic state checker, which checks all
files and directories recursively for changes
this resources tracker uses recursive iterator state
checker internally
if no tracker were specified in watcher constructor
it will use best one (inotify if available and rec
otherwise)
@travisbot
Copy link

This pull request passes (merged d1a7fcb into 092b5dd).

@everzet
Copy link
Contributor Author

everzet commented Jun 20, 2012

@fabpot @stof #4619

protected function createDirectoryChildCheckers(DirectoryResource $resource)
{
$checkers = array();
foreach ($resource->getFilteredResources() as $resource) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't array_map more appropriate here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but it doesn't really matter :)

@stof
Copy link
Member

stof commented Oct 13, 2012

@fabpot @everzet what is the status of this PR ?
@everzet it needs a rebase

@stof
Copy link
Member

stof commented Oct 13, 2012

btw, merging it will require fixing the serialization of the resource in AsseticBundle. Currently, it serializes far too much things.

@fabpot
Copy link
Member

fabpot commented Oct 13, 2012

#4619 should be fixed before we can merge this PR.

@webmozart
Copy link
Contributor

ping @fabpot

@ghost
Copy link

ghost commented Apr 6, 2013

will this make 2.3?

@stof
Copy link
Member

stof commented May 17, 2013

This code has been moved to a separate library: https://github.com/henrikbjorn/Lurker

Reusing the existing resources was causing issues as the component has different needs (see the changes done here on one hand and the discussion about config resources on the other hand). Keeping the config resources with their current purpose will make things easier.

I'm closing this PR in favor of Lurker. People wanting this feature can get Lurker through Composer (even in their 2.2 projects)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants