Without a very deep reflection on this, yes of course, the phase-id
should go d'accord with the originating command.
I don't see why this would break the spec. It's probably just
something nobody has thought about.
regards,
Martin
On 1/22/06, Volker Weber <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I had a problem with the immediate flag of a Button which is located
> inside a popup-panel which was attached as a facet to another button.
>
> According to the spec the queueEvent() method of UICommponent should
> delegate the event to the parents component queueEvent() method until
> UIViewRoot is reached.
>
> In UICommand additionally the phaseId is set dependent to the immediate
> flag.
>
> The resulting phaseId on the event is, in current implementation,
> dependent to the state of the immediate flag of the outer UICommand
> component, not to the immediate state of the originating UICommand.
>
> I have tested (not looked into the source) also with RI, the behavior is
> the same.
>
>
> IMO this is a bug, the phaseId of a Action should depend on the
> originating UICommand, and i can't find that nesting UICommands is not
> allowed.
>
> Could/should we fix this, i thought about something like
>
> if (event.getSource() == this) {...}
>
> or will this break the TCK tests?
>
> Any thoughts?
>
> Regards,
> Volker
>
> P.S.: I fixed my problem by moving the popup tag to outside of the
> command tag, but the general problem still exists.
>
> --
> Don't answer to From: address!
> Mail to this account are droped if not recieved via mailinglist.
> To contact me direct create the mail address by
> concatenating my forename to my senders domain.
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
