-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Zülke wrote:
> But it brings up an interesting point, thanks for that. Veikko asked
> much the same thing on IRC; he shows an HTML error page when a PDF
> cannot be generated.
>
> Right now, a convenient way to do that would be to simply do
> $container->setOutputType('html'); in YourErrorView::initialize() to set
> back the output type to HTML, no matter what the output type currently
> is. That wouldn't be possible anymore and would have to be done by doing
> the forward you're describing (kudos for having such clean code!)
>
> It might be worth noting that we wouldn't have to actually *prevent* the
> Output Type from being set. That means the quick-and-dirty-solution
> above *could* still work. We'd simply change things inside the framework
> so it doesn't care, and when you then use caching, things would act
> wonky. That would preserve flexibility (and 99.97% of BC, I presume),
> but might also be a potential source for WTF moments. But of course, we
> could throw an exception if we detect an output type change while trying
> to cache something. I guess that would work best, and basically mean
> that the functionality is only disabled in combination with caching.
> Which I, on the other hand, do not like, because a system should never
> force a user to bother with implementational details or optimizations
> (PHP has enough of that, I'm not keen on repeating those mistakes,
> besides the fact that it simply makes me angry...)
The problem is that code like Veikko's (and likely much worse, that
doesn't sound so bad) clearly exists. While I always encourage
"preserving flexibility," I really don't like the prospect of the WTF
situation that has the potential to arise.
I think the fundamental issue that I'm having is that I don't see any
architectural unsoundness with an application that sets its output types
in ::initialize(). The conditionality that PHP provides is far more
complete than both what our XML configuration handlers and what our
routing handlers can accept.
So I would see throwing an exception when caching is enabled and the OT
is changed as a *temporary solution* to a more salient problem of how
caching and our execution filter should really work together. Maybe this
is something we can resolve in 1.1 with the storage framework or in a
later version by revamping parts of the caching subsystem, the execution
filter, or both.
> Nice Catch-22, ain't it... (but a welcome change; most annoying
> decisions revolve around naming things, like in anything computer
> science :p)
Maybe the problem is that the whiteboard isn't big enough to hold all
the possibilities. :)
Regards,
Noah
- --
Noah Fontes
Bitextender GmbH
http://www.bitextender.com/
Phone: +1 919 349 9826
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAklvYkcACgkQhitK+HuUQJRgIwCdH5IeWiG9tQKbVUefMKhyk5I6
7p4AnjW0S4JiZZ0J15meYinj2nMNsgMS
=GfW2
-----END PGP SIGNATURE-----
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
