Rupert Redington wrote:
> The utility is responsible for generating a PDF snapshot of a view - as
> seen by the invoking user at the point when the utility is invoked. To
> do this I open an HTMLDOC subprocess which needs a url to go to, and
> which needs to know which user to pretend to be so that it can
> authenticate... This is indeed all very ugly, but I needed it done and
> couldn't think of a better way at the time.

Right, but your choice of a utility component is debatable. If it needs
the request, it should be a view (or a resource).

Why not create a view for IBrowserView? Then you can get PDF snapshots
of arbitrary views with URLs like
http://host/someobj/@@index.html/@@pdf. @@pdf is a view for a view and
would look like this:

  class PDFView(BrowserPage): # or BrowserView

      def __call__(self):
          html = self.context()  # get the HTML of the view
                                 # you want as a PDF
          pdf = html2pdf(html)   # 'html2pdf' is obviously
                                 # something you're doing now
          return pdf

> I can't help feeling that to say that a utility should never ever
> concern itself with URLs is unnecessarily restrictive.

I don't think it is. Utilities perform a well-defined task on Python API
level. URLs just aren't their concern. For example, it might still make
sense to facilitate URLs in the above example:

      def __call__(self):
          html = self.context()  # get the HTML of the view
                                 # you want as a PDF
          pdfgenerator = getUtility(IPDFGenerator)
          return pdfgenerator.fromHTML(html)

As you can see, the utility still does what it's actual task
is--generating PDF--but only that. That's the point of the Component
Architecture. This utility, for example, would now be usable outside
even a web app where there are no URLs and no requests...

>>> Furthermore I sometimes find myself using this in event subscribers - I
>>> can't see any way to get request data from an event...
>> Why would you want to? If you really want to use events, throw an event
>> that also holds on to the request. I still think that this wouldn't be
>> necessary in most cases.
> I sometimes send out an email from an event handler and
> getInteraction().participations[0].principal.title is a convenient way
> to tell the recipient of the mail who it was that initiated the
> change... (from John's post I begin to understand that I might find the
> actors details stored in an annotation (if its an annotatable content
> object thats been altered))

Yes, getting the data from DublinCore is a good idea.

Zope3-users mailing list

Reply via email to