Given that Symfony is going to be used to provide Drupal 8's HTTP library, it would be worth looking to see what other functionality could be replaced by Symfony. As a follow-on ticket, it might also then be useful to identify a path to completely immerse Symfony in Drupal, for those who want even more.

List of related issues

Please help keep this list up-to-date, and please tag all related issues with 'symfony' to help track them:

Comments

dixon_’s picture

Since we decided on the HTTP Foundation from Symfony2, I really think we should make use of the session handling that is bundled with the HTTP Foundation from Symfony. So, since we already have to carry that code weight, and our current session handling is a loosely defined inc file with a bunch of procedural functions in it, I think that makes total sense.

There is an issue about making the session handling OOP somewhere, couldn't find it though. But that's one thing I think makes total sense.

dixon_’s picture

And to add, the Symfony2 session handling has a very nice layout (as with everything else in Symfony2). It's pluggable and comes with a PDO implementation that I could see us use as a base.

dixon_’s picture

And here is a good issue, with some history, to continue the session talks in, maybe: #335411: Switch to Symfony2-based session handling

renat’s picture

Subscribe

adamdicarlo’s picture

Subscribing.

Crell’s picture

Subscribing for obvious reasons. :-) Sessions and the registry are the obvious places, since we're pulling in that code already.

wojtha’s picture

Subscribe

DamienMcKenna’s picture

Title: Identify other pieces of Drupal that could be replaced by Symfony code » Identify pieces of Drupal that could be replaced by Symfony code
catch’s picture

The registry we should probably start with #1240138: Adopt PSR-0 namespace convention for core framework classes and spin-off issues? The quicker we can do that for classes in /includes the better. Then it's a case of classes provided by modules which needs a separate discussion and will probably take a bit more work, but it'd be good to avoid the database registry for those as well since we've got outstanding critical issues from that.

