-
Notifications
You must be signed in to change notification settings - Fork 530
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
Possibility to load the editor server-side instead of client-side #66
Comments
If you're using rails, just follow the installation steps.. rails g mercury:install will put a template in your rails app.. basically read about the routes method -- it doesn't do a double load of the page and doesn't use the mercury loader. |
but as far as I understand, it does require the url to have a special "loader" path, like /homepage becomes /mercury/homepage. I try to avoid that in my system to confuse admins as little as possible. Am I correct in this thinking? Op woensdag 2 november 2011, om 17:09 heeft Jeremy Jackson het volgende geschreven:
|
Well, I've always had a toolbar that loaded.. and then when you click to edit it or something, it swaps out. On Nov 2, 2011, at 10:12 AM, Jean Mertz wrote:
|
I actually want it to load the iframe part on the server and not have Verstuurd vanaf mijn iPad Op 2 nov. 2011 om 20:25 heeft Jeremy Jackson
|
I would also like to be able to set everything, including the iframe, up server side and then just let Mercury know the page is ready for it to process. Using the route loading method, a request is made to /editor/thepage, which builds the Mercury stuff, then creates an iframe and strips out the '/editor/' part out of the URL and uses that as the src for the iframe, which results in another web request. So you get two web requests. At the very least, I'd like to be able to configure the editor route. Using /editor/thepage doesn't fit in with the flow of my app. If I have to stick with the route loading technique, I'd rather use a route like, /pages/123/editor. This currently isn't possible because the logic used to strip out the '/editor/' portion of the URL is hardcoded in the PageEditor.iframeSrc method. I just submitted a pull request (issue #68) that makes the PageEditor.iframeSrc method configurable via Mercury.config.iframeSrcMethod. Maybe not the best solution, but it allows me to do what I need for now. Being able to set everything up in a single web request would be ideal. |
I see what you guys mean, and it makes sense.. I'll take a look at how we could do this, or potentially make suggestions. @nreckart -- thanks for the pull request -- it was useful to see what you needed. =) I expect we could add a way to pass in the iframe you want to use to PageEditor (so one isn't created for you), and this will give you some flexibility -- but understand it'll still make two requests (the iframe request isn't made until after the first request is loaded). Other suggestions? I'm open to ideas. |
I exposed a few bugs while playing around with this.. so I'll be fixing those here in a bit.. but I came up with something sort of like this: Make your top level controller (eg.
Then, in the config file (this is where I found bugs -- seems rails loads things from vendor before your app/assets path wtf?).. anyway, I had to rename my mercury.js file to mercury_config.js and adjust the mercury.html.erb layout to also point to this file.. then at the bottom of that file (with the recent updates inspired by @nreckart) I added: jQuery(window).bind('mercury:loaded', function() { Mercury.PageEditor.prototype.iframeSrc = function(url) { return (url || window.location.href) + '?mercury_preview=true'; } }); Clearly the param thing is a hack, and if you're using any real params, it's likely an issue.. but it works in the simple case. I'll likely expand on this approach, and document something about it.. but give some things like that a shot and let me know what you think. |
Sorry, I must have been getting tired towards the end of the day yesterday. I now realize that there will always need to be two web requests to load the editor and then the iframe content. So building the iframe server side probably wouldn't help much. I like the 'mercury:loaded' event concept and will try it out today. |
I added some features, and a wiki article with more detailed instructions for this sort of technique. I'm closing this issue, as it was the inspiration for those features that are now a little easier to use. |
I was wondering, is it possible to load part of the editor on the server, instead of on the client? I ask this because I have an app where the editor is always visible (and can't be disabled) when logged in as an admin. But right now, when an admin loads a page, the page first shows up in a single frame, without the editor, after which the editor reloads the page with the editor loaded and the page stuck in an iframe.
This significantly increases loading times for each page (which is somewhat annoying) but I'd also like to be able to do things with the
_top
frame, like adding other admin commands (not related to the editor), without having them being stuck in the original page iframe.I will probably have more time to look into this next week, but I just wanted to throw this out there as a nice feature to have in CMS systems.
The text was updated successfully, but these errors were encountered: