Generalize Builder and Renderer classes and methods

This is a WIP patch of the changes that are needed to modularize the current 8.x-1.x branch in a way that adding additional Engines* is simple. I won't bother to write a lengthy explanation here because I know it isn't great yet. I'll upload another patch, possibly tomorrow, and write an appropriate explanation of the changes I am proposing to the architecture of the project.

I've updated the issue summary with the proposed changes to the file structure. I will have to check my patch and make sure that it actually matches the suggested file structure. I was working on this patch and the Word Export patch simultaneously, and I don't think that I was careful enough in my commits and rebasing to match my intention. I'll fix it and upload the corrected patch though.

Hmm. I don't know. Let me give it a shot and see what happens.

Okay, so I gave it another shot and tried to use a generic print plugin as you suggested. That is what I was hoping I could do with my first patch, but I think I misunderstood some of the components. After spending quite a bit more time reading through the existing code, I think I am headed in a better direction with this patch. This should be more sustainable and modular. That being said, there are some issues with this patch in its current state. The /entityprint/node/1/debug works, but anything that utilizes an export library does not work.

Currently, I have tried to change the config schema like so:

entity_print.settings:
  type: config_object
  label: 'Entity Print settings.'
  mapping:
    default_css:
      type: boolean
      label: 'Enable the default CSS.'
    force_download:
      type: boolean
      label: 'Force download of Print'
    print_engines:
      type: mapping
      label: 'The plugin id of the Print engine to use.'
      mapping:
        pdf_engine:
          type: string
          label: 'The plugin id of the PDF engine to use.'

Also, the updated file structure is:

• src/
  • PrintBuilder.php
  • PrintBuilderInterface.php
  • PrintEngineException.php
  • Annotation/
    • PrintEngine.php
  • Controller/
    • EntityPrintController.php
  • Entity/
    • PrintEngine.php
    • PrintEngineInterface.php
  • Event/
    • PrintCssAlterEvent.php
    • PrintEventBase.php
    • PrintEvents.php
    • PrintHtmlAlterEvent.php
    • PresendPrintEvent.php
    • PresendPrintMultipleEvent.php
  • EventSubscriber/
    • PostRenderSubscriber.php
  • Form/
    • SettingsForm.php
  • Plugin/
    • PrintEngineBase.php
    • PrintEngineInterface.php
    • EntityPrintPluginManager.php
    • Action/
      • {{ export_type }}Download
    • EntityPrint/
      • {{ entity_type }}Engine/
        • {{ export_library }}.php
    • Renderer/
      • ContentEntityRenderer.php
      • RendererBase.php
      • RendererFactory.php
      • RendererFactoryInterface.php
      • RendererInterface.php

Gotcha. I made that change to my global gitignore. Thanks for the suggestion. They are easier to read now.

You can see the changes I made in this latest patch in the interdiff. The route-based export and Action plugin export are both working properly now. I think this provides a very extensible base to build upon with other export types. I will have to work on the tests though. I haven't updated them yet.

Yeah, the controller is currently defaulting to PDF. I think we will need a new URL structure. I like /export_type/entity_type/entity_id. That is the same URL structure I was using in my patch to add Export to Word via PHPWord. That should be in this patch though. I will update the routing file, check all of the tests, and then I think it will be ready to review.

Thanks again for your help and feedback.

Would it be simpler to change the URL structure to

/entityprint/{{ export_type }}/{{ entity_type }}/{{ entity_id }}

and the debug route could either be

/entityprint/debug/{{ entity_type }}/{{ entity_id }} OR
/entityprint/html/{{ entity_type }}/{{ entity_id }} OR
/entityprint/print/{{ entity_type }}/{{ entity_id }}

?

That's what I thought too, but do we need a /debug for each export_type?

I made some more changes based upon my latest work on 2733781. I didn't do much with the tests because we're going to have to change that up a bit anyway to test the different export types. I will try to tackle that soon though.

1. Yeah, it could be engine_type. I'm just trying to track if it's a pdf export or word_doc export.
2. Yeah, you are correct. That comment doesn't make any sense. I will have to fix that. Good catch.

Yeah, I'll try to summarize what I've done. Hopefully that will at least give you a good start and you can ask other questions if you have them.

• Changed the config to allow for multiple *_engines in the future. Right now we just have print_engines.pdf_engine.
• Changed the Action to pdf_download_action to allow for other *_download_actions going forward.
• I could use some help with entity_print_entity_view_alter in .module
  • If you can figure out a good way to get PDF and Word Doc and ePub from the config here, I think that would be helpful going forward. Maybe just adding another field in the config.
• I changed up the SettingsForm a bit to allow for future export types
• We should find a better way to abstract the file extension in generateFilename() in PrintBuilder. I think I came up with some lame solution in one of the other issues, but we come up with a better solution.

I feel like there was probably other changes, but nothing major that I noticed skimming through the patch. A lot of changes to filenames and methods.

Sorry. I missed some trailing whitespace. I applied this patch on a new branch and it worked. Let me know if there are any other issues. Thanks.

Okay, I rebased and I think that all of the merge conflicts were resolved appropriately

Some of the tests weren't updated.

EDIT: Yeah, I guess something went wrong with that directory in the merge. Here's a patch to try to resolve that.

I'm going to have to work on the tests more tomorrow. I'm tired.

Updated routes on the tests

just working on the tests

I'm not sure that I understand the issues with the tests right now. I might have to tinker with it later if nobody else has a clue.

I took care of your suggestions in #1 and #2. I agree with the follow-up issues. It would probably be easier if these other issues were broken into separate issues too. I can add the follow-up issues if you'd like. I'm pretty sure I could get started on 'Update the settings form for all export types' and 'Test/fix the "View" links for each export type'. Those seem pretty doable. I have never worked on an upgrade path like this. I would be very interested to see how that looks though and contribute however I can.

Yay!