Unless we have a pressing need for something else (i.e. like the HTTP request classes which we didn't have any real equivalent API for in core) I'd prefer it if we focused on what's in the HTTPFoundation library first and see how that goes for a bit. However that doesn't mean we can't start looking at what else there is and if it's interesting.

Just as a sanity check, when looking at cache API refactoring, I had a good look at the Zend Cache (i.e. http://framework.zend.com/manual/en/zend.cache.html). which has some good things about it but several things I didn't like as well.

I've not been able to find any equivalent API grepping around Symfony or googling (it looks like components implement their own one-off caching - i.e. doctrine, as opposed to using a common API like cache_get()/cache_set() etc.), however I want to be sure I'm not missing anything.

q0rban’s picture

Subscribe

fietserwin’s picture

The decoupled front and back-end from the Zend cache is good, meaning you can change the back-end cache (db, memcached, file system) without changing anything in the code that uses caches as that is talking to the front-end interface.

A similar pattern used used for logging. One front-end interface, multiple back-end implementations (db, file, system event, status message on screen, ...) that in this case can be instantiated and written to together, each having their own filter, e.g. based on severity. It can also include handling PHP errors (http://framework.zend.com/manual/en/zend.log.overview.html). I'm not sure about the equivalent in Symphony.

catch’s picture

@fietserwin. We've had that pattern in Drupal for a long time, caching has been swappable since Drupal 5.0 was released, logging has been swappable since 6.0. It's a great pattern but not something we're currently missing.

Our caching API is reasonably mature and having reviewed both Zend's and Kohana's recently I'm pretty firmly in favour of keeping our own (although it does need updating slightly but there's active work going on there) - particularly our existing contrib implementations are further along than the ones Zend or Kohana provides (many of which just throw exceptions when confronted with something tricky).

Logging I've not looked at in Zend or Symfony yet. There is a decent choice of logging modules in Drupal and they generally work well, but I'm not entirely comfortable with watchdog() itself relying on the hook system since that creates some tricky interdependencies, so we might want to revisit that part of it (or make the hook system less dependent on other systems which would also help here).

lsmith77’s picture

For logging Symfony2 uses the Monolog project which is a port of a python lib.
For caching there is no generic component in Symfony2.
Zend Cache afaik is pretty good. Alternatively Doctrine also has a cache layer, not sure how generic it is though.

Seldaek’s picture

Monolog author here, I'd be happy to help and answer any questions if you'd like to integrate it in Drupal.

catch’s picture

I've opened an issue for logging here #1289536: Switch Watchdog to a PSR-3 logging framework, wasn't sure if it was a good idea to mix general refactoring discussions with specific discussion of Monolog but went for that for now.

Cyberwolf’s picture

One of the weak points in Drupal I always need to get around is its lack of advanced e-mail capabilities. There is no MIME or SMTP support out of the box, and the contrib modules out there which are implementing these things are either

  • reinventing hot water instead of using any existing decent libraries
  • using an existing library and need to implement the MailSystemInterface to integrate it with Drupal

I think it would be great if Drupal adopts an existing, well-tested, more widely used (meaning: out of Drupal) library for e-mail handling (both for the message itself as well as for the transport layer). Symfony mostly uses the Swift Mailer library, which is also maintained by Fabien Potencier, and is a good candidate for Drupal IMHO.

lsmith77’s picture

Swiftmailer is quite powerful indeed. However it has one severe issue and that is that its very heavy to instantiate, because of the way the dependency injection container is setup in the library. One day, though currently that day isn't planned to be too soon, it should be rewritten/refactored and moved to PHP 5.3.

Cyberwolf’s picture

Hi lsmith77, can you clarify what you mean with "very heavy"? Do you mean it uses a lot of system resources (memory) or that it's not so straightforward for developers to use the dependency injection container?

I certainly see some benefits in using the DI container in Drupal, as you could easily swap the actual implementations in different areas of e-mail handling with other ones.

Will try to have a closer look at this soon and see if it's feasible to use it in Drupal core.

lsmith77’s picture

Before you can use swift mailer in any request you need to include https://github.com/swiftmailer/swiftmailer/blob/master/lib/swift_init.php
This file as you can see includes several files that dynamically build up the dependency maps, this of course takes time.

A better approach is what the Symfony2 dependency container does is to essentially turn the entire dependency map into a once compiled PHP class with methods that only do the exact work necessary to create the required instance.

I am not sure if it would be possible to refactor swift mailer or if this would be such a fundamental change that it would be close to a rewrite.

That being said, its not the end of the world, but just wanted to make it clear that swift mailer has a bit of legacy baggage uncommon for other components used in Symfony2.

Crell’s picture

We haven't decided yet if we're going to implement a full on DIC for Drupal 8 logic objects. If we do, it will likely have to be runtime, not a "compile on a script" class, because Drupal cannot guarantee a "developer goes to the command line step and runs a program" step. Symfony can, because of the type of project it is. Drupal is a different type of project so cannot guarantee that.

lsmith77’s picture

I think you misunderstood what I meant with runtime here.
Its "runtime" in the sense that it configures an object at runtime by making method calls. This is obviously slow and repetitive. The Symfony2 on the other hand uses configuration to generate a class that needs no runtime configuration at all in order to be able to resolve dependencies and create class instances. There is no CLI involved here. Symfony2 simply watches the config files in dev mode for changes and automatically regenerates the DIC class. For production this is turned off by default.

Crell’s picture

I think you misunderstood me, actually. :-) I'm saying the Symfony2 approach of generating code is not viable for Drupal, because Drupal cannot guarantee the existence of a "Development mode" in which the code is able to do so. (Drupal is not allowed to write PHP code to disk for security reasons, except for the initial settings.php file during installation.)

lsmith77’s picture

Ok let me try one more time :)
Symfony2 has dev mode and prod mode etc. Drupal doesn't and thats fine.
The point is that the Symfony2 DIC can automatically keep itself uptodate or not, its your choice as a user of this component.
Symfony2 just chose to automatically regenerate in dev mode and not regenerate in prod mode.
Drupal can choose to always regenerate the DIC class if it detects that a configuration file was changed.

lsmith77’s picture

Anyway, to get back to the question that brought us here .. swift mailer's DIC is just needlessly expensive. Now if its prohibitively expensive is up to you guys to decide. Symfony2 decided that for now its ok and that there are no better alternatives.

RobLoach’s picture

Templating
SymfonyTemplate/TwigTemplate could live along side our PHPTemplate (node.tpl.twig).
YAML
YAML could replace any config files we have (system.info).
Crell’s picture

Another possible component is the BrowserKit component: https://github.com/symfony/BrowserKit

It provides an abstraction for the stuff we currently do with drupal_http_request(). Unfortunately it doesn't include an implementation; I suspect because that would have introduced a dependency on HttpFoundation (for the response object), but since we have that anyway that's a non-issue. We could build an implementation on top of that ourselves, or Lukas tells me that a lot of Symfony folks end up using https://github.com/kriswallsmith/Buzz . I have not looked at it myself in any sort of detail to say if it's useful for us or not.

That would let us lazy-instantiate and outsource much of the code for a viable drupal_http_request() replacement.

beberlei’s picture

