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

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

Closed
JeanMertz opened this issue Nov 1, 2011 · 9 comments
Closed

Comments

@JeanMertz
Copy link

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
Copy link
Owner

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
Copy link
Author

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:
#66 (comment)

@jejacks0n
Copy link
Owner

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:
#66 (comment)

Reply to this email directly or view it on GitHub:
#66 (comment)

@JeanMertz
Copy link
Author

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:
#66 (comment)

Reply to this email directly or view it on GitHub:
#66 (comment)

Reply to this email directly or view it on GitHub:
#66 (comment)

@nreckart
Copy link
Contributor

nreckart commented Nov 3, 2011

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor

nreckart commented Nov 4, 2011

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
Copy link
Owner

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.

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

No branches or pull requests

3 participants