Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-240
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: ajesse
Votes: 2
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

more events from the framework

Created: 07/Feb/07 04:23 PM   Updated: 24/Jan/14 09:47 PM
Component/s: Lifecycle
Affects Version/s: 1.1
Fix Version/s: 2.3

Time Tracking:
Not Specified

File Attachments: 1. Text File message.txt (38 kB) 12/Feb/08 02:59 PM - Ed Burns
2. Text File message.txt (37 kB) 12/Feb/08 01:05 PM - Ed Burns

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency
 

Issuezilla Id: 240
Status Whiteboard:

EGTop5 effort_moderate cat2 frame size_medium importance_large draft

Tags:
Participants: ajesse, Ed Burns and Ryan Lubke


 Description  « Hide

Often it would be usefull be able to attach a event-listener to the jsf-
framework. But the framework does not fire events...
Eg: after successfull initialization I would like to get a event with a
reference to the completed runtime-config > I could register used custom
components (eg. for license fees), during dev: dump out the complete config-info
Or: after a successfull component-tree-creation a event carying a reference to
the component-tree -> I could check whether I need to inject some values into
managed beans used in the components in the tree (an idea for a http-GET
interface)

Most probably other events might prove usefull as well...



Ed Burns added a comment - 06/Mar/07 11:31 AM

This issue is already on the list of issues to be addressed in JSF 2.0.


Ed Burns added a comment - 12/Feb/08 01:05 PM

Created an attachment (id=123)
First part of fixing this bug, first iteration.


Ed Burns added a comment - 12/Feb/08 02:59 PM

Created an attachment (id=124)
First part of fixing this bug, second iteration.


Ed Burns added a comment - 20/Feb/08 11:05 AM

290 blocks this.


Ryan Lubke added a comment - 20/Aug/08 02:11 PM

Depends on 178.


Ryan Lubke added a comment - 20/Aug/08 02:12 PM

Adding 443 as dependency.


Ryan Lubke added a comment - 20/Aug/08 02:24 PM

Also consider a ComponentCreatedEvent.


Ryan Lubke added a comment - 09/Sep/08 10:13 AM

Request from a 314 observer:

---------------------------------------

I did not able to send this email to JSR-314 EG because not member of
it. But I think maybe useful to add two other listener
and event to the Kito D. listener list; these are

  • ConverterInvokedEvent/ConverterInvokedListener

public ConverterInvokedListener extends EventListener{ public void beforeConverterInvoked(ConverterInvokedEvent event) ; public void afterConverterInvoked(ConverterInvokedEvent event); }

public ConverterInvokedEvent extends EventObject{ public FacesContext getContext(); public String getEventType(); //Before or After public boolean isExceptionThrown(); //If converter exception throws public ConverterException getException(); public UIComponent getComponent(); }

  • ValidatorInvokedEvent/ValidatorInvokedListener

public ValidatorInvokedListener extends EventListener{ public void beforeValidatorInvoked(ValidatorInvokedEvent event) ; public void afterValidatorInvoked(ValidatorInvokedEvent event); }

public ConverterInvokedEvent extends EventObject{ public FacesContext getContext(); public String getEventType(); //Before or After public boolean isExceptionThrown(); //If converter exception throws public ValidatorException getException(); public UIComponent getComponent(); }


Ed Burns added a comment - 13/Oct/08 07:37 AM

Will mark 491 as dup of this.


Ed Burns added a comment - 13/Oct/08 07:38 AM
      • Issue 491 has been marked as a duplicate of this issue. ***

Ed Burns added a comment - 06/Feb/09 01:17 PM

ConverterInvokedEvent

I assert that we don't need this since we have the validate events.

ComponentCreatedEvent

I assert that we don't need this because you could decorate Application
and override its createComponent* methods.


Ed Burns added a comment - 03/Apr/09 05:31 AM

We should have system events for pre and post every lifecycle phase.


Ed Burns added a comment - 30/Jun/09 10:26 AM

From: Gurkan Erdogdu <gurkanerdogdu@yahoo.com>
Sender: dev-return-1710-ed.burns=sun.com@javaserverfaces.dev.java.net
To: dev@javaserverfaces.dev.java.net
Subject: Re: [240-Megalisteners] Naming
Date: Mon, 14 Apr 2008 10:02:33 -0700 (PDT)
Content-type: multipart/alternative;
boundary="Boundary_(ID_uuZw7vnbr+OC0VpICackyA)"
MIME-version: 1.0

Yeap. If not getting exception than able to get this from event.

public void beforeConverterInvoked(ConverterInvokedEvent event){
public Object getLocalValue(); // Gets the local, unconverted value
}

public void afterConverterInvoked(ConverterInvokedEvent event){
public Object getConvertedValue(); //Gets the converted value after conversion
}

Thanks;

Gurkan


Ed Burns added a comment - 24/Sep/09 08:17 AM

Move to 2.1


Ed Burns added a comment - 24/Nov/09 07:40 AM

Prepare to delete api subcomponent


Ed Burns added a comment - 14/Dec/09 08:59 AM

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.


Ed Burns added a comment - 02/Mar/10 05:14 PM

At JSFdays last week, Leonardo Uribe suggested we add events for iterating components. Iteration
begin, etc.


Ed Burns added a comment - 04/Mar/10 12:45 PM

cat2


Ed Burns added a comment - 17/Mar/10 02:14 PM

frame


Ed Burns added a comment - 22/Mar/10 06:36 AM

lifecycle


Ed Burns added a comment - 15/May/10 07:54 AM

These are targeted at 2.1.


Ed Burns added a comment - 08/Jun/10 01:52 PM

triage


Ed Burns added a comment - 24/Jun/10 02:41 PM

GlassFish 3.1 M6 at the latest.


Ed Burns added a comment - 24/Jun/10 02:55 PM

Move these to M5


Ed Burns added a comment - 30/Aug/10 12:11 PM

Move these to 2.2


Ed Burns added a comment - 23/Sep/10 09:15 AM

Another event that we need is one that allows the installation of a client side JavaScript listener that will be
called, on the client side when the user tries to navigate away from the current view. The listener must
have the ability to veto the navigation. This feature could be used to allow developers to throw up a modal
dialog saying something like, "you have unsaved changes in this page, are you sure you want to discard
them?" and have the chance to cancel the navigation.