The most important thing is imho having the drupal "front controller" implement:

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Htt...

All the rest in HttpKernel is irrelevant compared to this. Why?

There are two intermediate benefits:

1. You can use the Symfony Reverse Proxy written in PHP to allow reverse-proxy caching for Drupal on the PHP level out of the box. This would even work on shared hosts.
2. Drupal applications can be nested into Symfony or any other applications that implement this interface, for example as a subrequest.

nielsvm’s picture

subscribing

dimduj’s picture

Hi,

Glad to see that Drupal and Symfony are joining their effort, I add my two cents, hope this could help:

FORMS:
We could replace the Form API using the Symfony's forms objects
See: http://symfony.com/doc/current/book/forms.html.

Symfony forms object handled the building of the form, the validation, the submission and the theming.

There is already a security token mechanism (CSRF Protection) similar to Drupal.

IMHO, One of the biggest advantage of Symfony forms over Drupal ones is the better separation between the form building and form binding (based on a request object and not on data in the $_POST ),:

public function newAction(Request $request)
{
    // just setup a fresh $task object (remove the dummy data)
    $task = new Task();

    $form = $this->createFormBuilder($task)
        ->add('task', 'text')
        ->add('dueDate', 'date')
        ->getForm();

    if ($request->getMethod() == 'POST') {
        $form->bindRequest($request);

        if ($form->isValid()) {
            // perform some action, such as saving the task to the database

            return $this->redirect($this->generateUrl('task_success'));
        }
    }

    // ...
}

SCHEMA
The schema api could be replaced by the symfony model:
Symfony use YAML to define the model ( similar to Drupal hook_schema())

In Symfony, basics forms can be generated based on the model (our schema), those forms can be extended if needed

jonaswouters’s picture

@dimduj Symfony2 not only uses yaml, but leaves the choice to the user. So using plain php, xml, the database or something completely different is possible.
Maybe something drupal can adopt as well?

Using yaml as standard would make sense.

catch’s picture

@dimduj, where is the Symfony schema code, I only see raw CREATE TABLE statements in the various classes, or Doctrine.

lsmith77’s picture

@catch: Symfony2 itself is database agnostic. there are some Bundles you can enable that add support for Doctrine (and there are others for Propel etc). Now any Bundle relying on Doctrine etc would include the schema configuration in its own Resource directory (or as annotations) for the Entities/Documents the Bundle provides. In other words the database schema isn't defined on an application basis, but on a per Bundle basis.

The Doctrine*Bundles then provide CLI commands for operating on these config files. F.e setting up tables for the ORM is done via:
app/console doctrine:schema:create

dimduj’s picture

