Hi,
as for Veikkos problem: Instead of setting the output type in
view::initialize() the view could just define a generic execute()
which forwards to itself with the proper OT. Same effect, just a
single roundtrip more. Considering this is an error condition which
should not be reached in the majority of cases I'd say it's a good
tradeoff for a cleaner and more consistent implementation.
cheers
felix
On Jan 15, 2009, at 4:35 PM, David Zülke wrote:
Hi Manuel,
no, that would still work fine, both with and without caching. The
actual forward occurs much later, and is not affected by this change.
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...)
Nice Catch-22, ain't it... (but a welcome change; most annoying
decisions revolve around naming things, like in anything computer
science :p)
- David
Am 15.01.2009 um 15:43 schrieb Manuel Giesa:
Hi David,
would this affect forward containers? I my particular case i have
an action wich has a special output type compared to the rest of
the application. But in an error case i create a forward container
to my something went wrong action with a different output type.
Manuel
___
users mailing list
users@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users
___
users mailing list
users@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users
--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix.gilc...@bitextender.com
http://bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever
smime.p7s
Description: S/MIME cryptographic signature
___
users mailing list
users@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users
