Skip to content
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

Request for logic change in CMS/Twig/Extension #2184

Closed
DMeganoski opened this issue Jul 6, 2016 · 4 comments
Closed

Request for logic change in CMS/Twig/Extension #2184

DMeganoski opened this issue Jul 6, 2016 · 4 comments

Comments

@DMeganoski
Copy link

So, essentially what I am trying to do is integrate a pretty impressive drag and drop wysiwyg editor into october, and adapt it to the existing template logic.

This is a little complicated, having to have the markdown in the editor and the rendered html in the preview. So what I am doing is making a request and parsing the markup in my controller, then hiding the markup in the html with comments.

My issue is that the Class CMS\Classes\Controller has the functions to build and prepare the twig environment, yet when creating a plugin, the controllers are to extend Backend\Classes\Controller, which does not have the same twig instance being built.

I have found where the environment is built, and copied the initTwigEnvironment() function over to my plugin's controller.

The problem is, the class CMS\Twig\Extension requires an instance of CMS\Classes\Controller, when my controller is an instance of Backend\Classes\Controller. Trying to switch Controller classes leads to missing function issues.

So what I did was copied the CMS\Twig\Extension and all related classes into my plugin, and changed the requirement to the backend controller model. (I probably could have just extended it and fixed the namespace issues to avoid copying so many files but it seemed easier at the time)

This of course throws a few 'method not found' errors, but I manually added those methods to my controller and all works well now. It will render simple markdown like {% partial "nav" %}

I hate to re-create what already exists, and if you guys make any changes to those classes at all I will have to copy them all over again.

Instead, would you be willing to remove the Type Hint in the constructor of CMS/Twig/Extension?

This would allow me to utilize the existing twig classes without modification. All I would have to do is add the custom methods to my controller.

These methods could be added to Backend\Classes\Controller as well, to make things more compatible, but that is not really necessary for me. (renderPartial(), pageUrl(), etc.)

Not the most elegant solution, but I don't foresee many other use cases for this other than what I am trying to achieve. If you have a better solution, feel free.

@daftspunk
Copy link
Member

Have you considered using the system twig engine instead?

@DMeganoski
Copy link
Author

Sorry, my issue wasn't very clear. I could use \App::make('twig.environment'); But it would still be missing the additional tags and filters, such as {% styles %} and {% partial %} and the 'theme' filter that are created in Cms/Twig/Extension.

The idea is for javascript to send the markup, in small chunks, via ajax to the server where they are rendered to html as they would be rendered by the cms on that page.

I would have to create my own extension and add these tags manually. At the time of writing this, because of namespace issues, I had copied most of the classes over from Cms\Twig namespace into my plugin. Of course, that would mean that if you made any changes to those classes I would have to make my versions reflect them, and the plugin would likely be broken until that was done.

I have figured out now, though, (rookie mistake) that I don't have to copy all the classes over if I just extend the class Cms\Twig\Extension and override the constructor instead of trying to replace the whole class. (I also could have used 'use' to point the rest of the functions to the right namespace, but why have duplicate functions if you don't have to?)

This way the only code I have to worry about you changing is that particular construct function.

I would imagine that because the cms's extension relies heavily on the passed object having certain functions, you would prefer to keep the Type Hint. That is okay. I can make this work.

The only OTHER issue with this is that there is no way to tell the extension which page I want to render for, and it includes things (like css files) intended for the backend editor page only, instead of the frontend page I am editing. but that much can probably be sorted out later.

I will go ahead and close this for now.

@ghost
Copy link

ghost commented Jun 8, 2017

Hi, what about your "pretty impressive drag and drop wysiwyg editor for october cms", is it ready, could we test it ? I'm very interested by that !

@DMeganoski
Copy link
Author

DMeganoski commented Jun 8, 2017

Sorry, because of the complexity of the project, it has since been abandoned. I cannot remember what exactly all the complications were now, but I remember having stopped when I discovered that maintaining a relationship between the elements on the page and the elements that could be manipulated by javascript was next to impossible without re-working the entire javascript project.

Here is the editor I was trying to use, if you wanted to give a crack at it yourself, or perhaps inspire some ideas of your own. https://codecanyon.net/item/architect-lite-html-builder-frontend-version/12154122

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

No branches or pull requests

2 participants