@catch Yes, I mean, by using Doctrine... ( I talk about the model cause there is a good interaction between the forms and the model (model's forms are build dynamically using Doctrine))

amateescu’s picture

dimduj’s picture

@amateescu ... well thanks for the information ... forget about Doctrine...

And what about the forms ?

Damien Tournoud’s picture

At first sight, the Form API is way more powerful then Symfony Forms. And you definitely can submit data into forms that are not coming from $_POST.

dimduj’s picture

Maybe more powerful (I'm interested to know why ?), but the OOP apporach seems cleaner ?

lsmith77’s picture

the form and validation are adaptations of java standards originally developed in the hibernate project IIRC. so they are very solid in their concepts. one important difference to most form layers: the Symfony2 validation system validates object state and not request parameters. so the form layer has tools to populate a model instance from a request, but the actual validation is then done on object state. this has the nice side effect that the validation can also be used to validate model instances that have not been populated via a form.

cosmicdreams’s picture

I think that replacing Drupal's FormAPI with something else would be very controversial. How much of a burden are we going to put on the community to relearn Drupal in Drupal 8? I think we should really consider the cost of these benefits and have a good transition plan on how to get there, if that's were we really want to go.

willvincent’s picture

but the OOP apporach seems cleaner ? - dimduj

Cleaner how, as in less code?

Sure.. there probably is less code written for each form element, but that doesn't make it 'cleaner' that makes it more obfuscated, obtuse, and difficult to understand (and potentially write, debug, and maintain).

When you look at a FormAPI array it's pretty clear what every element of the form is, what it's attributes are, and how it's going to work. Mucking up the clarity of that with a bunch of convoluted OO code isn't necessarily going to make things better.

Yes, OO has it's advantages, but it's not the end all be all solution. As far as I'm concerned the form api works quite well, and there is no reason to fix something that isn't broken.

If I wanted to write Symphony apps I would work with Symphony, not Drupal.

Seldaek’s picture

@cosmicdreams: One approach there might be to make sure the FormAPI is decoupled enough that those willing to use other ways to handle their forms can do so, without forcing anything new onto the larger community. This would allow the transition to happen more naturally maybe.

I have no idea how deep the forms are integrated in Drupal at the moment, so this is maybe not practical, but in Symfony the use of the Form Component is completely up to the user. Of course Drupal being a bit higher level, it may be harder to accomplish.

Crell’s picture

Issue tags: +WSCCI, +D8MI

HttpKernel is on my list of things to investigate. I don't know yet if it will work for what we want to do. If it does, great. It does sound at the conceptual level like it's along similar lines. Whether or not it would work in practice given Drupal's needs I don't know yet.

As DB maintainer for Drupal I consider Doctrine off the table, for reasons mentioned in the blog post in #34. :-)

FAPI vs. Symfony forms, I'm a bit impartial. On the one hand, I have nothing against Symfony's form system (not having really looked at it); with the class loader now in core we will need to OOP-ify the form processing engine at least anyway so it's not like FAPI can get by unscathed; FAPI as we all know is notoriously hard to document; And less code we have to maintain ourselves is a good thing.

On the other hand, FAPI is extremely deeply integrated into Drupal with the Render API; I don't know how well Symfony forms handle partial form rebuilds for AHAH, form element dependency, HTML5, and so on; I am concerned about the performance implications of that many more method calls; And hook_form_alter is not going away any time soon.

On the first hand, WSCCI will be taking a hatchet to Render API anyway, at least at the page level, by eliminating the "page" as a renderable element.

So... I don't know.

The Console component looks like it may be useful for the Drush folks. There's also a Locale library that is worth looking into as part of the D8MI initiative.

Gábor Hojtsy’s picture

Issue tags: +language-base

Tagging for base language system.

Gábor Hojtsy’s picture

Issue tags: +negotiation

Tagging for language negotiation too.

sun’s picture

boombatower’s picture

Currently, the FAPI and render API are similiar, but not entirely the same. In order to use symfony2 form component the render API will need class components as well that will probably stay Drupal specific and simply work together with form API. Otherwise I suppose we would have to use templates for everything, unless there is some other existing mechanism to mimic the render API in symfony.

Converting the form system seems to make sense for several reasons:
1) less code to maintain,
2) one less drupalism,
3) decreased memory footprint [based on some basic comparisons]

It doesn't sound like anyone, including myself, has looked too deeply to tell if there are any obvious show stoppers, but it seems worth attempting. On that note I'll open a separate issue to evaluate the symfony form component. #1447712: Evaluate Symfony form component as a replacement for Drupal FAPI

boombatower’s picture

What about the BrowserKit component to replace drupal_http_request() and DrupalWebTestCase internal browser. Originally, I worked on http://drupal.org/project/browser which got all messed up during the long code freeze and what not, but the idea of replacing both with a single browser component was accepted.

This would seem like a fairly straight forward change, infact we can use the CssSelector component as an optional replacement for writing xpath directly in tests.

EDIT: webchick agreed that this seems like a good idea on the surface so I created #1447736: Adopt Guzzle library to replace drupal_http_request()

boombatower’s picture

file_scan_directory() with Finder component, looks like it would solve #1165694: Remove default nomask from file_scan_directory()
FileSystem component for our file handling functions? handles all the fun stuff like links and recursion.

pounard’s picture

boombatower +1 FAPI issue seems to be hardest out of the 3

Crell’s picture

I have not worked with the Finder component, but from reading through its documentation it sounds like fun. We would need to experiment and see what it would buy us if we were to use it. If it ends up giving us more bang-for-the-buck, I'm fine with using it.

cosmicdreams’s picture

I must admit, I'm not too familar with the apis for handling files but the file_entity effort is making a lot of the same implementations. Still, it would be good to evaluate if adding this library will be a win. So I created an issue for it: #1451320: Evaluate Symfony2's Finder Component to simplify file handling

Gábor Hojtsy’s picture

Issue tags: -D8MI, -language-base

Clemens tried hard, but turns out not relevant for D8MI. Untagging.

Gábor Hojtsy’s picture

Issue summary: View changes

Added a list of issues.

fago’s picture

fago’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes
Status: Active » Fixed

Aside from #1289536: Switch Watchdog to a PSR-3 logging framework, this meta issue is done (for D8).

Aforementioned issue could really use some help though — our "watchdog" logging system is one of the last remaining legacy beasts in D8, which continues to produce problems.

Thanks all!

andypost’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.