Possibility to load the editor server-side instead of client-side

[JeanMertz]

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.

[jejacks0n]

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.

[JeanMertz]

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:

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.

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2605417

[jejacks0n]

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:

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:

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.

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2605417

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2605462

[JeanMertz]

I actually want it to load the iframe part on the server and not have a special URL. I guess I could build the page with the iframe on the server and then tell Mercury everything is set when the page is loaded. I'll see if I can get it working and create a wiki entry for anyone who is interested

Verstuurd vanaf mijn iPad

Op 2 nov. 2011 om 20:25 heeft Jeremy Jackson reply@reply.github.com 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:

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:

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.

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2605417

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2605462

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/66#issuecomment-2608196

[nreckart]

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.

[jejacks0n]

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.

[jejacks0n]

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. ApplicationController) determine a layout that should be used.. in this case if someone can_edit, and there's not a mercury_preview param set -- this param is passed back in when mercury loads it's iframe.

class ApplicationController < ActionController::Base

  protect_from_forgery

  layout :layout_with_mercury
  def layout_with_mercury
    if can_edit? && !params[:mercury_preview]
      'mercury'
    else
      'application'
    end
  end

  def can_edit?
    true
  end
end

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.

[nreckart]

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.

[jejacks0n]

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.