The Rise and Rise of Contextual Events (or the birth of Implicit Contextual Events)
527 views
Skip to first unread message
Chris Muir
Aug 1, 2010, 11:36:42 PM8/1/10
to ADF Enterprise Methodology Group
Hi everyone
I've been struggling with JDeveloper 11g's Contextual Events for a
little while now, not in the technical implementation sense, but from
the design perspective. I'd like to share my thoughts with the group.
Between JDev 11g versions we've seen the support for Contextual Events
improve. In the early vanilla 11g versions the IDE had little design
time support, and the documentation was nearly none existent. In the
latest versions the IDE has certainly improved (though I still think
it has some way to go), the documentation has improved (though I still
think it has some way to go), and luckily today there's nearly a
million blogs (give or take a few) on using Contextual Events, which
makes up for the IDE and documentation limitations.
So what have I been struggling with?
Our application architecture under 11g has multiple ADF Library BTFs
loaded into a master application. We've now two 11g production
systems. The "red letter moment" in our BTF design was when we
realised that each BTF needed a standard set of BTF parameters (tailor
fitted to our application), along with a set uniquely required for
each BTF. This made it easy to dictate to the BTF programmers what
they had to work with in terms of parameters, and in turn what they
needed to tell the master ADF application programmer to supply them in
addition if not already supplied.
Both these 11g systems were simple enough from a BTF interaction point
of view that they didn't require Contextual Events. Yet our next
system under design and prototyping certainly does.
As readers of the ADF EMG will know, up to now most documentation and
demonstrations on Contextual Events consider that they can be used to
pass data between BTFs/regions based on value change or action
events. That's all good and well and I've that working numerous
times, the technique works.
But, unlike the BTF parameters above, I'm currently missing my "red
letter moment" in identifying a generic set of events to raise from
each BTF. In other words, from a design point of view, I haven't yet
been able to produce much guidance on what events I think all our BTF
programmers should be raising by default, along with specific events
needed for each BTF.
So at this point I'd like to raise the question to the group please,
has anybody discovered besides just passing data between regions a
specific set of Contextual Events that appear to be repeating over
multiple BTFs? Maybe events you can imagine raised and handled in all
of your future applications? In turn maybe events that *all* of our
applications should be raising?
To give an example, the ADF UI Shell has a "dirty transaction" feature
that when enabled for a BTF, wont allow the user to close the BTF
without acknowledging a dialog box. This is ideal for warning users
that they have outstanding work to commit. Yet from a design point of
view we don't really want the UI Shell to dictate the "dirty
transaction" as it's the BTF that inherently knows when the user has
muddied the transaction. This therefore makes an ideal "generic
Contextual Event" that all BTFs should raise, that consuming master
ADF applications can make use of.
Anybody have any more examples to share?
This does make me wonder are we likely to see in future ADF releases,
the framework inherently raise some contextual events on our behalf,
effectively "Implicit Contextual Events"? And it's this realisation
that makes me think somewhat excitedly, ADF is at a catalyst moment,
because if we see the concept of Implicit Contextual Events introduced
some time in the future, guess which other Oracle architecture/
solution is very similar to that model?
A clue: triggers.
Keen to hear everyones' thoughts.
Regards,
CM.
I've been struggling with JDeveloper 11g's Contextual Events for a
little while now, not in the technical implementation sense, but from
the design perspective. I'd like to share my thoughts with the group.
Between JDev 11g versions we've seen the support for Contextual Events
improve. In the early vanilla 11g versions the IDE had little design
time support, and the documentation was nearly none existent. In the
latest versions the IDE has certainly improved (though I still think
it has some way to go), the documentation has improved (though I still
think it has some way to go), and luckily today there's nearly a
million blogs (give or take a few) on using Contextual Events, which
makes up for the IDE and documentation limitations.
So what have I been struggling with?
Our application architecture under 11g has multiple ADF Library BTFs
loaded into a master application. We've now two 11g production
systems. The "red letter moment" in our BTF design was when we
realised that each BTF needed a standard set of BTF parameters (tailor
fitted to our application), along with a set uniquely required for
each BTF. This made it easy to dictate to the BTF programmers what
they had to work with in terms of parameters, and in turn what they
needed to tell the master ADF application programmer to supply them in
addition if not already supplied.
Both these 11g systems were simple enough from a BTF interaction point
of view that they didn't require Contextual Events. Yet our next
system under design and prototyping certainly does.
As readers of the ADF EMG will know, up to now most documentation and
demonstrations on Contextual Events consider that they can be used to
pass data between BTFs/regions based on value change or action
events. That's all good and well and I've that working numerous
times, the technique works.
But, unlike the BTF parameters above, I'm currently missing my "red
letter moment" in identifying a generic set of events to raise from
each BTF. In other words, from a design point of view, I haven't yet
been able to produce much guidance on what events I think all our BTF
programmers should be raising by default, along with specific events
needed for each BTF.
So at this point I'd like to raise the question to the group please,
has anybody discovered besides just passing data between regions a
specific set of Contextual Events that appear to be repeating over
multiple BTFs? Maybe events you can imagine raised and handled in all
of your future applications? In turn maybe events that *all* of our
applications should be raising?
To give an example, the ADF UI Shell has a "dirty transaction" feature
that when enabled for a BTF, wont allow the user to close the BTF
without acknowledging a dialog box. This is ideal for warning users
that they have outstanding work to commit. Yet from a design point of
view we don't really want the UI Shell to dictate the "dirty
transaction" as it's the BTF that inherently knows when the user has
muddied the transaction. This therefore makes an ideal "generic
Contextual Event" that all BTFs should raise, that consuming master
ADF applications can make use of.
Anybody have any more examples to share?
This does make me wonder are we likely to see in future ADF releases,
the framework inherently raise some contextual events on our behalf,
effectively "Implicit Contextual Events"? And it's this realisation
that makes me think somewhat excitedly, ADF is at a catalyst moment,
because if we see the concept of Implicit Contextual Events introduced
some time in the future, guess which other Oracle architecture/
solution is very similar to that model?
A clue: triggers.
Keen to hear everyones' thoughts.
Regards,
CM.
Jan Vervecken
Aug 2, 2010, 5:17:18 AM8/2/10
to ADF Enterprise Methodology Group
hi Chris
Thanks for this interesting post. Currently I don't have any specific
experience to share that could answer your questions.
What I have been wondering is how the API for a specific task-flow
(parameters, events, and other aspects) can be best communicated to
the task-flow client developer.
Even if Frank Nimphius describes it as "a good way to look at task
flows is as a service with a UI attached to it ... parameters are the
contract ..." ...
at http://forums.oracle.com/forums/message.jspa?messageID=4454273#4454273
... besides the parameters, its events are a relevant aspect of its
API.
Also Duncan Mills point out in "An Oracle White Paper - June 2010 -
Task Flow Design Fundamentals " ...
at http://www.oracle.com/technology/products/jdev/11/collateral/adf_task_flow_design.pdf
... that "... The developer needs to understand in which ways a task
flow can “leak.” or otherwise depend on external information. ..."
... and points out about events "... It goes without saying that
contextual events provide an extremely powerful tool in the task flow
designers armory and should be fully documented, ..."
... but how this documenting should be done best, remains unclear
(e.g. think about what WSDL can do in other contexts in terms of
documenting API).
Since your questions about events seem related to communicating a
specific task-flow API, it made me wonder again if some more explicit
support in the technology/framework and/or design-time (although not
sure what all this should look like) could help improve the
communication about a specific task-flow API ... which could soften
the need for "Implicit Contextual Events" because every event would be
a clear part of a specific task-flow API.
regards
Jan Vervecken
Thanks for this interesting post. Currently I don't have any specific
experience to share that could answer your questions.
What I have been wondering is how the API for a specific task-flow
(parameters, events, and other aspects) can be best communicated to
the task-flow client developer.
Even if Frank Nimphius describes it as "a good way to look at task
flows is as a service with a UI attached to it ... parameters are the
contract ..." ...
at http://forums.oracle.com/forums/message.jspa?messageID=4454273#4454273
... besides the parameters, its events are a relevant aspect of its
API.
Also Duncan Mills point out in "An Oracle White Paper - June 2010 -
Task Flow Design Fundamentals " ...
at http://www.oracle.com/technology/products/jdev/11/collateral/adf_task_flow_design.pdf
... that "... The developer needs to understand in which ways a task
flow can “leak.” or otherwise depend on external information. ..."
... and points out about events "... It goes without saying that
contextual events provide an extremely powerful tool in the task flow
designers armory and should be fully documented, ..."
... but how this documenting should be done best, remains unclear
(e.g. think about what WSDL can do in other contexts in terms of
documenting API).
Since your questions about events seem related to communicating a
specific task-flow API, it made me wonder again if some more explicit
support in the technology/framework and/or design-time (although not
sure what all this should look like) could help improve the
communication about a specific task-flow API ... which could soften
the need for "Implicit Contextual Events" because every event would be
a clear part of a specific task-flow API.
regards
Jan Vervecken
Chris Muir
Aug 2, 2010, 9:21:20 PM8/2/10
to ADF Enterprise Methodology Group
Hi Jan,
I appreciate your point, well made. I guess for TF parameters they
are published in the relating TF xml file and so are clearly defined
to the outside world (though I wish the Resource Palette would show
these without me having to open the TF). However Contextual Events
aren't as you describe. Like your WSDL analogy, it seems like a good
idea to me that they should be, to make it clear to the consuming
application (or programmer) what's being communicated/available from
the child TF.
I have a slight worrying tickle in the back of my head, that any of
these sort of bright ideas might be a bit too late. As we know Fusion
Apps is just around the corner, and I suspect we'll see a strong push
in JDev in (near) future releases to not include any new major
features as not to upset the stability of the built Fusion Apps. You
could imagine for Oracle's several thousand built task flows in Fusion
Apps, putting in a requirement that the Contextual Events first be
registered in the task flow xml file, would cause a few issues. But
you never know, maybe this feature is planned for JDev 12g.
It's a good idea. If one of the Oracle team don't follow up in the
next few days, I'll try and ask somebody to participate.
Cheers,
CM.
On Aug 2, 5:17 pm, Jan Vervecken <verv...@gmail.com> wrote:
> hi Chris
>
> Thanks for this interesting post. Currently I don't have any specific
> experience to share that could answer your questions.
>
> What I have been wondering is how the API for a specific task-flow
> (parameters, events, and other aspects) can be best communicated to
> the task-flow client developer.
>
> Even if Frank Nimphius describes it as "a good way to look at task
> flows is as a service with a UI attached to it ... parameters are the
> contract ..." ...
> athttp://forums.oracle.com/forums/message.jspa?messageID=4454273#4454273
I appreciate your point, well made. I guess for TF parameters they
are published in the relating TF xml file and so are clearly defined
to the outside world (though I wish the Resource Palette would show
these without me having to open the TF). However Contextual Events
aren't as you describe. Like your WSDL analogy, it seems like a good
idea to me that they should be, to make it clear to the consuming
application (or programmer) what's being communicated/available from
the child TF.
I have a slight worrying tickle in the back of my head, that any of
these sort of bright ideas might be a bit too late. As we know Fusion
Apps is just around the corner, and I suspect we'll see a strong push
in JDev in (near) future releases to not include any new major
features as not to upset the stability of the built Fusion Apps. You
could imagine for Oracle's several thousand built task flows in Fusion
Apps, putting in a requirement that the Contextual Events first be
registered in the task flow xml file, would cause a few issues. But
you never know, maybe this feature is planned for JDev 12g.
It's a good idea. If one of the Oracle team don't follow up in the
next few days, I'll try and ask somebody to participate.
Cheers,
CM.
On Aug 2, 5:17 pm, Jan Vervecken <verv...@gmail.com> wrote:
> hi Chris
>
> Thanks for this interesting post. Currently I don't have any specific
> experience to share that could answer your questions.
>
> What I have been wondering is how the API for a specific task-flow
> (parameters, events, and other aspects) can be best communicated to
> the task-flow client developer.
>
> Even if Frank Nimphius describes it as "a good way to look at task
> flows is as a service with a UI attached to it ... parameters are the
> contract ..." ...
> ... besides the parameters, its events are a relevant aspect of its
> API.
>
> Also Duncan Mills point out in "An Oracle White Paper - June 2010 -
> Task Flow Design Fundamentals " ...
> athttp://www.oracle.com/technology/products/jdev/11/collateral/adf_task...
> API.
>
> Also Duncan Mills point out in "An Oracle White Paper - June 2010 -
> Task Flow Design Fundamentals " ...
fnimphiu
Aug 3, 2010, 6:12:10 AM8/3/10
to ADF Enterprise Methodology Group
Chris,
for the book Lynn and I wrote, I spent a good portion of my time spent
for chapter 6 investigating into contextual events to a time in which
even internally documentation consisted of reading source code.I also
filed bugs that lead to better visual support for contextual events.
Still, as you say it, there is a lot more we can do here. My
experience by the way is to first try and understand how to manually
set up contextual events up before you start using the declarative
options (at least when your goal is to better understand what's
behind).
"This does make me wonder are we likely to see in future ADF
releases,the framework inherently raise some contextual events on our
up the ADF PageDef chain to broadcast the message to directly
registered listeners (aka. consumers (though they don't consume the
event)) to then,turn around to bubble down the chain, to broadcasti
the message to all sibling PageDef files just in case there is a wild
card consumer registered. You can imagine what happens if events are
blindly published though nobody cares (what a waste of energy). So
better is a meet in the middle solution in which developer explicitly
enable implicit events.For this I think there a specific feature
missing: discoverability. When adding a BTF from a library how do I
know which event this is listening for or broadcasting. This is not a
trivial task because a BTF can have hundreds of ADF bound page
fragments, each of which can be sending or listening for events. So
exposing a list on the BTF task flow call activity or ADF Regions may
be too much of an overkill.
I like to jump onto this thread (sorry Chris) and ask the community
what they would think how inter-region communication (aka contextual
event) should be improved in terms of registration, subscription,
implicit events and design time improvements, Unfortunately it seems
that there is no good uptake of contextual events yet (as I can tell
from questions on OTN and the internal lists).
Maybe we can start with a list of use cases that you see contextual
events make sense to be used in. Once we have the use cases, we can
think about what the event and the payload is that would be
broadcasted. Based on this - hopefully - we are able to determine a
common set of events that may make good candidate for Chris's vision
of implicit events.
Frank
for the book Lynn and I wrote, I spent a good portion of my time spent
for chapter 6 investigating into contextual events to a time in which
even internally documentation consisted of reading source code.I also
filed bugs that lead to better visual support for contextual events.
Still, as you say it, there is a lot more we can do here. My
experience by the way is to first try and understand how to manually
set up contextual events up before you start using the declarative
options (at least when your goal is to better understand what's
behind).
"This does make me wonder are we likely to see in future ADF
behalf, effectively "Implicit Contextual Events"? "
The truth is that contextual events are expensive because they bubble
up the ADF PageDef chain to broadcast the message to directly
registered listeners (aka. consumers (though they don't consume the
event)) to then,turn around to bubble down the chain, to broadcasti
the message to all sibling PageDef files just in case there is a wild
card consumer registered. You can imagine what happens if events are
blindly published though nobody cares (what a waste of energy). So
better is a meet in the middle solution in which developer explicitly
enable implicit events.For this I think there a specific feature
missing: discoverability. When adding a BTF from a library how do I
know which event this is listening for or broadcasting. This is not a
trivial task because a BTF can have hundreds of ADF bound page
fragments, each of which can be sending or listening for events. So
exposing a list on the BTF task flow call activity or ADF Regions may
be too much of an overkill.
I like to jump onto this thread (sorry Chris) and ask the community
what they would think how inter-region communication (aka contextual
event) should be improved in terms of registration, subscription,
implicit events and design time improvements, Unfortunately it seems
that there is no good uptake of contextual events yet (as I can tell
from questions on OTN and the internal lists).
Maybe we can start with a list of use cases that you see contextual
events make sense to be used in. Once we have the use cases, we can
think about what the event and the payload is that would be
broadcasted. Based on this - hopefully - we are able to determine a
common set of events that may make good candidate for Chris's vision
of implicit events.
Frank
Andrejus Baranovskis
Aug 3, 2010, 10:05:10 AM8/3/10
to adf-met...@googlegroups.com
Hi Frank,
"Unfortunately it seems that there is no good uptake of contextual events yet"
Yes, thats true. Mainly because Contextual Events framework (as it is
now) is too complex for such 'simple' thing as region communication
and visual property refresh. Also in many cases we are using Shared
Data Control, there is no need for Contextual Events then, region can
be refreshed by changing region input parameter and using Refresh
ifNeeded option.
Once we will be able to declare/debug Contextual Events in more
intuitive way, I believe adoption will be better.
Regards,
Andrejus
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodolo...@googlegroups.com
>
--
Oracle ACE Director
My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/
Rommel Pino
Aug 3, 2010, 10:46:58 AM8/3/10
to adf-met...@googlegroups.com
Hi All,
I just wanted to share our usage of ADF Contextual Events in our
current project that use the UI Shell pattern and Stateless session
beans.
The challenge that we face before was how to update other tabs on
actions made in another tab, especially that we are using UI Shell in
which we cannot determine from which region a certain event would be
raised.
This link to a screencast illustrates how we use contextual events to
solve that challenge:
http://soadev.blogspot.com/2010/08/adf-ui-shell-taking-advantage-of.html
Regards,
pino
Chris Muir
Aug 3, 2010, 10:23:39 PM8/3/10
to ADF Enterprise Methodology Group
Coincidentally I had a bit of whine about the use of the #{payLoad} EL
expression in the following blog post:
http://one-size-doesnt-fit-all.blogspot.com/2010/08/jdev-contextual-events-payload-payload.html
Now that I've got that off my chest, returning to Frank's idea about
listing out common Contextual Event use cases, I've already mentioned
flagging the dirty transaction from the child BTF to parent
application. A further common usage I've been thinking about is,
well, it's a bit complicated, so let's explain.
In the layout of our application, we make use of the ADF UI Shell with
a number of opening and closing BTFs in the tabbed region area. To
the right of these, we've extended the UI Shell to include what I call
an overflow-right area. Those coming from a Designer 100% generation
background will be familiar with this term. Richard Wright from
Oracle tells me they call this a Contextual Area - not to be confused
with Contextual Events.
The purpose of the Contextual Area is to show additional information
to whatever you see in the current tabbed BTF region. For example,
imagine in the tabbed BTF regions you're displaying a single
customer. As you switch between BTF regions, you see different
customers. Now imagine each BTF details all the characteristics of
the customer: name, addresses, tax file number, teddy bear
preferences. However you have the business requirement to show the
user all calls logged against that customer, which is peripheral
information to the actual customer details. This call log would be
ideal for the Contextual Area on the right.
As such the application has the need, when switching tabbed BTFs (or
in other words switching customers), that the Contextual Area updates
itself to show the call log for the currently displayed customer.
Returning to Frank's question, where I see a common Contextual *Event*
usage is, when a BTF becomes active, and the associated record it is
currently showing (or if a table, the current row), the primary key of
the current record should be automatically communicated to the parent
application, so it can decide to show peripheral information in the
Contextual Area. The Contextual Event would have to be raised either
when the user opens a new BTF, or moves between BTFs, or in turn
within that BTF, the user navigates records. The equivalent forms
triggers would be WHEN-NEW-BLOCK-INSTANCE and WHEN-NEW-RECORD-
INSTANCE.
Anybody else have any Contextual Event patterns to share?
CM.
On Aug 3, 10:46 pm, Rommel Pino <rhpino...@gmail.com> wrote:
> Hi All,
>
> I just wanted to share our usage of ADF Contextual Events in our
> current project that use the UI Shell pattern and Stateless session
> beans.
> The challenge that we face before was how to update other tabs on
> actions made in another tab, especially that we are using UI Shell in
> which we cannot determine from which region a certain event would be
> raised.
> This link to a screencast illustrates how we use contextual events to
> solve that challenge:http://soadev.blogspot.com/2010/08/adf-ui-shell-taking-advantage-of.html
>
> Regards,
> pino
>
expression in the following blog post:
http://one-size-doesnt-fit-all.blogspot.com/2010/08/jdev-contextual-events-payload-payload.html
Now that I've got that off my chest, returning to Frank's idea about
listing out common Contextual Event use cases, I've already mentioned
flagging the dirty transaction from the child BTF to parent
application. A further common usage I've been thinking about is,
well, it's a bit complicated, so let's explain.
In the layout of our application, we make use of the ADF UI Shell with
a number of opening and closing BTFs in the tabbed region area. To
the right of these, we've extended the UI Shell to include what I call
an overflow-right area. Those coming from a Designer 100% generation
background will be familiar with this term. Richard Wright from
Oracle tells me they call this a Contextual Area - not to be confused
with Contextual Events.
The purpose of the Contextual Area is to show additional information
to whatever you see in the current tabbed BTF region. For example,
imagine in the tabbed BTF regions you're displaying a single
customer. As you switch between BTF regions, you see different
customers. Now imagine each BTF details all the characteristics of
the customer: name, addresses, tax file number, teddy bear
preferences. However you have the business requirement to show the
user all calls logged against that customer, which is peripheral
information to the actual customer details. This call log would be
ideal for the Contextual Area on the right.
As such the application has the need, when switching tabbed BTFs (or
in other words switching customers), that the Contextual Area updates
itself to show the call log for the currently displayed customer.
Returning to Frank's question, where I see a common Contextual *Event*
usage is, when a BTF becomes active, and the associated record it is
currently showing (or if a table, the current row), the primary key of
the current record should be automatically communicated to the parent
application, so it can decide to show peripheral information in the
Contextual Area. The Contextual Event would have to be raised either
when the user opens a new BTF, or moves between BTFs, or in turn
within that BTF, the user navigates records. The equivalent forms
triggers would be WHEN-NEW-BLOCK-INSTANCE and WHEN-NEW-RECORD-
INSTANCE.
Anybody else have any Contextual Event patterns to share?
CM.
On Aug 3, 10:46 pm, Rommel Pino <rhpino...@gmail.com> wrote:
> Hi All,
>
> I just wanted to share our usage of ADF Contextual Events in our
> current project that use the UI Shell pattern and Stateless session
> beans.
> The challenge that we face before was how to update other tabs on
> actions made in another tab, especially that we are using UI Shell in
> which we cannot determine from which region a certain event would be
> raised.
> This link to a screencast illustrates how we use contextual events to
> solve that challenge:http://soadev.blogspot.com/2010/08/adf-ui-shell-taking-advantage-of.html
>
> Regards,
> pino
>
Lucas
Aug 4, 2010, 10:46:10 AM8/4/10
to ADF Enterprise Methodology Group
Hi Frank,
One thing I would like to have - which also addresses at least to a
point the cost of the events - is the ability to define the client
side equivalent of the contextual event. I mean that the UI components
rendered by the BTF should be able to publish client side events that
can be handled on the client side (without of course the BTF knowing
in advanced which listeners there will be in the client rendered by
the page that embeds the BTF. What that would require probably is a
generic client side ADF event handler to which events can be published
by client components (in reusable BTFs) - even if no subscribers are
registered. Consumers of those BTFs can include JavaScript functions
that we can register as listeners for such client side events. If
there are no listeners - that is fine. If there are one or more, that
is fine too and they will be notified when the BTFs components produce
the event. By bypassing the server, it would seem we can make this
much more lightweight.
It seems that being able to define the client side equivalent of
serverListener components or an alternative type of clientListener
(one that is not directly associated to the component that produces
the event but instead one that listens (on the client side) for an
event appearing on the AdfCustomEvent.queue would do this trick.
Starting to wonder: can that be done already by any chance:
Registering a client side listener on the AdfCustomEvent.queue?
example:
BTF:
contains inputText component
that publishes a valueChangeEvent called birthdayFieldValueChangeEvent
=> to a generic client side event handling infrastructure
Consuming page:
contains a 'clientsideServerListener' that listens for an event of
type birthdayFieldValueChangeEvent; it is implemented as a javascript
function that is registered with and called by the generic client
event handling infrastructure; the server side is not involved
Lucas
> > CM.- Hide quoted text -
>
> - Show quoted text -
One thing I would like to have - which also addresses at least to a
point the cost of the events - is the ability to define the client
side equivalent of the contextual event. I mean that the UI components
rendered by the BTF should be able to publish client side events that
can be handled on the client side (without of course the BTF knowing
in advanced which listeners there will be in the client rendered by
the page that embeds the BTF. What that would require probably is a
generic client side ADF event handler to which events can be published
by client components (in reusable BTFs) - even if no subscribers are
registered. Consumers of those BTFs can include JavaScript functions
that we can register as listeners for such client side events. If
there are no listeners - that is fine. If there are one or more, that
is fine too and they will be notified when the BTFs components produce
the event. By bypassing the server, it would seem we can make this
much more lightweight.
It seems that being able to define the client side equivalent of
serverListener components or an alternative type of clientListener
(one that is not directly associated to the component that produces
the event but instead one that listens (on the client side) for an
event appearing on the AdfCustomEvent.queue would do this trick.
Starting to wonder: can that be done already by any chance:
Registering a client side listener on the AdfCustomEvent.queue?
example:
BTF:
contains inputText component
that publishes a valueChangeEvent called birthdayFieldValueChangeEvent
=> to a generic client side event handling infrastructure
Consuming page:
contains a 'clientsideServerListener' that listens for an event of
type birthdayFieldValueChangeEvent; it is implemented as a javascript
function that is registered with and called by the generic client
event handling infrastructure; the server side is not involved
Lucas
>
> - Show quoted text -
fnimphiu
Aug 4, 2010, 11:50:59 AM8/4/10
to ADF Enterprise Methodology Group
Agreed. I am open to work with anyone intersted on this group to spec
out improvements and
to push this to the dev-team for implementing. I did not yet look at
the internal JDeveloper 11.1.2
build for changes in contextual events, but think that still
complexity rules
Frank
On Aug 3, 4:05 pm, Andrejus Baranovskis
> My Blog -http://andrejusb.blogspot.com/
out improvements and
to push this to the dev-team for implementing. I did not yet look at
the internal JDeveloper 11.1.2
build for changes in contextual events, but think that still
complexity rules
Frank
On Aug 3, 4:05 pm, Andrejus Baranovskis
<andrejus.baranovs...@gmail.com> wrote:
> Hi Frank,
>
> "Unfortunately it seems that there is no good uptake of contextual events yet"
>
> Yes, thats true. Mainly because Contextual Events framework (as it is
> now) is too complex for such 'simple' thing as region communication
> and visual property refresh. Also in many cases we are using Shared
> Data Control, there is no need for Contextual Events then, region can
> be refreshed by changing region input parameter and using Refresh
> ifNeeded option.
>
> Once we will be able to declare/debug Contextual Events in more
> intuitive way, I believe adoption will be better.
>
> Regards,
> Andrejus
>
> Hi Frank,
>
> "Unfortunately it seems that there is no good uptake of contextual events yet"
>
> Yes, thats true. Mainly because Contextual Events framework (as it is
> now) is too complex for such 'simple' thing as region communication
> and visual property refresh. Also in many cases we are using Shared
> Data Control, there is no need for Contextual Events then, region can
> be refreshed by changing region input parameter and using Refresh
> ifNeeded option.
>
> Once we will be able to declare/debug Contextual Events in more
> intuitive way, I believe adoption will be better.
>
> Regards,
> Andrejus
>
amit seth
Aug 4, 2010, 5:58:56 PM8/4/10
to adf-met...@googlegroups.com
I apologize for inconvenience to you all,
by mistake I send my previous reply with incomplete message.
Hi All,
This is certainly very nice thread started by Chris and it feels good to see that Frank is taking it to
development, ofcourse everything will depends on complexity, performance and other factor.
I am not sure if this adds any value to the thread but I wanted to speak my mind on couple of scenarios
where I guess default contextual action(CA) could be helpful.
1. Default CA that could give TaskFlow Return outcome. With more and more use of dynamic UI shell
and patterns like that many a taskflows are launched programatically. Since there is no explicit region
we don't have regionNavigationListener too. I think it would be good to raise an implicit event that
could convey the task flow return outcome, so that based on the outcome listener could process some
logic. This many not be the requirement for all the TaskFlows, so having a property that could control
if event is should be raised or skipped would help in minimizing the cost when its not required.
2. You can call me crazy for this but here it goes second opinion:
Most of the times we think of CA as child produces an event and parent consumes it. With the large
popularity of re-usable taskflow and popups, I have seen customer wants TF's that do not share a txn
and should have there own commit and rollback. Till here its all fine. Problem arises when they ask to use
them in popups because the controls are with consumers that is popup dialog buttons but you need to
raise the event on these buttons so that you can consume then in taskflow without actually re-executing
it. What I am proposing here is some default listeners in TF's that could specifically be used for commit and
rollback.
Thanks
Amit
by mistake I send my previous reply with incomplete message.
Hi All,
This is certainly very nice thread started by Chris and it feels good to see that Frank is taking it to
development, ofcourse everything will depends on complexity, performance and other factor.
I am not sure if this adds any value to the thread but I wanted to speak my mind on couple of scenarios
where I guess default contextual action(CA) could be helpful.
1. Default CA that could give TaskFlow Return outcome. With more and more use of dynamic UI shell
and patterns like that many a taskflows are launched programatically. Since there is no explicit region
we don't have regionNavigationListener too. I think it would be good to raise an implicit event that
could convey the task flow return outcome, so that based on the outcome listener could process some
logic. This many not be the requirement for all the TaskFlows, so having a property that could control
if event is should be raised or skipped would help in minimizing the cost when its not required.
2. You can call me crazy for this but here it goes second opinion:
Most of the times we think of CA as child produces an event and parent consumes it. With the large
popularity of re-usable taskflow and popups, I have seen customer wants TF's that do not share a txn
and should have there own commit and rollback. Till here its all fine. Problem arises when they ask to use
them in popups because the controls are with consumers that is popup dialog buttons but you need to
raise the event on these buttons so that you can consume then in taskflow without actually re-executing
it. What I am proposing here is some default listeners in TF's that could specifically be used for commit and
rollback.
Thanks
Amit
Chris Muir
Aug 5, 2010, 3:19:13 AM8/5/10
to ADF Enterprise Methodology Group
Frank, thanks for the offer to take up giving members of the group the
opportunity to help specify future features of contextual events. For
these members benefit, how would you like to proceed on that front?
Would you like to do it in this public forum, or shall I ask members
to contact me and I'll give you a list of names & email addresses?
CM.
> ...
>
> read more »
opportunity to help specify future features of contextual events. For
these members benefit, how would you like to proceed on that front?
Would you like to do it in this public forum, or shall I ask members
to contact me and I'll give you a list of names & email addresses?
CM.
>
> read more »
Chris Muir
Aug 5, 2010, 11:39:30 PM8/5/10
to ADF Enterprise Methodology Group
While we're waiting for Frank to follow up (he's usual super busy), I
think I struck upon another limitation in the current contextual event
model, though I ask any readers who know otherwise to post to the
group with their understandings please.
I'm currently working on a programmatic approach to contextual events,
I'll blog about it next week (for the record it's mentioned in Frank
and Lynn Munsinger's book, it's nothing new). Like declarative
contextual events, the programmatic solution requires contextual
events are invoked by action events on buttons, or value change events
on fields. The payloads to be communicated to the contextual event
consumer are actually attached to the button or field themselves
programmatically. Note this solution for contextual events is very
web page specific, as it requires the actual UI components to both
invoke the events from the programmatic code and carry the payloads.
The contextual event bindings actually map to ActionListener or
ValueChangeListenerSomething (class name escapes me) proving this
fact.
Today I was thinking about what if I wanted to raise a contextual
event via the actual task flow itself? In other words can I in the
task flow diagrammer declarative raise a contextual event in the flow
rather than from a page? I think it seems reasonable in the task flow
diagrammer, given I take a certain logical route through the flow, I
might want to raise events and pass payloads to the parent
application. I also think given there's great emphasis on not hiding
code in web page listeners, but showing their calls via "Method Call"
activities in a declarative in-your-face diagram type approach as a
design principle, it would seem consistent we should also be able to
raise contextual events via task flows declaratively too.
For example say I'm a call center clerk logging different phone
inquiries. At a certain point in my BTF based on the person who calls
me, a task flow router activity calls a method to determine if the
customer is a new customer or old customer. If it's a new customer,
on taking a different BTF route, I want to communicate to the calling
application that it needs to do something specific to new customers
like show a check list of sign up questions or remind the operator to
be friendly, smile and steal as much money from the new customer as
possible. If it's an old customer, instead we tell the calling
application to display a screen of survey questions on customer
satisfaction, or remind the operator to steal as much money from the
old customer as possible.
Given the declarative task flow contextual event idea, it doesn't
appear it's possible to define contextual events declaratively at the
moment in the task flow diagrammer. As (from my understanding
described at the beginning) the contextual events can only be raised
from action and value change listener events based on UI Components.
This means even if we were to programmatically raise the contextual
event via a task flow method call, we have no UI Component to add our
payloads too.
For the record I considered the task flow Parent Action activity, but
it's really to do with invoking navigation within the parent
application, not events which pass data.
I'd appreciate any comments if my conclusions are wrong. As Frank
said, it's a brave new area that not many people are using at the
moment, so any discussions are good discussions IMHO.
Cheers,
CM.
> ...
>
> read more »
think I struck upon another limitation in the current contextual event
model, though I ask any readers who know otherwise to post to the
group with their understandings please.
I'm currently working on a programmatic approach to contextual events,
I'll blog about it next week (for the record it's mentioned in Frank
and Lynn Munsinger's book, it's nothing new). Like declarative
contextual events, the programmatic solution requires contextual
events are invoked by action events on buttons, or value change events
on fields. The payloads to be communicated to the contextual event
consumer are actually attached to the button or field themselves
programmatically. Note this solution for contextual events is very
web page specific, as it requires the actual UI components to both
invoke the events from the programmatic code and carry the payloads.
The contextual event bindings actually map to ActionListener or
ValueChangeListenerSomething (class name escapes me) proving this
fact.
Today I was thinking about what if I wanted to raise a contextual
event via the actual task flow itself? In other words can I in the
task flow diagrammer declarative raise a contextual event in the flow
rather than from a page? I think it seems reasonable in the task flow
diagrammer, given I take a certain logical route through the flow, I
might want to raise events and pass payloads to the parent
application. I also think given there's great emphasis on not hiding
code in web page listeners, but showing their calls via "Method Call"
activities in a declarative in-your-face diagram type approach as a
design principle, it would seem consistent we should also be able to
raise contextual events via task flows declaratively too.
For example say I'm a call center clerk logging different phone
inquiries. At a certain point in my BTF based on the person who calls
me, a task flow router activity calls a method to determine if the
customer is a new customer or old customer. If it's a new customer,
on taking a different BTF route, I want to communicate to the calling
application that it needs to do something specific to new customers
like show a check list of sign up questions or remind the operator to
be friendly, smile and steal as much money from the new customer as
possible. If it's an old customer, instead we tell the calling
application to display a screen of survey questions on customer
satisfaction, or remind the operator to steal as much money from the
old customer as possible.
Given the declarative task flow contextual event idea, it doesn't
appear it's possible to define contextual events declaratively at the
moment in the task flow diagrammer. As (from my understanding
described at the beginning) the contextual events can only be raised
from action and value change listener events based on UI Components.
This means even if we were to programmatically raise the contextual
event via a task flow method call, we have no UI Component to add our
payloads too.
For the record I considered the task flow Parent Action activity, but
it's really to do with invoking navigation within the parent
application, not events which pass data.
I'd appreciate any comments if my conclusions are wrong. As Frank
said, it's a brave new area that not many people are using at the
moment, so any discussions are good discussions IMHO.
Cheers,
CM.
>
> read more »
fnimphiu
Aug 10, 2010, 3:41:39 AM8/10/10
to ADF Enterprise Methodology Group
Chris,
I think best would be to think about how to build working groups
within EMG. I am sure that security and Web Service DataControl could
become the next subject for such a ommunity input. However, to start
following up on the contextual events, here's what I suggest
1. If you can, you collect the mail addresses of people interesting in
contributing to an ER for contextual events and send me the list
2. I'll contact them and organize a conference call to get a first run
on the topics that need improvement
3. If required I would cal for additional meetings in which I share
the document I work on
4. Once the group agrees (virtually signs off he document), I pass the
document on to the dev team to look at and provide the feedback
5. We then publish the document and the feedback (as long as it can be
published) here on the EMG group for everyone to have a look
Frank
> ...
>
> read more »
I think best would be to think about how to build working groups
within EMG. I am sure that security and Web Service DataControl could
become the next subject for such a ommunity input. However, to start
following up on the contextual events, here's what I suggest
1. If you can, you collect the mail addresses of people interesting in
contributing to an ER for contextual events and send me the list
2. I'll contact them and organize a conference call to get a first run
on the topics that need improvement
3. If required I would cal for additional meetings in which I share
the document I work on
4. Once the group agrees (virtually signs off he document), I pass the
document on to the dev team to look at and provide the feedback
5. We then publish the document and the feedback (as long as it can be
published) here on the EMG group for everyone to have a look
Frank
>
> read more »
Chris Muir
Aug 10, 2010, 8:36:39 AM8/10/10
to ADF Enterprise Methodology Group
Okay boys and girls, you heard the man, send me your email addresses
and I'll collate them: su...@ccmlabz.net
We already have 2 takers!
CM.
> ...
>
> read more »
and I'll collate them: su...@ccmlabz.net
We already have 2 takers!
CM.
>
> read more »
Michael Fons
Aug 10, 2010, 8:34:41 PM8/10/10
to ADF Enterprise Methodology Group
It is so odd you are having this thread while I am working my way
through chapter 6 of Frank and Lynn's book. :-) I just published
this question in JDev forum: http://forums.oracle.com/forums/message.jspa?messageID=4490715#4490715
In some ways it seems the question I was asking was related to what
Chris just asked while he is waiting for Frank to get back.
As I read through this chapter it seemed there were two kinds of way
to raise context events: at the component level and at the binding
level. It appeared from my read of this chapter that *any* binding
could have an event associated with it...which did not make a lot of
sense to me, as it seemed that bindings are no good without
components, and some components (like tables) have many different
events raised from them. So, it seemed that you could associate an
event with a binding without saying which component event it was
associated with, and that seemed confusing. At this point though, I
am beginning to think that these events on the binding side, are
possibly just available for being produced...and it does not just have
to happen on a value change or an action event...especially since I
think there was a range-change example in the book, and maybe some
others.
I am keeping my mind open until I read more ;-)
through chapter 6 of Frank and Lynn's book. :-) I just published
this question in JDev forum: http://forums.oracle.com/forums/message.jspa?messageID=4490715#4490715
In some ways it seems the question I was asking was related to what
Chris just asked while he is waiting for Frank to get back.
As I read through this chapter it seemed there were two kinds of way
to raise context events: at the component level and at the binding
level. It appeared from my read of this chapter that *any* binding
could have an event associated with it...which did not make a lot of
sense to me, as it seemed that bindings are no good without
components, and some components (like tables) have many different
events raised from them. So, it seemed that you could associate an
event with a binding without saying which component event it was
associated with, and that seemed confusing. At this point though, I
am beginning to think that these events on the binding side, are
possibly just available for being produced...and it does not just have
to happen on a value change or an action event...especially since I
think there was a range-change example in the book, and maybe some
others.
I am keeping my mind open until I read more ;-)
Michael Fons
Aug 11, 2010, 8:48:33 AM8/11/10
to ADF Enterprise Methodology Group
I did not address Chris's question about raising task flow events. I
would think that would be a helpful addition, judging on what I have
read so far.
> ...
>
> read more »
would think that would be a helpful addition, judging on what I have
read so far.
>
> read more »
Edwin Biemond
Aug 11, 2010, 2:18:09 PM8/11/10
to ADF Enterprise Methodology Group
Hi,
For the event I always use java data control to fire events and one to
capture the events. With this I can fire everything . just put it in a
map and pass this as payLoad, capture this and do your thing.
public Map<String, Object> fireComplexEvent() {
System.out.println("fire complex event ");
Map<String, Object> eventData = new HashMap<String, Object>();
eventData.put("text1", "hello");
eventData.put("text2", "hello2");
return eventData;
}
public String captureComplexEvents(Object parameter) {
System.out.println("capture complex event");
Map<String, Object> eventData = (Map<String,
Object>)parameter;
return (String)eventData.get("text1") + " / " +
(String)eventData.get("text2");
}
I do it all manually because the jdev property or pagedef editor is
always failing. always good to know how it really works.
but I like to see that the pagedef or datacontrol definition is not
necessary anymore .to fire custom events and what Lucas said to
capture the events on the client side.
thanks
> ...
>
> meer lezen »
For the event I always use java data control to fire events and one to
capture the events. With this I can fire everything . just put it in a
map and pass this as payLoad, capture this and do your thing.
public Map<String, Object> fireComplexEvent() {
System.out.println("fire complex event ");
Map<String, Object> eventData = new HashMap<String, Object>();
eventData.put("text1", "hello");
eventData.put("text2", "hello2");
return eventData;
}
public String captureComplexEvents(Object parameter) {
System.out.println("capture complex event");
Map<String, Object> eventData = (Map<String,
Object>)parameter;
return (String)eventData.get("text1") + " / " +
(String)eventData.get("text2");
}
I do it all manually because the jdev property or pagedef editor is
always failing. always good to know how it really works.
but I like to see that the pagedef or datacontrol definition is not
necessary anymore .to fire custom events and what Lucas said to
capture the events on the client side.
thanks
>
> meer lezen »
Edwin Biemond
Aug 12, 2010, 10:55:39 AM8/12/10
to ADF Enterprise Methodology Group
By the way together with Pino, we found the following bugs in PS2
Table events are not fired in PS2, no problem in PS1
In a tree the highest level node events are not published in PS2 .no
problem in PS1
and I noticed when there is only one row to click on then the event is
never fired. ( In PS1 and 2 )
Here is the testcase http://biemond.blogspot.com/2009/11/adf-contextual-events-in-11g-r1-ps1.html
and the workspace to test this in PS1 or PS2 http://www.sbsframes.nl/jdeveloper/Events.zip
thanks
> ...
>
> meer lezen »
Table events are not fired in PS2, no problem in PS1
In a tree the highest level node events are not published in PS2 .no
problem in PS1
and I noticed when there is only one row to click on then the event is
never fired. ( In PS1 and 2 )
Here is the testcase http://biemond.blogspot.com/2009/11/adf-contextual-events-in-11g-r1-ps1.html
and the workspace to test this in PS1 or PS2 http://www.sbsframes.nl/jdeveloper/Events.zip
thanks
>
> meer lezen »
Chris Muir
Aug 16, 2010, 8:15:21 AM8/16/10
to ADF Enterprise Methodology Group
Thanks for follow up Edwin.
Edwin or Pino, do you have a bug number(s)?
CM.
On Aug 12, 10:55 pm, Edwin Biemond <biem...@gmail.com> wrote:
> By the way together with Pino, we found the following bugs in PS2
>
> Table events are not fired in PS2, no problem in PS1
> In a tree the highest level node events are not published in PS2 .no
> problem in PS1
>
> and I noticed when there is only one row to click on then the event is
> never fired. ( In PS1 and 2 )
>
> Here is the testcasehttp://biemond.blogspot.com/2009/11/adf-contextual-events-in-11g-r1-p...
> and the workspace to test this in PS1 or PS2http://www.sbsframes.nl/jdeveloper/Events.zip
> ...
>
> read more »
Edwin or Pino, do you have a bug number(s)?
CM.
On Aug 12, 10:55 pm, Edwin Biemond <biem...@gmail.com> wrote:
> By the way together with Pino, we found the following bugs in PS2
>
> Table events are not fired in PS2, no problem in PS1
> In a tree the highest level node events are not published in PS2 .no
> problem in PS1
>
> and I noticed when there is only one row to click on then the event is
> never fired. ( In PS1 and 2 )
>
> and the workspace to test this in PS1 or PS2http://www.sbsframes.nl/jdeveloper/Events.zip
>
> read more »
fnimphiu
Aug 16, 2010, 12:03:49 PM8/16/10
to ADF Enterprise Methodology Group
Just in a quick reply to Michael:
There are indeed to type of events:
- component events
- binding events
Component events are JavaServer Faces events that you pass on to a
event binding. The binding events are value change for attribute
bindings and range change for tree binding. Given that a change on the
binding could be through code, I think its not bad to *not* make
contextual events dependent of having a component associated in the
UI.
When I started writing chapter 6, then there was no UI support to
create component events and everything had to be build manually. The
UI support came in during copy edits (very late in the book writing
cycle) and honestly I was torn between documenting it or leaving the
chapter as it was. A little angel sitting on my right shoulder beat
the little devil sitting on the left and so I documented the new UI
though my impression was that it did add to the confusion. However,
its the UI that will hoepfully make things easier - its just a
question of how ;-) Note that if we get a god working together on this
topic, and if you are interested, we can then look at ADF region
interaction as a whole. I know that for example Lucas Jellema is a
friend of a lightweight approach in inter-region communication, which
may feed in to contextual events as well.
Frank
Ps.: Once Chris has collected the mails of the volunteers, I'll follow
up with you directly. As of the timing, I think a start after OOW is
what possibly is the best. For PS3 and the 11.1.2 release we can't
change contextual events, so we are in a good start position for the
release after.
> ...
>
> read more »
There are indeed to type of events:
- component events
- binding events
Component events are JavaServer Faces events that you pass on to a
event binding. The binding events are value change for attribute
bindings and range change for tree binding. Given that a change on the
binding could be through code, I think its not bad to *not* make
contextual events dependent of having a component associated in the
UI.
When I started writing chapter 6, then there was no UI support to
create component events and everything had to be build manually. The
UI support came in during copy edits (very late in the book writing
cycle) and honestly I was torn between documenting it or leaving the
chapter as it was. A little angel sitting on my right shoulder beat
the little devil sitting on the left and so I documented the new UI
though my impression was that it did add to the confusion. However,
its the UI that will hoepfully make things easier - its just a
question of how ;-) Note that if we get a god working together on this
topic, and if you are interested, we can then look at ADF region
interaction as a whole. I know that for example Lucas Jellema is a
friend of a lightweight approach in inter-region communication, which
may feed in to contextual events as well.
Frank
Ps.: Once Chris has collected the mails of the volunteers, I'll follow
up with you directly. As of the timing, I think a start after OOW is
what possibly is the best. For PS3 and the 11.1.2 release we can't
change contextual events, so we are in a good start position for the
release after.
>
> read more »
Edwin Biemond
Aug 17, 2010, 5:01:05 PM8/17/10
to ADF Enterprise Methodology Group
Hi Chris,
I send the testcase to Frank and he confirmed the bugs in PS2 and in
the current build release of PS3. He will report the bugs to
development.
So lets hope the bug are important enough to make it to the PS3
release.
and a update of this bug / feature when there is only one row to
click on then the event is never fired. ( In PS1 and 2 ) .
This also means the first record in a table or tree. this is because
this record is the default selected row.
Workaround , make a dummy record or the user has to select a other row
first and then select the first.
thanks
> ...
>
> meer lezen »
I send the testcase to Frank and he confirmed the bugs in PS2 and in
the current build release of PS3. He will report the bugs to
development.
So lets hope the bug are important enough to make it to the PS3
release.
and a update of this bug / feature when there is only one row to
click on then the event is never fired. ( In PS1 and 2 ) .
This also means the first record in a table or tree. this is because
this record is the default selected row.
Workaround , make a dummy record or the user has to select a other row
first and then select the first.
thanks
>
> meer lezen »
Chris Muir
Aug 30, 2010, 7:49:28 AM8/30/10
to ADF Enterprise Methodology Group
To complete this post, thanks to all that put their hands up to assist
Frank in defining the future requirements for contextual events. As
Frank mentioned post OOW we'll contact you to take this to the next
logical step.
Regards,
CM.
> ...
>
> read more »
Frank in defining the future requirements for contextual events. As
Frank mentioned post OOW we'll contact you to take this to the next
logical step.
Regards,
CM.
>
> read more »
Reply all
Reply to author
Forward
0 new messages