I have tryed to use an IFRAME as a target to display pdf, word docs and images in a central frame so i still have the menu, news, breadcrumb etc around it but have had no joy. It seems to screen everything up.
So at the minute i'm just opening then in a new window which in some ways is just as good.
I'm thinking of the furture when the release of MySource Matrix is available that keeps friendly urls for pdf's, word docs etc so that we can then edit their metadata etc. All to do with using the Simple Edit Interface for contributing documents etc. I want to create a design that has the company logo bar, login box, etc at the top then an iframe for the document to display in. Does this sound OK? If this is doable how will i then assign this design to the document so when the new window is opened from the link the document is displayed in the iframe?
There is nothing in the settings for a pdf to assign a design. Do you assign the design to the parent asset?
One of the reasons for this is we will have an edit button available when the user logs in so that they don't have to add /_edit to the end of the url.
Or is this complete crap and there is a better way to do this?
Any suggestions are welcome. We want to get were the contributors can add documents, update documents and set there metadata and status.
Using IFRAME to Display Docs
I'll just say that you cant assign designs to File assets (PDFs, DOCs etc) because they are not printed as HTML content. These files are served by the browser to your local machine. The fact they they open in the browser window is only because of the browser you are using. So this wont work for everyone.
Yeah i see that. But if i say to open it in a new browser window and then because of the browser or because of the way they want to open pdf's, word docs etc it then launchs the full Acrobat or MS Word i will still have a window with the company logo, login box, edit button etc. So we can they choose to edit the properties for that particular file. It is just the matter of assigning the design to the correct asset for this to happen.
If this isn't possible then does anybody have any other suggestions? I mean all the Simple Edit Interface functionality for a better CMS but we can't edit the properties for a pdf doc with out actually editing the url and adding /_edit.
I know the friendly URL thing is being looked at by you guys so some of this won't work on Live docs until that fix is released. But even then how do we get round this problem.
File assets do not respect designs applied to them, so I dont think your going to be able to do what you after.
How would i allow/get a contributor to edit a documents properties using the simple edit interface without having to get them to type /_edit on the end of the url for the document?
Hello,
Not sure if this is what you're after: You could add another div to each page that you want them to be able to edit, containing a link to _edit. Then set the read permission of the div as deny public access and grant access to your contributor users. So only your contributors will see the link, and they can just click to go to _edit.
Yeah we have this. When a user logs in then a edit button appears. But the problem we have is that when you display a pdf or word doc then don't display in a frame or whatever of the current window so therefor the edit button is there. You have to add /_edit to the end of the url. I've tried using an iframe instead of a div for the main content part of the design but this just screws the whole design.
I see this as a major point towards using the Simple Edit Interface for CMS. If a contributor has to add /_edit to the url for a pdf or word doc to get at it's metadata, details, etc then they aren't gonna like that. It just isn't friendly.
Create an asset listing that lists the PDFs/Words in a specific location and add /_edit to the %asset_url% keyword, so that the links automatically open into edit mode, like so:
[html]<a href="%asset_url%/_edit">Edit: %asset_name%</a>[/html]
In v3.6, asset listings can have multiple root nodes, so you will be able to use a single asset listing to list all of the file-based assets in your system (if you want). Or, you can use individual asset listings in particular locations for the same task.
Also, you can also use the show_if design area in v3.4 or higher to show/hide an "Edit this page" link depending on whether the user is logged in and has write access. This is integrated into the design itself and doesn't require an additional bodycopy or anything that tedious. 
Could you use the asset listings that are available to all users and add an image to the end of each line, for editing, if the current logged in user has right access?
Not at the moment, no – the asset listing currently doesn't allow conditional displays, though that would make a good feature request. However, it'd be a difficult thing to implement, because it would be a massive performance hit: for every asset being listed, we'd have to check the currently logged in user's permission against that asset.
Most of my clients have created an "authors" area – a place where all the simple edit tools are stored, that is only accessible after login. This includes asset builders to upload new files or create new pages, as well as asset listings to find/edit existing assets within the site. Remember, the site map is permissions-based already, so once you're logged in, a site map asset will show you the pages to which you have access. Couple that with a design-based "Edit this page" link, and its a pretty simple arrangement.
Sounds like the way to go. But we are unable to edit the properties of Live pdf's, word docs, etc in 3.4.1 because of the friendly url bug. Is this correct?
That's correct. Once you can maintain the Matrix URL, you should be able to access the simple edit mode for file-based assets.
Let me just add that the friendly URL option should be used a little as possible. Every time you tell the file asset to matain it's friendly URL, you are telling Matrix to serve that file rather than Apache. If you have a number of large popular files, this will really decrease the performance of the served files and will put more strain on your web server.
The firendly URLs option is not a solution for editing metadata for live file assets, its a solution for file assets that must have a friendly URL because the files are expected to be in a certain location (eg. robots.txt).
I might be missing something here. But if i don't use the Friendly URL option how do users use the Simple Edit Interface to edit the metadata of a Live document?
They dont. You're not missing anything.
The simple editing interface has limitations - thats why it's simple You cant do everything in the simple editing interface that you can in the admin interface - and you can do even less for file assets.
Wait, so is there a way to prevent certain pages from the using simple edit interface, and only allow backend editing of the page? And if that is the case, would Apache serve the file, rather than Matrix? I am confused about this, is Matrix always dynamicly generating all pages, and Apache only serves files like pdf, and doc? Or is there a case where I can have Apache serve my Matrix pages also? If so, it would be great, my test machine seems slow while serving pages, and I am worried about speed when moving this to a production enviroment.
Matrix (by default) allows Apache to serve all binary files (i.e. pdfs, docs, images – files that are uploaded to Matrix) that are Live with Public Read permissions (by using the __data URLs). These are the only assets that are slightly more difficult to edit using the Simple Edit interface, as their Public URLs will not trigger the interface. Rather, you have to use the alternative limbo_assetid method of calling the interface.
This does not occur for content delivered by Matrix (i.e. Page-based assets created within Matrix itself). These assets are always generated by Matrix. However, for performance, you should enable the Matrix Cache Manager (in the System Management folder) and at least enable Public Level caching. This allows Matrix to cache out content for faster delivery.