>>>>> On Mon, 8 Jul 2013 10:45:51 -0400 (EDT), Ken Finnigan <kfinniga_at_redhat.com> said:
KF> On line 260 of FlashELResolver, in Mojarra 2.2.0, it makes a direct
KF> call to ELFlash to set a flag.
KF> This prevents a developer from developing their own Flash
KF> implementation, that can be retrieved from the FlashFactory, and
KF> have it function as expected within the FlashELResolver.
KF> On closer inspection of the flag being set on ELFlash, it appears to
KF> only be used within the ELFlash.get() method. However, the structure
KF> of the code within that method means that whether the flag is set or
KF> not, the result of the get() method will be identical, as both
KF> situations result in a call to
KF> ELFlash. getPhaseMapForReading().get(key).
While I concur with your assertion that getPhaseMapForReading().get(key)
is called in both cases, the state of the keep flag clearly has a
purpose. If it is set, then the get() has the side-effect of causing
keep() to be called on the key. Otherwise, this side-effect does not
happen in get().
KF> I have a two fold question around this:
KF> 1) Can we remove the direct usage of ELFlash from FlashELFactory?
KF> 2) And is the best way to remove that direct usage by simply
KF> removing the setKeepFlag() method, and associated get and clear,
KF> from ELFlash? As opposed to adding methods onto Flash.
I don't feel comfortable doing that because then the semantics of keep
would be changed.
>>>>> On Mon, 15 Jul 2013 16:04:10 -0400, Neil Griffin <neil.griffin_at_portletfaces.org> said:
NG> However, if developing class with the new JSF 2.2 FlashWrapper, then
NG> it might be possible to have the FlashFactory return something that
NG> simply decorates the Mojarra ELFlash where necessary. I'm not 100%
NG> sure, but I think that might be enough in most cases.
While it is true that one could decorate like this, Ken's observation of
this tight coupling still applies when one chooses not to decorate,
which is a valid choice in any other factory type thing.
When we specified the flash in 2.0, we required that implementations
honor a top level EL implicit object called "flash", but we did not
require this be implemented using a FlashELResolver. This is an
implementation choice.
I think we need to expand the responsibilities of the FlashFactory here,
which means this is a spec change. Clearly this is a case where the
ELResolver that handles expressions involving the flash and the flash
instance vended by the FlashFactory need to collaborate. Neil, can you
file a spec issue?
Thanks,
Ed