Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I hope this won't be too silly of a question.
I had never looked at the 'Print View' button in /activities/one.php closely before. I naively thought 'Who prints these days?!' and was happy to know it is there. Until it recently turned out that a client of mine needs to print out the details of certain activities on a regular basis. 'No problem', I said, and clicked on 'Print View'. Surprise! The output is more or less the same as the 'edit_view', with all of its editable fields and checkmarks, drop-down menus, buttons, etc. The printer output of a simple activity with a couple of lines in the notes ended up 3 pages long!
Maybe the 'Print View' was intended for some other purpose and the button is misnamed or maybe the 'Print View' was never written… Can anyone tell me which of those it is?
Since the client needed the functionality ASAP, I put together a simple printer-friendly output template that I linked into /activities/one.php so life is now good again.
My question is whether others would find this useful in XRMS so I can contribute that back to the project? If so, how would you like me to hook it in? In the client's deployment, I replaced the built-in 'print_view' with the new printer-friendly output template so I call that with the 'Print View' button. Yet, I cannot be too sure if this button was somehow intended for something else that I have not yet grasped…
Oh, life was so simple when we still scratched on clay tablets ;)
My memory is hazy, but I'd say go ahead and commit the code.
Thank you for the prompt response!
I am having second thoughts about committing this template just yet. It was put together very hastily and I simply used CSS to hide the elements I did not want to show up in the print preview. This is not a deadly sin in itself. However, I needed a quick fix and, since I was having trouble loading the CSS of the print-preview on demand, I ended up including it inline. Now, in my book, this IS a deadly sin and, while it may have gotten me out of hot water, it is not a good way to do things long-term.
XRMS's start_page() function does not allow additional CSS to be added to the HTML HEAD on demand and, outside of copying and pasting its code in the print preview page and then bastardizing it just to add the CSS, I do not see a different way to access the HTML HEAD.
Any ideas if there is another approach I can use? I looked over utils-interface but did not seem to find anything… If no other approach is available, I could extend the start_page function with an additional optional parameter to load CSS files on request… it should not break anything else.
If I can load the print-preview CSS dynamically in the HEAD, where it should be, I would be far more comfortable to have the template code out there.
Isn't there already code in there that loads a print view CSS? I'm not at a computer with the code installed handy, but that's my recollection.
Thank you for the quick response! The start_page() function does load the /css/print.css stylesheet, however, that is system-broad, the same for every page, and is directed for printer output only (@media print). I wanted to make the screen output resemble the print output as a true preview would.
What I want to do essentially is to load a separate stylesheet for a single page within XRMS but I don't necessarily want to bypass or manually recreate the start_page() function. That is why I am thinking that, unless there is another mechanism that would allow me to load a custom CSS in the HTML HEAD at will, it may not be a bad idea to provide that as an optional parameter to the start_page() function. This will also allow creating other pages (or even groups of pages) in XRMS that would appear different than the standard XRMS UI.