Re: Printer friendly pages

--- On Tue, 5/13/08, Thijs Kinkhorst <[email protected]> wrote:

> > But now my question is: how a plugin is supposed to
> > change the layout of the message before it is printed.
> > I.e. what if you don't want the printed message to look
> > exactly in the same way it is displayed (what if you want
> > less header fields, for example ?...) ?
> 
> > I vote strongly against this change, and kindly
> > request to have it reverted.
> 
> I genuinely think that would be a step in the wrong direction. This is
> not "just another way to do it", it fully alligns with the goal of
> separating code (what it does) and display (how it looks). Printer
> friendly is definately just a means of presentation, not logic. CSS is
> the way to go here, as it is when developing e.g. a mobile phone
> equivalent or one for people with bad eye sight.
> 
> I understand your concerns, but I think the right solution is to find a
> way to embed them within this framework rather than reverting it.
> 
> If you want to display some fields differently or not at all, css is
> your friend and will actually make it easier to do that, rather
> than to hack away at the old printer friendly code. In fact, you can
> completely revamp the print.css stylesheet so that printer friendly
> looks exactly the way you want it to be, without intermingling with
> core code.
> 
> If you don't want to edit print.css but want all code to be confined to
> your plugin purely, it is possible to add a custom css to the
> page header with your media=print definitions.
> 
> If the current template set doesn't have the right css classes to fully 
> express what you want, we can of course see if that can be changed, I
> don't expect much problems there.
> 
> All in all, I believe that this is a great improvement, maybe even more
> for custom print friendlies rather than less.

I'm afraid it is way more complicated than that... The formal messages I am dealing with in my plugin got a very complex set of headers, many of which are actually stored as base64 encoded XML, in a X-RDF field. Each, the read_body.php and printer_friendly_bottom.php files which are particular to my plugin (I use hooks to make SQM switch to them when dealing with formal messages), use different routines to decode different fields from the XML, for example. This is also complicated by the fact that while in the workflow circuit (i.e. as long as the message was not sent and is still to be approved by one or several authorities before it is), the message body looks like the one of a normal email (and then I need more or less all the header fields showing and printed), while once sent (or when
  received from another authority), the body takes the shape of an HTML form with some of the header fields repeated in its own header (this is so someone not using a
 Melinda-compatible MUA may still read those fields in the final message, while they would be unknown to their MUA), and of course, I don't want the corresponding fields in the header to be printed along the HTML form: it is plain useless and takes space on the paper.
To give you another example, while still in the workflow circuit, the messafe "To:" field will bear the address of the next person to sign it, while in the XML, the "TO" recipent(s) will be the authority(ies) you wish your message to be sent to... when printing the message, you really don't care about the "To:" field of the standard SMTP header, but want instead to see to whom the message will be delivered once approved... but on the other hand, you will want to know who already signed the message, and who must still sign it, and this data is presented as a workflow table after the body of the message... again something to build before printing the message...

I could multiply the examples, but to make the story short, let's just say that I do need a smart processing of the message data to be printed, and this just plain can't be done with CSS.

It's not as much about HOW the printed message will look than WHAT should be printed, and/or in what order.

By removing this possibility for plugin writers in the name of a principle you are making SQM less interesting for people and organisations such as mine...

So if you don't reverse the patch, I will have no choice but to keep my own reversal patch and provide it as a mandatory patch for allowing the Melinda plugin to work properly, with all the risks for maintainability it involves... :-(

Please also note that Melinda is being developped under the GPL and although it has not yet been released to the public (it's a big project, and SQM is only a component in it, along plugins for Thunderbird, a workflow engine for Postfix, an archival system and much more: still a lot to do and still a moving target as far as the specifications go), it will end up on Sourceforge one day or another. So the less incompatibilities and the less exotic patches, the better for all of us...

Regards,

Thierry.


      


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel