Question about server-side for history, notes, etc.

[DougPuchalski]

I'm noticing that the primary toolbars have paths such as /mercury/panels or /mercury/models. If these operations are designed to modify page data, is the intention that the paths would be modified to append a page identifier of some sort?

[jejacks0n]

I don't know if I understand your question.. the views are intended to be overridden by your application should you want to, so you can place your own views in /app/views/mercury/panels.

On Feb 17, 2012, at 1:07 PM, Doug Puchalski wrote:

I'm noticing that the primary toolbars have paths such as /mercury/panels or /mercury/models. If these operations are designed to modify page data, is the intention that the paths would be modified to append a page identifier of some sort?

---

Reply to this email directly or view it on GitHub: https://github.com/jejacks0n/mercury/issues/160

[DougPuchalski]

MercuryController#resource handles the default/stubbed requests for history/notes as defined in mercury_config.rb. I'm just noticing that the page that's being edited isn't in the request. So before I determine the way I want to do this, I thought I would first ask if you had envisioned a way to tell the MercuryController which page's history was being queried.

I was actually leaning towards using the show action for the page and adding query parameters, so the page in question would be implicit.

[gvarela]

Mercury makes no assumption about what you are editing. It's up to you to figure that out based on your implementation. For my application I overrode the Mercury#editor action so that I could query the page model I was editing as I load up Mercury. Then you can create custom handlers based on how you decide to store that information.

[DougPuchalski]

I must not be doing a good job of explaining my question.

The toolbar history and notes are noted as placeholders, but based on the high quality of the gem I would suspect that some thought was put into the requests they generate. I'm just trying to confirm that.

Are these merely placeholders that no one has thought of implementing yet?

[gvarela]

Yes these are just placeholders to show how you can add your own panels. Since Mercury is just an editor, granted a very full featured one, it is up to the developer to implement those. Those features are meant for the CMS in whatever form you build it.

Gabe Varela 303-638-6576

On Feb 18, 2012, at 4:41 PM, Doug Puchalskireply@reply.github.com wrote:

I must not be doing a good job of explaining my question.

The toolbar history and notes are noted as placeholders, but based on the high quality of the gem I would suspect that some thought was put into the requests they generate. I'm just trying to confirm that.

Are these merely placeholders that no one has thought of implementing yet?

---

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

[jejacks0n]

Gabe's right. Notice how mercury doesn't 'save' anything? Yes, it sends data on what content to save, but the gem itself doesn't save that content.

And without a model to represent that content, history and notes aren't possible.

[DougPuchalski]

Roger, thanks to both.

[jejacks0n]

Oh god, just re read your question. Yeah, I'd pass back the iframesrc -- a method in page editor. I should come up with something there, but if you get to it first I'd be curious what you do.

Sorry I didn't fully read the initial post.

[DougPuchalski]

No worries--

FYI I'm building a back-end gem inspired by and to bolt on to mercury. I'm overriding and extending in my own gem as needed, but would like to play well with any standards you've established.

Maybe pages could be RESTful. Rather than using an /editor prefix to the path, the route to the page directly should show the page as normally, and then /edit suffix would trigger the mercury editor, and then custom actions would follow. History, notes, etc. would just be nested singleton resources.

show: GET /about/contact-us edit: GET /about/contact-us/mercury-edit update: PUT /about/contact-us show history: GET /about/contact-us/mercury-history show notes: GET /about/contact-us/mercury-notes update notes: PUT /about/contact-us/mercury-notes

...and my addition would be

show metadata index: GET /about/contact-us/metadata show metadata: GET /about/contact-us/metadata/page_title update metadata: PUT /about/contact-us/metadata/page_title {metadata: {page_title: "New page title"}} create metadata: POST /about/contact-us/metadata {metadata: {published: "true"}}

I'm prefixing the actions with mercury- to avoid any potential routing conflicts to real content.

[gvarela]

Hey Doug,

I have just begun building a CMS on top of Mercury. It's still very early in development and very rough. But, it might trigger some ideas for you. Unless Rails 3.1 has changed things (it might have) you can't do route globs before a fixed segment which is why mercury defaults to /editor/*. You can check out what I have so far here: https://github.com/modeset/cmsimple

[DougPuchalski]

Thanks, I'll check it out. Mine's at https://github.com/aceofspades/caloris.

Good point about the routes, the docs are a little ambiguous as to whether that's been changed. If that won't work, I'll revert to using query params.

[DougPuchalski]

Looks like the RESTful routing issue is doable.

[DougPuchalski]

@jejacks0n The approach I'm leaning to now is where Rails.application.config.mercury_config would return a Proc--the layout would call it with the view_context so that the Proc could access helpers. In my implementation, the controller has loaded a page instance into the assigns. I can then use the named route helpers to generate toolbar URL's.

I can do this by overriding the mercury layout in my own code. But do you think it makes sense that Mercury should do this anyway? When generating the toolbar, seems like having access to the view context would be indispensable for lots of implementations.

[jejacks0n]

Yeah, we may consider moving some of that logic out of the view (layout) and into a helper, but yes I'm totally down with using a proc.

On Feb 26, 2012, at 12:38 PM, Doug Puchalskireply@reply.github.com wrote:

@jejacks0n The approach I'm leaning to now is where Rails.application.config.mercury_config would return a Proc--the layout would call it with the view_context so that the Proc could access helpers. In my implementation, the controller has loaded a page instance into the assigns. I can then use the named route helpers to generate toolbar URL's.

I can do this by overriding the mercury layout in my own code. But do you think it makes sense that Mercury should do this anyway? When generating the toolbar, seems like having access to the view context would be indispensable for lots of implementations.

---

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

[gvarela]

Instead of the application confitg you can also just turn the js config into an erb file where you would have access to all that any way. I've done this with translations in the past.

So make the generated mecury.js a mercury.js.erb file and change the paths to path helpers.

Gabe Varela 303-638-6576

On Feb 26, 2012, at 1:49 PM, Jeremy Jacksonreply@reply.github.com wrote:

Yeah, we may consider moving some of that logic out of the view (layout) and into a helper, but yes I'm totally down with using a proc.

On Feb 26, 2012, at 12:38 PM, Doug Puchalskireply@reply.github.com wrote:

@jejacks0n The approach I'm leaning to now is where Rails.application.config.mercury_config would return a Proc--the layout would call it with the view_context so that the Proc could access helpers. In my implementation, the controller has loaded a page instance into the assigns. I can then use the named route helpers to generate toolbar URL's.

I can do this by overriding the mercury layout in my own code. But do you think it makes sense that Mercury should do this anyway? When generating the toolbar, seems like having access to the view context would be indispensable for lots of implementations.

---

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

---

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

[DougPuchalski]

Agreed, a helper seems quite appropriate. Maybe the path helpers could take a hash param even if unused in the default implementation, since it's anticipated that something would get passed in--in my case, a reference to a page instance.

[DougPuchalski]

After implementing a bunch of features and changes, I've settled on using a .js.erb partial which I include in my layout. Some of the configuration is general, and other things are things that change by page, but this method should handle it well.