Most importantly for the purposes of this group, I am one of the
architects of the ADF Faces rich client project. I have also served
as Oracle's representative to the JavaServer Faces expert group for
the last several years.
By "long-time", I mean: long enough to date back to a time when
character mode (vt100 ftw!) and X-Windows/Motif were more popular
client-side platforms for Oracle's tools than Windows 3.1. :-)
Since joining Oracle (almost 19 years ago), I have helped to build a
series of user interface frameworks that have been the basis for a
wide range of both Oracle and customer-built products.
Old-school Oracle Forms/Reports users might remember the good old
"Oracle Toolkit" - a cross-platform UI toolkit built in C. (Think
Java's AWT, but before James Gosling shared Java with the world.)
Once Java came along I helped to found the Oracle's EWT component set
- one of the first high-level component offerings for AWT. (Think
Swing, before there was Swing.) EWT led to JEWT, a port of our
components to Swing.
Eventually we realized that there was more to the web than just
applets, which led to the founding of our first Servlet-based web
framework, UIX. (Think JSF, before JSF.) This included an XML-based
templating language that served as an efficient alternative to JSP.
(Think Facelets.) Another memorable UIX feature was an iframe-based
mechanism for communicating with the server without replacing the
entire page, which we named "partial page rendering". (Think Ajax,
before XmlHttpRequest.)
We used our experiences with UIX to help drive the development of the
JSF 1.0 specification. Once the spec and implementation were ready,
we quickly jumped on board and produced what was likely the first ever
JSF-based component library: ADF Faces. This original version of ADF
Faces was donated to Apache back in 2006 and is now Apache MyFaces
Trinidad. Since then I have been busy working on the second
generation of our JSF component set: ADF Faces rich client.
Yikes. That's a lot of components!
These days my focus is split between ADF Faces performance/
scalability, maintenance/enhancements relating to our core framework,
JSF specification development/integration, and of course, whatever hot
client/customer issue happens to arise today.
Let's see, what else is important…
I think simplicity is key when it comes both to API and UI design.
(Candy machine interfaces ftw!)
I strongly believe that community is a critical part of software
development. I am pretty psyched/honored to now be included in the
ADF EMG community!
My pet peeve is unnecessarily vague error messages.
My favorite Java Posse member is Dick Wall.
The compiler is my friend.
I am not a "brogrammer".
Er… okay, might be getting off track here.
Looking forward to answering whatever questions I can, but I am
especially excited to hear about your experiences using ADF Faces and/
or JSF.
On behalf of the EMG members thanks very much to agreeing to be part
of the next "I am" series on the ADF EMG.
19 years! Are you sure you didn't found Oracle with Uncle Larry? It
never ceases to me amaze me how long some people have been at Oracle.
So what do you get from Oracle when you hit the 20 year mark? One of
Larry's boats? Oh, I look forward to the day when I can sail the
seven seas as a salty Oracle sea dog.....
What I find interesting about the history of products you've worked on
at Oracle, is that in many cases Oracle has been pushing the envelope
by taking a current technology and extending it (e.g. Oracle Toolkit,
EWT, UIX and now ADF Faces). What do you believe is the primary
driver for this model? I'm guessing Oracle in building software for
its customers often finds solutions incomplete for its needs, so a new
toolkit is built. Historically this doesn't look to be that customer
focused.
Yet with the transition to UIX then JSF this appears to have changed.
I must admit I became aware of you through your blog and submissions
to the JSF specification. It seems to me that Oracle has been a keen
player in the JSF world (for members that's since ~2004), very much
community focused through its collaboration with JSR-344
(http://bit.ly/IzMnyC) and the JCP. Can you comment on how your job
has changed (if at all) from being internally focused to now having to
consider the wider (JSF) communities needs? Or does the JSF JCP act
as a cabal of brogrammers?
CM.
On 2 May 2012 22:01, Andy <andy.g.schwa...@gmail.com> wrote:
> Most importantly for the purposes of this group, I am one of the
> architects of the ADF Faces rich client project. I have also served
> as Oracle's representative to the JavaServer Faces expert group for
> the last several years.
> By "long-time", I mean: long enough to date back to a time when
> character mode (vt100 ftw!) and X-Windows/Motif were more popular
> client-side platforms for Oracle's tools than Windows 3.1. :-)
> Since joining Oracle (almost 19 years ago), I have helped to build a
> series of user interface frameworks that have been the basis for a
> wide range of both Oracle and customer-built products.
> Old-school Oracle Forms/Reports users might remember the good old
> "Oracle Toolkit" - a cross-platform UI toolkit built in C. (Think
> Java's AWT, but before James Gosling shared Java with the world.)
> Once Java came along I helped to found the Oracle's EWT component set
> - one of the first high-level component offerings for AWT. (Think
> Swing, before there was Swing.) EWT led to JEWT, a port of our
> components to Swing.
> Eventually we realized that there was more to the web than just
> applets, which led to the founding of our first Servlet-based web
> framework, UIX. (Think JSF, before JSF.) This included an XML-based
> templating language that served as an efficient alternative to JSP.
> (Think Facelets.) Another memorable UIX feature was an iframe-based
> mechanism for communicating with the server without replacing the
> entire page, which we named "partial page rendering". (Think Ajax,
> before XmlHttpRequest.)
> We used our experiences with UIX to help drive the development of the
> JSF 1.0 specification. Once the spec and implementation were ready,
> we quickly jumped on board and produced what was likely the first ever
> JSF-based component library: ADF Faces. This original version of ADF
> Faces was donated to Apache back in 2006 and is now Apache MyFaces
> Trinidad. Since then I have been busy working on the second
> generation of our JSF component set: ADF Faces rich client.
> Yikes. That's a lot of components!
> These days my focus is split between ADF Faces performance/
> scalability, maintenance/enhancements relating to our core framework,
> JSF specification development/integration, and of course, whatever hot
> client/customer issue happens to arise today.
> Let's see, what else is important…
> I think simplicity is key when it comes both to API and UI design.
> (Candy machine interfaces ftw!)
> I strongly believe that community is a critical part of software
> development. I am pretty psyched/honored to now be included in the
> ADF EMG community!
> My pet peeve is unnecessarily vague error messages.
> My favorite Java Posse member is Dick Wall.
> The compiler is my friend.
> I am not a "brogrammer".
> Er… okay, might be getting off track here.
> Looking forward to answering whatever questions I can, but I am
> especially excited to hear about your experiences using ADF Faces and/
> or JSF.
> Andy
> --
> 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-methodology+unsubscribe@googlegroups.com
From my experience customers (and java developer) are very impressed
the first time they see ADF faces.
I also believe it is the most creative and productive framework on JSF
framework, with numerous components and options.
Yet, it is not simple. It has many devils in the detail.
All customers have an opinion about the UI even when they have no idea
what it does.
The details are hard to implement , and browser's differences increase
the complexity.
Also performance and usability are still not as good as client
applications.
I would like to ask what would you expect as future UI technologies
and tools.
Will it be JSF2(X) and html5(X) or should we expect moving back to
more client based technology?
Thanks
MK
On May 3, 3:32 am, Chris Muir <chriscm...@gmail.com> wrote:
> On behalf of the EMG members thanks very much to agreeing to be part
> of the next "I am" series on the ADF EMG.
> 19 years! Are you sure you didn't found Oracle with Uncle Larry? It
> never ceases to me amaze me how long some people have been at Oracle.
> So what do you get from Oracle when you hit the 20 year mark? One of
> Larry's boats? Oh, I look forward to the day when I can sail the
> seven seas as a salty Oracle sea dog.....
> What I find interesting about the history of products you've worked on
> at Oracle, is that in many cases Oracle has been pushing the envelope
> by taking a current technology and extending it (e.g. Oracle Toolkit,
> EWT, UIX and now ADF Faces). What do you believe is the primary
> driver for this model? I'm guessing Oracle in building software for
> its customers often finds solutions incomplete for its needs, so a new
> toolkit is built. Historically this doesn't look to be that customer
> focused.
> Yet with the transition to UIX then JSF this appears to have changed.
> I must admit I became aware of you through your blog and submissions
> to the JSF specification. It seems to me that Oracle has been a keen
> player in the JSF world (for members that's since ~2004), very much
> community focused through its collaboration with JSR-344
> (http://bit.ly/IzMnyC) and the JCP. Can you comment on how your job
> has changed (if at all) from being internally focused to now having to
> consider the wider (JSF) communities needs? Or does the JSF JCP act
> as a cabal of brogrammers?
> CM.
> On 2 May 2012 22:01, Andy <andy.g.schwa...@gmail.com> wrote:
> > Most importantly for the purposes of this group, I am one of the
> > architects of the ADF Faces rich client project. I have also served
> > as Oracle's representative to the JavaServer Faces expert group for
> > the last several years.
> > By "long-time", I mean: long enough to date back to a time when
> > character mode (vt100 ftw!) and X-Windows/Motif were more popular
> > client-side platforms for Oracle's tools than Windows 3.1. :-)
> > Since joining Oracle (almost 19 years ago), I have helped to build a
> > series of user interface frameworks that have been the basis for a
> > wide range of both Oracle and customer-built products.
> > Old-school Oracle Forms/Reports users might remember the good old
> > "Oracle Toolkit" - a cross-platform UI toolkit built in C. (Think
> > Java's AWT, but before James Gosling shared Java with the world.)
> > Once Java came along I helped to found the Oracle's EWT component set
> > - one of the first high-level component offerings for AWT. (Think
> > Swing, before there was Swing.) EWT led to JEWT, a port of our
> > components to Swing.
> > Eventually we realized that there was more to the web than just
> > applets, which led to the founding of our first Servlet-based web
> > framework, UIX. (Think JSF, before JSF.) This included an XML-based
> > templating language that served as an efficient alternative to JSP.
> > (Think Facelets.) Another memorable UIX feature was an iframe-based
> > mechanism for communicating with the server without replacing the
> > entire page, which we named "partial page rendering". (Think Ajax,
> > before XmlHttpRequest.)
> > We used our experiences with UIX to help drive the development of the
> > JSF 1.0 specification. Once the spec and implementation were ready,
> > we quickly jumped on board and produced what was likely the first ever
> > JSF-based component library: ADF Faces. This original version of ADF
> > Faces was donated to Apache back in 2006 and is now Apache MyFaces
> > Trinidad. Since then I have been busy working on the second
> > generation of our JSF component set: ADF Faces rich client.
> > Yikes. That's a lot of components!
> > These days my focus is split between ADF Faces performance/
> > scalability, maintenance/enhancements relating to our core framework,
> > JSF specification development/integration, and of course, whatever hot
> > client/customer issue happens to arise today.
> > Let's see, what else is important…
> > I think simplicity is key when it comes both to API and UI design.
> > (Candy machine interfaces ftw!)
> > I strongly believe that community is a critical part of software
> > development. I am pretty psyched/honored to now be included in the
> > ADF EMG community!
> > My pet peeve is unnecessarily vague error messages.
> > My favorite Java Posse member is Dick Wall.
> > The compiler is my friend.
> > I am not a "brogrammer".
> > Er… okay, might be getting off track here.
> > Looking forward to answering whatever questions I can, but I am
> > especially excited to hear about your experiences using ADF Faces and/
> > or JSF.
> > Andy
> > --
> > 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-methodology+unsubscribe@googlegroups.com
You describe your work for Oracle on different UI technologies
repeatedly with a remark like "think X before there was X".
Given that we now have mobile platforms and related UI technologies,
what has been the evolution for Oracle in that area, or how do you see
this evolve in the future?
thanks
Jan Vervecken
On May 2, 4:01 pm, Andy <andy.g.schwa...@gmail.com> wrote:
> Most importantly for the purposes of this group, I am one of the
> architects of the ADF Faces rich client project. I have also served
> as Oracle's representative to the JavaServer Faces expert group for
> the last several years.
> By "long-time", I mean: long enough to date back to a time when
> character mode (vt100 ftw!) and X-Windows/Motif were more popular
> client-side platforms for Oracle's tools than Windows 3.1. :-)
> Since joining Oracle (almost 19 years ago), I have helped to build a
> series of user interface frameworks that have been the basis for a
> wide range of both Oracle and customer-built products.
> Old-school Oracle Forms/Reports users might remember the good old
> "Oracle Toolkit" - a cross-platform UI toolkit built in C. (Think
> Java's AWT, but before James Gosling shared Java with the world.)
> Once Java came along I helped to found the Oracle's EWT component set
> - one of the first high-level component offerings for AWT. (Think
> Swing, before there was Swing.) EWT led to JEWT, a port of our
> components to Swing.
> Eventually we realized that there was more to the web than just
> applets, which led to the founding of our first Servlet-based web
> framework, UIX. (Think JSF, before JSF.) This included an XML-based
> templating language that served as an efficient alternative to JSP.
> (Think Facelets.) Another memorable UIX feature was an iframe-based
> mechanism for communicating with the server without replacing the
> entire page, which we named "partial page rendering". (Think Ajax,
> before XmlHttpRequest.)
> We used our experiences with UIX to help drive the development of the
> JSF 1.0 specification. Once the spec and implementation were ready,
> we quickly jumped on board and produced what was likely the first ever
> JSF-based component library: ADF Faces. This original version of ADF
> Faces was donated to Apache back in 2006 and is now Apache MyFaces
> Trinidad. Since then I have been busy working on the second
> generation of our JSF component set: ADF Faces rich client.
> Yikes. That's a lot of components!
> These days my focus is split between ADF Faces performance/
> scalability, maintenance/enhancements relating to our core framework,
> JSF specification development/integration, and of course, whatever hot
> client/customer issue happens to arise today.
> Let's see, what else is important…
> I think simplicity is key when it comes both to API and UI design.
> (Candy machine interfaces ftw!)
> I strongly believe that community is a critical part of software
> development. I am pretty psyched/honored to now be included in the
> ADF EMG community!
> My pet peeve is unnecessarily vague error messages.
> My favorite Java Posse member is Dick Wall.
> The compiler is my friend.
> I am not a "brogrammer".
> Er… okay, might be getting off track here.
> Looking forward to answering whatever questions I can, but I am
> especially excited to hear about your experiences using ADF Faces and/
> or JSF.
On Wed, May 2, 2012 at 8:32 PM, Chris Muir <chriscm...@gmail.com> wrote:
> On behalf of the EMG members thanks very much to agreeing to be part
> of the next "I am" series on the ADF EMG.
Thanks Chris - I am very happy to be part of this series!
BTW, All - apologies ahead of time for any delays in responding.
Unfortunately I seem to be unable to fully escape my day job. :-)
> 19 years! Are you sure you didn't found Oracle with Uncle Larry? It
> never ceases to me amaze me how long some people have been at Oracle.
During my initial orientation (back in 1993), I remember one of the
presenters sharing a statistic that the average stay at Oracle was 2
1/2 years. I guess I am an outlier. :-) Though I am not the most
senior developer on the ADF Faces team. That honor goes to my
colleague and mentor, Blake Sullivan, who arrived at Oracle a few
years before I did. (Blake is also active in the JSF expert group
discussions.)
The ADF Faces team has been very lucky in that we've got a group of
strong, dedicated developers who genuinely seem to enjoy working with
each other and with this area of the tech stack. That's a big part of
the reason why I have stuck around all of these years.
> So what do you get from Oracle when you hit the 20 year mark? One of
> Larry's boats? Oh, I look forward to the day when I can sail the
> seven seas as a salty Oracle sea dog.....
Lol. It's been a while since I have checked the employee handbook,
though I've got my hopes up that the 20 year gift is something cool
like… oh, how about legal signing authority for approving use of open
source projects in Oracle products? Yeah! I'm sure it's something
awesome like that. :-)
> What I find interesting about the history of products you've worked on
> at Oracle, is that in many cases Oracle has been pushing the envelope
> by taking a current technology and extending it (e.g. Oracle Toolkit,
> EWT, UIX and now ADF Faces).
Funny thing is that I hadn't really thought about it in that light
until I wrote up my little intro yesterday. When I re-read my blurb,
it hit me that, yeah, we've had a really good run at pushing our tech
stack forward to keep up with the changing times/trends.
> What do you believe is the primary
> driver for this model? I'm guessing Oracle in building software for
> its customers often finds solutions incomplete for its needs, so a new
> toolkit is built. Historically this doesn't look to be that customer
> focused.
You are right that historically the starting point for many of these
projects has been demand from Oracle internal product teams. UIX was
in use internally for quite a while before it found its path to
external users (via JDeveloper). ADF Faces was the first project that
I worked on where from day 1 we knew that we would be targeting an
external audience.
These days we've got such an incredible range of applications being
built on top of ADF, both internally and externally. Our users are
often ahead of the curve, looking to solve problems that require
pushing our framework/components in ways that we might not have
anticipated. This is a significant driving factor in the
enhancement/evolution of our offerings.
> Yet with the transition to UIX then JSF this appears to have changed.
> I must admit I became aware of you through your blog and submissions
> to the JSF specification. It seems to me that Oracle has been a keen
> player in the JSF world (for members that's since ~2004), very much
> community focused through its collaboration with JSR-344
> (http://bit.ly/IzMnyC) and the JCP.
Yep. Long before I got involved, my (former) colleague Adam Winer
played a very active role in the original JSF expert groups (up
through the start of JSF 2.0).
> Can you comment on how your job
> has changed (if at all) from being internally focused to now having to
> consider the wider (JSF) communities needs? Or does the JSF JCP act
> as a cabal of brogrammers?
Hah!
In a personal sense, participating in the JCP has without a doubt
raised my awareness of the importance of community. A common knock
against JSF 1.x was that it seemed to be designed in isolation. Maybe
not so much a "cabal", though I do seem to remember the term "ivory
tower" being mentioned here and there. There was a clear awareness of
this when I joined the JSF expert group shortly after 2.0 got
underway. This definitely led to a more community-focused process,
which, of course, led to a better outcome.
One of my favorite things about our expert group was that both the
members and the spec leads were enthusiastic about improving
transparency/community involvement. So, for example, although the
expert group discussions were historically done on private mailings
lists, Ed Burns (spec lead) opened our discussions to the public [1].
EG members pushed for additional openness - eg. changing how user
feedback was provided, getting our EG discussion archives online,
inviting "extended" expert group members to the discussion. It seems
that we anticipated (and maybe helped to instigate?) some of the JCP
reforms that are being enacted via JCP.next [2].
I should note that the JSF 2.2 JSRs are being run in a similarly open
manner. Anyone who is interested in monitoring expert group
discussions can do so either via the expert group list archive [3] or
by subscribing to the us...@javaserverfaces-spec-public.java.net
mailing list [4]. (Requires java.net login to subscribe.) I would
love to see more participation on the users list!
Hrm. I can go on for days on this topic (and maybe more thoughts
later in the thread), but let's just say that my experience with the
JSF EG has moved me towards favoring very open, community-oriented
projects/process.
On May 3, 4:43 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> Hello and welcome Andy.
Thanks Michael!
> +1 for Chris questions.
> From my experience customers (and java developer) are very impressed
> the first time they see ADF faces.
> I also believe it is the most creative and productive framework on JSF
> framework, with numerous components and options.
Thanks for that feedback!
> Yet, it is not simple. It has many devils in the detail.
Yes, understood.
> All customers have an opinion about the UI even when they have no idea
> what it does.
> The details are hard to implement , and browser's differences increase
> the complexity.
Our goal is to protect our application developers from browser
differences wherever possible. I know that we aren't perfect in this
regard, but I would have thought that exposure to browser differences
would have been a relatively rare occurrence.
Don't suppose you could shed a little more light on what sorts of
issues you have hit? Definitely interested in hearing more about
this.
> Also performance and usability are still not as good as client
> applications.
Are you thinking primarily of the to the ability to handle more user
interaction locally on the client rather than performing Ajax-style
round trips to the server? Or other areas?
> I would like to ask what would you expect as future UI technologies
> and tools.
> Will it be JSF2(X) and html5(X) or should we expect moving back to
> more client based technology?
Great question. It seems like yesterday that I first downloaded this
interesting piece of software called the Mosaic web browser. It blows
my mind just how far browser-based standards/technologies have come!
Without a doubt web applications are going to increasingly leverage
the power provided by modern browsers. I think that there will always
be a range of options for how application developers prefer to go
about doing this. There will surely be a growing contingent of folks
who prefer to avoid any server-centric framework (not just JSF). On
the other hand, there will be plenty of developers who are happy to
continue leveraging their favorite server-side frameworks.
For the latter camp, I think the key question is going to be whether
these frameworks are able to take advantage of emerging client-side
technologies while still providing the traditional benefits of
server-side frameworks. Personally, I think that JSF is well
positioned here and I expect that we'll see JSF (and ADF)
users/applications benefiting from advances in browser technology.
Actually, it's not just that I think this… it's a necessity.
Frameworks that fail to keep up will simply lose out over time.
BTW, a question for you and for other folks reading this thread, regarding:
> It has many devils in the detail.
Aside from browser differences, are there areas of ADF Faces (or JSF)
that you find particularly troublesome/difficult to work with? I
skimmed through the recent skinning thread. Seems like that has been
a pain point. What else trips folks up?
On Thu, May 3, 2012 at 9:46 AM, Jan Vervecken <verv...@gmail.com> wrote:
> Thank you for your message Andy.
> You describe your work for Oracle on different UI technologies
> repeatedly with a remark like "think X before there was X".
Er… I hope that didn't come across as too pretentious. :-D
> Given that we now have mobile platforms and related UI technologies,
> what has been the evolution for Oracle in that area, or how do you see
> this evolve in the future?
On the ADF Faces side, our goal initial goal is to ensure that our
components are fully functional on touch devices. This unfortunately
does not come for free. :-/ In addition, we are looking at ways to
reduce our footprint for better experience on higher latency
connections.
Looking to the future, we have a parallel "ADF Mobile" effort
underway. See the following document on product direction:
The goal of ADF Mobile is to offer ADF developers the best of both
worlds - ie. it will allow developers to apply their existing ADF
skills to build applications that can be installed directly on mobile
devices (and thus take advantage of native mobile facilities).
> Er… I hope that didn't come across as too pretentious. :-D
Not at all. You should be proud on your accomplishments.
I was only looking for an equivalent "think X before there was X"
remark for the current mobile reality.
regards
Jan Vervecken
On May 3, 7:48 pm, Andy Schwartz <andy.g.schwa...@gmail.com> wrote:
> On Thu, May 3, 2012 at 9:46 AM, Jan Vervecken <verv...@gmail.com> wrote:
> > Thank you for your message Andy.
> > You describe your work for Oracle on different UI technologies
> > repeatedly with a remark like "think X before there was X".
> Er… I hope that didn't come across as too pretentious. :-D
> > Given that we now have mobile platforms and related UI technologies,
> > what has been the evolution for Oracle in that area, or how do you see
> > this evolve in the future?
> On the ADF Faces side, our goal initial goal is to ensure that our
> components are fully functional on touch devices. This unfortunately
> does not come for free. :-/ In addition, we are looking at ways to
> reduce our footprint for better experience on higher latency
> connections.
> Looking to the future, we have a parallel "ADF Mobile" effort
> underway. See the following document on product direction:
> The goal of ADF Mobile is to offer ADF developers the best of both
> worlds - ie. it will allow developers to apply their existing ADF
> skills to build applications that can be installed directly on mobile
> devices (and thus take advantage of native mobile facilities).
First, thanks for sitting in our little group - it's nice to be able to interact with the implementation teams.
I have a relatively simple question that may not have a short answer: in the past we've seen Oracle contribute some of the technologies behind ADF to the open source community - thinking primarily here of the 'Trinidad' components to the Apache Software Foundation.
ADF also has several features that make JSF 'more useful' - particularly the controller/task flow architectures that are a fantastic extension of the JSF controller. We've also seen the ADF Model/binding approach submitted then withdrawn from the JSR process.
In your position with a foot in both camps, do you see interest in contributing some of the advances and extensions to JSF to the Java community, either through the JSR process or the open source community again?
(I also recall some rumblings about an "ADF Community Edition" sometime back - is that possibly related?)
Greetings to all the ADF gurus in this community and especially to Mr Andy
Schwartz!
It was pleasure for me to hear how things kept going in the eyes of a man
from the kitchen.
We all know that old technologies like Oracle Toolkit, AWT and UIX used to
be the top-notch players,
just like JSF and ADF currently are. As unlikely it had seemed, they got
dropped out as new technologies were emerging.
What I am interested in is whether Oracle is already looking in the crystal
ball, foreseeing what future changes might drive JSF and ADF out of the
game.
Maybe the mobile and social era won't change the rules so much, unlike
cloud operating systems might? Although we are absorbed in nowadays
technologies, if Oracle had not kept innovating, it wouldn't be the company
we all know today.
On Thu, May 3, 2012 at 8:12 PM, Chad Thompson <chad_thomp...@mac.com> wrote:
> Andy:
> First, thanks for sitting in our little group - it's nice to be able to
> interact with the implementation teams.
> I have a relatively simple question that may not have a short answer: in
> the past we've seen Oracle contribute some of the technologies behind ADF
> to the open source community - thinking primarily here of the 'Trinidad'
> components to the Apache Software Foundation.
> ADF also has several features that make JSF 'more useful' - particularly
> the controller/task flow architectures that are a fantastic extension of
> the JSF controller. We've also seen the ADF Model/binding approach
> submitted then withdrawn from the JSR process.
> In your position with a foot in both camps, do you see interest in
> contributing some of the advances and extensions to JSF to the Java
> community, either through the JSR process or the open source community
> again?
> (I also recall some rumblings about an "ADF Community Edition" sometime
> back - is that possibly related?)
> --
> 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-methodology+unsubscribe@googlegroups.com
On Thursday, May 3, 2012 at 6:13 PM, missgeburt wrote:
> What I am interested in is whether Oracle is already looking in the crystal ball, foreseeing what future changes might drive JSF and ADF out of the game.
I'll jump in with a quick comment: JSF/ADF is (for the foreseeable future) built on a stronger foundation for future adaptation than some of the older Oracle UI technologies. This isn't necessarily because of the specific technology base - but rather because the 'future' right now seems to be the dreamed of past: the open web, driven primarily by HTML5.
In addition there is a certain maturity that 'component driven' programming of JSF that is finally arriving. We can use a 'component' such as <af:calendar/> in business applications and rely on framework developers to ensure that the component is cross-browser compliant, corresponds to the appropriate markups, etc.
The approach certainly isn't perfect (as most of us can attest to), but ADF (and JSF) is hitting that stride where things are improving with every release - certainly this bodes well for making an investment now in developing JSF/ADF applications versus other non-component driven web frameworks. (Compare to the plethora of Apache Struts apps out there - many of them were pretty good apps for the time, but once a need to modernize hit, developers ended up re-writing the view layers just to incorporate things like table-less CSS layouts.)
It's good to see someone who has been part of every technology that when it
evolves, he adapts and evolves with it, and it's good that you have been in
Oracle for that amount of time and still take your technical skills
seriously!!!
My question is a bit different, as its concerned about how the direction of
the ADF is going, as Using Struts as a main framework at first, and then
JSF 1.x as a component based framework that only understands JSF syntax,
which evolves to JSF 2.0 which is a hybrid between JSF syntax and HTML
syntax thanks to facelets, and still evolving... Who knows maybe in JSF3 we
might see something like GWT or Vaadin that is application based framework,
which a developer can draw screens the same way as they do in Desktop
application.
Don't get me wrong, I still prefer dealing with the way JSF does, but as
technology moves forward, and the need to JS Applications rise and Mobile
apps, it seems that this is the way to unify things and taking the headache
out of the developers.
My question is from your experience of Frameworks and how the web has
evolved so far, what do you think of the fate of ADF as Framework?
On Fri, May 4, 2012 at 3:41 AM, Chad Thompson <chad_thomp...@mac.com> wrote:
> On Thursday, May 3, 2012 at 6:13 PM, missgeburt wrote:
> What I am interested in is whether Oracle is already looking in the
> crystal ball, foreseeing what future changes might drive JSF and ADF out of
> the game.
> I'll jump in with a quick comment: JSF/ADF is (for the foreseeable
> future) built on a stronger foundation for future adaptation than some of
> the older Oracle UI technologies. This isn't necessarily because of the
> specific technology base - but rather because the 'future' right now seems
> to be the dreamed of past: the open web, driven primarily by HTML5.
> In addition there is a certain maturity that 'component driven'
> programming of JSF that is finally arriving. We can use a 'component' such
> as <af:calendar/> in business applications and rely on framework developers
> to ensure that the component is cross-browser compliant, corresponds to the
> appropriate markups, etc.
> The approach certainly isn't perfect (as most of us can attest to), but
> ADF (and JSF) is hitting that stride where things are improving with every
> release - certainly this bodes well for making an investment now in
> developing JSF/ADF applications versus other non-component driven web
> frameworks. (Compare to the plethora of Apache Struts apps out there -
> many of them were pretty good apps for the time, but once a need to
> modernize hit, developers ended up re-writing the view layers just to
> incorporate things like table-less CSS layouts.)
> --
> 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-methodology+unsubscribe@googlegroups.com
Not all ADF EMG members will be familiar with what the main goals of
JSF 2.2 are. Could you summarize and give an idea of what areas you
have a particular interest in please Andy?
In turn what is an interesting question is the fact for many years ADF
was ahead of the game for JSF, but recently in parts JSF has caught up
and implemented some common features. For example the AJAX support
added in JSF 2.0. This does seem to create an issue for Oracle
because where it was ahead of the game, it's now kind of off on it's
own game in some parts of the Oracle JSF solution, or indeed there's
two solutions - the Oracle one and the JSF one. Given that you're
part of the expert group designing the upcoming JSF specs, how do you
balance the need for stability for Oracle vs the need for improvements
for the wider JSF community?
CM.
On 3 May 2012 23:13, Andy Schwartz <andy.g.schwa...@gmail.com> wrote:
> On Wed, May 2, 2012 at 8:32 PM, Chris Muir <chriscm...@gmail.com> wrote:
> I should note that the JSF 2.2 JSRs are being run in a similarly open
> manner. Anyone who is interested in monitoring expert group
> discussions can do so either via the expert group list archive [3] or
> by subscribing to the us...@javaserverfaces-spec-public.java.net
> mailing list [4]. (Requires java.net login to subscribe.) I would
> love to see more participation on the users list!
> Hrm. I can go on for days on this topic (and maybe more thoughts
> later in the thread), but let's just say that my experience with the
> JSF EG has moved me towards favoring very open, community-oriented
> projects/process.
> --
> 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-methodology+unsubscribe@googlegroups.com
On May 3, 8:01 pm, Andy Schwartz <andy.g.schwa...@gmail.com> wrote:
> Our goal is to protect our application developers from browser
> differences wherever possible. I know that we aren't perfect in this
> regard, but I would have thought that exposure to browser differences
> would have been a relatively rare occurrence.
> Don't suppose you could shed a little more light on what sorts of
> issues you have hit? Definitely interested in hearing more about
> this.
One of the main issues we have is that our ADF application is faster
in Firefox than IE.
Also java scripts and css changes does not behave the same in
different browsers.
Also some components are displayed and behave differently (i.e.
af:inputText with rows>1 is resizable in firefox but not in IE, in IE
it display scroll-bars)
> > Also performance and usability are still not as good as client
> > applications.
> Are you thinking primarily of the to the ability to handle more user
> interaction locally on the client rather than performing Ajax-style
> round trips to the server? Or other areas?
> Aside from browser differences, are there areas of ADF Faces (or JSF)
> that you find particularly troublesome/difficult to work with? I
> skimmed through the recent skinning thread. Seems like that has been
> a pain point. What else trips folks up?
We have many requirements from our customers that concerns heavy data
entry operations like the tab
order, the Focus on ADF components, and shortcut keys
These requirements can only be applied with java scripting which in
many cases it is challenging, like
--> Focus should be in the first input component in a new row after
insert operation is performed (they want this in all editable tables).
--> Focus to be inside query criteria when query page opens
--> When a value is selected in an input list of values field the
focus to move to the next input field.
--> When you focus out the last field of the last row of an ADF table
a new row to be created (there is no focusOut type for client
listener)
--> Tab key to skip icons (date, lov)
--> Tab not to go on browser controls
--> Shortcut keys to navigate to menu items
--> Shortcut keys on main page not to be functional when a popup is
open.
etc...
These are logical requirements that users have used to have in client
applications, yet they cost too much to develop with java scripting in
each component.
It would be really useful if some of this functionality was added to
ADF Faces components, or a declarative way existed in order to define
such behavior.
I like that ADF can adapt to the different capabilities of the browser in which it is running. This will be particularly important for mobile applications that may be running on iPhone or Android Phone or iPad or Android tablet, or even President Obama's Blackberry. It is for us, the developers, to test our applications in as many of the expected execution environments as we can and see how it renders. If we don't like it, we should probably go back and either choose another component, or try different properties for the original choice.
I assume that after a while, we'll know from experience what works for our environment, and what doesn't.
I know that Oracle's developers will continue to improve how the product renders too, and improve how it adapts to different browsers. It is a HARD nut to crack, and I don't blame them if they get it wrong from time to time. Besides, my wrong might be someone else's right - can't please all the people all the time.
I just hope they won't change things too much too fast - I hate it when an upgrade turns into a total re-write.
Apologies for going quiet on this thread. Work/life are conspiring to
not make this easy, but I will be back in action soon. Thanks for all
of the excellent questions so far!
On Thu, May 3, 2012 at 3:12 PM, Chad Thompson <chad_thomp...@mac.com> wrote:
> Andy:
> First, thanks for sitting in our little group - it's nice to be able to
> interact with the implementation teams.
Thanks Chad! I am so happy to have this opportunity to interact with you all.
> I have a relatively simple question that may not have a short answer: in
> the past we've seen Oracle contribute some of the technologies behind ADF to
> the open source community - thinking primarily here of the 'Trinidad'
> components to the Apache Software Foundation.
Right.
> ADF also has several features that make JSF 'more useful' - particularly the
> controller/task flow architectures that are a fantastic extension of the JSF
> controller.
I agree - tasks flows are a great addition to the JSF ecosystem. (I
am not saying that to be self-congratulatory, as task flows are not
provided by the ADF Faces team, but by our sibling ADF Controller
team. I am very impressed with what they have done here!)
It is interesting that you mention this particular feature, as
standardization of task flow-like functionality is happening now. Ed
Burns is leading the standardization effort of this area, dubbed
"Faces flows", which is targeted for inclusion in the JSF 2.2
specification. Our ADF Controller team has been actively supporting
this effort.
> We've also seen the ADF Model/binding approach submitted then
> withdrawn from the JSR process.
> In your position with a foot in both camps, do you see interest in
> contributing some of the advances and extensions to JSF to the Java
> community, either through the JSR process or the open source community
> again?
Yes. As for open source, we'll continue to push functionality down
into Trinidad where this makes sense. Determining which features to
pursue at the JSF spec level can be a bit tricky. My old friend (and
former JSF EG representative) wrote up some thoughts on this topic
that I still find interesting. See his "What belongs in the JSF
standard" blog entry:
- about "It would be really useful if some of this functionality was
added to ADF Faces components, or a declarative way existed in order
to define such behavior."
Have you created Oracle enhancement requests for these navigation/
focus features you describe?
regards
Jan Vervecken
On May 4, 11:56 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> On May 3, 8:01 pm, Andy Schwartz <andy.g.schwa...@gmail.com> wrote:
> > Our goal is to protect our application developers from browser
> > differences wherever possible. I know that we aren't perfect in this
> > regard, but I would have thought that exposure to browser differences
> > would have been a relatively rare occurrence.
> > Don't suppose you could shed a little more light on what sorts of
> > issues you have hit? Definitely interested in hearing more about
> > this.
> One of the main issues we have is that our ADF application is faster
> in Firefox than IE.
> Also java scripts and css changes does not behave the same in
> different browsers.
> Also some components are displayed and behave differently (i.e.
> af:inputText with rows>1 is resizable in firefox but not in IE, in IE
> it display scroll-bars)
> > > Also performance and usability are still not as good as client
> > > applications.
> > Are you thinking primarily of the to the ability to handle more user
> > interaction locally on the client rather than performing Ajax-style
> > round trips to the server? Or other areas?
> > Aside from browser differences, are there areas of ADF Faces (or JSF)
> > that you find particularly troublesome/difficult to work with? I
> > skimmed through the recent skinning thread. Seems like that has been
> > a pain point. What else trips folks up?
> We have many requirements from our customers that concerns heavy data
> entry operations like the tab
> order, the Focus on ADF components, and shortcut keys
> These requirements can only be applied with java scripting which in
> many cases it is challenging, like
> --> Focus should be in the first input component in a new row after
> insert operation is performed (they want this in all editable tables).
> --> Focus to be inside query criteria when query page opens
> --> When a value is selected in an input list of values field the
> focus to move to the next input field.
> --> When you focus out the last field of the last row of an ADF table
> a new row to be created (there is no focusOut type for client
> listener)
> --> Tab key to skip icons (date, lov)
> --> Tab not to go on browser controls
> --> Shortcut keys to navigate to menu items
> --> Shortcut keys on main page not to be functional when a popup is
> open.
> etc...
> These are logical requirements that users have used to have in client
> applications, yet they cost too much to develop with java scripting in
> each component.
> It would be really useful if some of this functionality was added to
> ADF Faces components, or a declarative way existed in order to define
> such behavior.
On Thu, May 3, 2012 at 7:13 PM, missgeburt <missgeb...@gmail.com> wrote:
> Greetings to all the ADF gurus in this community and especially to Mr Andy
> Schwartz!
> It was pleasure for me to hear how things kept going in the eyes of a man
> from the kitchen.
Thank you, Todor! I am thoroughly enjoying this. Might need to stick
around this group. At least until I wear out my welcome. :-)
> We all know that old technologies like Oracle Toolkit, AWT and UIX used to
> be the top-notch players,
> just like JSF and ADF currently are. As unlikely it had seemed, they got
> dropped out as new technologies were emerging.
> What I am interested in is whether Oracle is already looking in the crystal
> ball, foreseeing what future changes might drive JSF and ADF out of the
> game.
Oh, my. Toughest question yet! This is the one that haunts my dreams.
I don't suppose that I can get away with saying that I like Chad's answer? :-)
I do think that Chad is onto something: JSF/ADF provide some level of
future-proofing by virtue of its component abstraction. We've already
seen this work to our benefit - for example, the DVT components being
able to fallback from Flash to other renderings without requiring the
application to rewrite.
> Maybe the mobile and social era won't change the rules so much, unlike cloud
> operating systems might?
I also think that JSF/ADF are set up to manage a transition to the
cloud fairly well.
What other trends do folks see that the evolution of web application
development?
Mobile and a diversity of devices is clearly a big one.
Real-time, full-duplex communication (ie. WebSockets) is another.
High-speed connections everywhere?
Increasingly powerful web browsers.
Diversification of applications/clients away from the web browser?
Hrm… seems like JSF/ADF should be able embrace many of these. It is
hard to say at what point we shift from evolution to revolution. I
guess all I can say is that we live in exciting times and I hope I can
stick around long enough to see what comes next!
On that note, it now seems completely inappropriate but somewhat
timely to include this totally off-topic link:
On Thu, May 3, 2012 at 10:33 PM, Amr Gawish <amr.gaw...@gmail.com> wrote:
> Hello Andy,
> First welcome to ADF EMG.
Thanks Amr!
BTW, I like your profile pic. I've got some pics just like that. :-)
> It's good to see someone who has been part of every technology that when
> it evolves, he adapts and evolves with it, and it's good that you have been
> in Oracle for that amount of time and still take your technical skills
> seriously!!!
:-)
Is it just me or do you ever feel like there are so many interesting
technologies (languages, frameworks, tools) available today that it is
impossible to learn everything that you want/need to know? :-/
> My question is a bit different, as its concerned about how the direction
> of the ADF is going, as Using Struts as a main framework at first, and then
> JSF 1.x as a component based framework that only understands JSF syntax,
> which evolves to JSF 2.0 which is a hybrid between JSF syntax and HTML
> syntax thanks to facelets, and still evolving... Who knows maybe in JSF3 we
> might see something like GWT or Vaadin that is application based framework,
> which a developer can draw screens the same way as they do in Desktop
> application.
FWIW, it is possible to built desktop-like applications today on top
of JSF/ADF. Though I also think that things seem to be trending away
from traditional desktop-like UIs, even on the desktop! (Thinking
about Windows 8/Metro.)
> Don't get me wrong, I still prefer dealing with the way JSF does, but as
> technology moves forward, and the need to JS Applications rise and Mobile
> apps, it seems that this is the way to unify things and taking the headache
> out of the developers.
Think you nailed a key goal: eliminating development headaches is critical.
> My question is from your experience of Frameworks and how the web has
> evolved so far, what do you think of the fate of ADF as Framework?
My feeling is that HTML5 is going to be a unifying technology across
platforms. This recent article on LinkedIn's new iPad app provides
one interesting data point:
(Some controversial comments on responsive web design as well.)
I think that ADF's path forward is to embrace HTML5 and other modern
browser technologies. ADF Mobile will take this a step further by
allowing ADF developers to harness native mobile device capabilities.
Time will tell how much progress we can make with headache
elimination. That goal is always present in our minds.
And, now you've got me wondering what direction "JSF3" might take.
Though it would probably be best for me to see what I can do to help
out with 2.2 first. :-)
Firstly, I must apologize because when I first saw your name on MyFaces
list I thought your were a recent promising addition to Oracle's team,
while it turns out that you're a not so recent, but still promising (and
young of course!) one.
Now to my questions, which are based on the most common complains I have to
face toward ADF Faces or even JSF in general.
I think most people agree that the component based model is great. As a
proof, it was already mentioned in this topic. Also, JSF 2.0 greatly
improved the GET support through preemptive navigation as well as view
parameters. That being said, JSF (and especially ADF Faces RC) remains more
oriented to application development than web site development due mostly to
the lack of GET form submission (using h:form that is). Do you think that
trend is going to stay or do you believe that JSF will evolve to include
more basic HTML features so that we can have a component based framework
that allows full control of GET/POST if the need shows up?
My next question is more specific to ADF Faces RC as well the skinning
which is what web designers hate the most about the technology. Before
anything else, we need to face something: the generated HTML is not perfect
in ADF Faces. I have my own personal shame about the tr:train which use
nested tables to give the train its layout, but I'm wiser today... To the
same extent, I'm wondering if Oracle's approach toward the generated HTML
has evolved with time, since you were there from the time of UIX, I guess
you can have a very relevant conception of that. Also I'd like to know what
kind of validation the generated HTML for a component goes through before
being released.
Also, are you planning to change the HTML generated with time? This could
be especially relevant with the rise of HTML 5. I see a major hurdle with
backward compatibility however and that problem will be mostly due to
skinning which also happen to be more complex than it should be. One of the
main issue is that ADF Faces try to exposes selectors for most HTML
elements in the component while trying to promise that the HTML may change,
but the selector will remain. That sounded great when I first started to
work on Trinidad, but now that I have much more CSS experience (since I
always end up doing the skinning), I wonder if it's realistic. I can hardly
see how you can maintain all the selectors if you reduce the amount of tag
generated for example or even keep about the same look if you go from a div
to a span and the skin does not provide a display property for example. So,
basically, the only way I see it to work well would be to create a
completely new render kit so that users can choose when to switch from
"rich" to "html5" (tentative name). Is it something you're considering or
am I completely out of my mind?
On the same subject, but more skinning oriented now and it more a
suggestion than a question. If you do plan to change HTML, I'd suggest to
use only a style class on the root HTML tag of each component as well as
state style classes on the root or the child elements. That would make web
designers' life much easier I think since they would not have to
reverse-engineer the selector from the class names in Firebug and would
also reduce the amount of style classes needed, reducing both the HTML code
and the CSS. This would bring the problem of having the CSS depending on
the generated HTML but, from experience, I'd say that it's already the case
anyway.
Let go a bit more technical now, component creation. I assume I'm one of
the rare person who's creating brand new ADF Faces RC components (not
composite), but I think it's a shame as the framework itself is where ADF
Faces' real power lie imho. However, that power is also very hermetic and
pretty much undocumented (I'm talking to you *Peer.js). Furthermore,
component creation requires quite a bit of boilerplate code
(adf-js-feature, faces-config.xml, something.tld, tag class, tag handler,
...) as is totally not tooled in JDeveloper. I assume this question is more
toward the JDeveloper team, but does Oracle plan to make component creation
easier with time or is the approach to try to provide everything needed in
the toolbox and at best keep the composite components for user to create
customizations? One of the component I had to create recently, for example,
is what we call a selectPartialBooleanCheckbox, also known as tri-state
checkbox which allows values UNSELECTED, PARTIALLY_SELECTED and
FULLY_SELECTED. Creating such component using the composite facility is
doable, but quite hard if you want to support key shortcuts and will most
likely requires a loop to the server when the user click on it to change
the visual look.
Finally, let talk about the Web flow / task flow feature that is coming in
JSF. I must admit that the task flows is one the best new feature in 11g so
I do send my kudos to the ADFc team as well. One thing lacking I though
however is the ability to define custom activities. Of course you can
always do a method call, but I think the activity equivalent of a tag
library would have been very nice. this could be useful when an enterprise
has a common process that need to be done repeatedly. Instead of forcing
the developers from knowing the exact method with what parameters to call,
one could see the gain of simply exposing a custom ActivityLogic that
encapsulate all that and would simply need to be dragged on the task flow.
Is that something the ADFc team see for the future? Is that something being
considered for the JSF specification? On a more technical level, how do you
think the flows will work with preemptive navigation? For example, let say
you have page1 (outcome next)--> methodCall (outcome *)--> page2 in the
unbounded task flow (the root task flow, the one affecting the URL). What
happen if you have <h:link outcome="next"/> in page1? Will the method be
called? Will the method call have its own URL so that the preemptive
navigation goes there instead of directly to page2? What would be the right
approach in your opinion?
Thanks!
~ Simon
On Fri, May 4, 2012 at 9:51 PM, Andy Schwartz <andy.g.schwa...@gmail.com>wrote:
> On Thu, May 3, 2012 at 10:33 PM, Amr Gawish <amr.gaw...@gmail.com> wrote:
> > Hello Andy,
> > First welcome to ADF EMG.
> Thanks Amr!
> BTW, I like your profile pic. I've got some pics just like that. :-)
> > It's good to see someone who has been part of every technology that when
> > it evolves, he adapts and evolves with it, and it's good that you have
> been
> > in Oracle for that amount of time and still take your technical skills
> > seriously!!!
> :-)
> Is it just me or do you ever feel like there are so many interesting
> technologies (languages, frameworks, tools) available today that it is
> impossible to learn everything that you want/need to know? :-/
> > My question is a bit different, as its concerned about how the direction
> > of the ADF is going, as Using Struts as a main framework at first, and
> then
> > JSF 1.x as a component based framework that only understands JSF syntax,
> > which evolves to JSF 2.0 which is a hybrid between JSF syntax and HTML
> > syntax thanks to facelets, and still evolving... Who knows maybe in JSF3
> we
> > might see something like GWT or Vaadin that is application based
> framework,
> > which a developer can draw screens the same way as they do in Desktop
> > application.
> FWIW, it is possible to built desktop-like applications today on top
> of JSF/ADF. Though I also think that things seem to be trending away
> from traditional desktop-like UIs, even on the desktop! (Thinking
> about Windows 8/Metro.)
> > Don't get me wrong, I still prefer dealing with the way JSF does, but as
> > technology moves forward, and the need to JS Applications rise and Mobile
> > apps, it seems that this is the way to unify things and taking the
> headache
> > out of the developers.
> Think you nailed a key goal: eliminating development headaches is critical.
> > My question is from your experience of Frameworks and how the web has
> > evolved so far, what do you think of the fate of ADF as Framework?
> My feeling is that HTML5 is going to be a unifying technology across
> platforms. This recent article on LinkedIn's new iPad app provides
> one interesting data point:
> (Some controversial comments on responsive web design as well.)
> I think that ADF's path forward is to embrace HTML5 and other modern
> browser technologies. ADF Mobile will take this a step further by
> allowing ADF developers to harness native mobile device capabilities.
> Time will tell how much progress we can make with headache
> elimination. That goal is always present in our minds.
> And, now you've got me wondering what direction "JSF3" might take.
> Though it would probably be best for me to see what I can do to help
> out with 2.2 first. :-)
> Andy
> --
> 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-methodology+unsubscribe@googlegroups.com
On Fri, May 4, 2012 at 5:05 AM, Chris Muir <chriscm...@gmail.com> wrote:
> Not all ADF EMG members will be familiar with what the main goals of
> JSF 2.2 are. Could you summarize and give an idea of what areas you
> have a particular interest in please Andy?
Sure. Although JSF 2.0 did a great job of tackling many of the
highest visibility spec limitations/issues, it was simply not possible
to address all requirements in one release. JSF 2.1 ended up being a
fairly minor spec rev, in part because this work was done via the
JCP's maintenance release process rather than as a formal JSR. JSF
2.2 (jsr-344) is our first post-2.0 to opportunity to really advance
the specification again.
Rather than summarize the 2.2 work, I'll instead recommend reading
this wonderful (and regularly updated) summary written by Arjan Tijms:
As for my particular areas of interest, well… to be honest my biggest
interest, which goes beyond anyone particular feature, is performance.
As you've probably seen, we build some fairly complex JSF-based
apps/UIs here at Oracle. We also focus a significant amount of energy
on devising optimizations to allow our complex apps to perform/scale.
One of my most important goals for any rev of the JSF spec is to (try
to) ensure that we do not unintentionally introduce any new sources of
overhead that might regress performance/scalability.
As for specific features, aside from Faces Flows, two other features
that I find particularly interesting (and, sadly, have not yet had
time to review thoroughly), are window id support (which Trinidad/ADFv
already provides) and view actions.
> In turn what is an interesting question is the fact for many years ADF
> was ahead of the game for JSF, but recently in parts JSF has caught up
> and implemented some common features. For example the AJAX support
> added in JSF 2.0. This does seem to create an issue for Oracle
> because where it was ahead of the game, it's now kind of off on it's
> own game in some parts of the Oracle JSF solution, or indeed there's
> two solutions - the Oracle one and the JSF one. Given that you're
> part of the expert group designing the upcoming JSF specs, how do you
> balance the need for stability for Oracle vs the need for improvements
> for the wider JSF community?
Great question!
Fortunately, for the most part these two goals (stability for existing
apps + enhancements that advance the platform) have not been mutually
exclusive. Most of the new APIs that were introduced in JSF 2.0
complement existing APIs, thus allowing (relatively) smooth upgrades.
There are some subtleties here (eg. new tree visiting requirements),
though these tend to impact component and framework developers more so
than application developers. (Upgrading Trinidad/ADF to JSF2 was not
trivial. However, upgrading Trinidad/ADF-based applications to JSF2
should be.)
As an expert group member, my top priority is to help produce the best
possible result for all JSF users. I am always happy to see folks
having positive application development experiences with JSF,
regardless of what component set they happen to be using. SImilarly,
I am always interested in what sorts of difficulties our users are
struggling with, regardless of their choice of component set.
As a representative of Oracle/ADF, I of course have an interest in
seeing new APIs evolve in a way that is compatible with our existing
ADF feature set. However, this does not simply mean pushing for
unchallenged standardization of our Trinidad/ADF APIs. The expert
group is made up of some extremely talented developers who bring their
own experiences and viewpoints to the table. I always welcome
engagement from my fellow EG members (and community members) even if
this means having to rethink existing designs.
As you point out, this does mean that we end up with overlap between
JSF and ADF features. The best outcome is when our overlapping
features can work together in an integrated fashion (eg. <f:ajax> and
partialTriggers). In some cases it is simply tough to avoid having
parallel features (eg. JSF2 composite components vs. ADF declarative
components). For such cases, we'll continue to support our existing
APIs (which is critical for our own apps) while looking for ways to
ease migration from old to new.
Good to hear your biggest interest is performance. For me that's the biggest concern....
There are quite a few customers who build really large pages, often encouraged by (custom) implementations of our UI Shell Dynamic Tab template.
With this design, you easily have a number of independent tabs open, each tab holding an af:region with taskflow with page fragments.
Many ADF developers don't seem to realize that all those tabs are still one page with one UITree.
And even the simplest partial submit, which refreshes only one or two items within a tab, still causes the whole UITree to be processed although the browser only repaints the two items.
I have seen a significant impact on performance in apps with many tabs open and large page fragments with lots of sub-tabs and accordions. Currently, the only (supported) way to improve performance in such a scenario is to use the activie property on the taskflow binding and set the activation property to conditional (active=false when tab is not selected tab). When active property evaluates to false the af:region tag handler skips processing of the entire region. But this is troublesome, and means all server-side state of these taskflow is lost when switching tabs. (The unsupported way is to change the regiontag handler and skip processing when region.isRendered evalutes to false)
/*Partial state saving
*To reduce the overhead of state saving and management, JSF 2.0 introduces partial state saving
as new functionality. In an effort to provide continued backwards compatibility, ADF Faces will
utilize its existing state saving implementation while the new JSF 2.0 implementation matures.
/
This statement concerns me a bit. Can you explain what this means?
I read in your blog about JSF 2.0 <http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/> that Adam Winer created a solution for partial state saving on trinidad years ago which was used as the basis for PSS in JSF 2.0. This might imply that ADF Faces already uses some sort of PSS but that isn't true is it?
> On Fri, May 4, 2012 at 5:05 AM, Chris Muir<chriscm...@gmail.com> wrote:
>> Not all ADF EMG members will be familiar with what the main goals of
>> JSF 2.2 are. Could you summarize and give an idea of what areas you
>> have a particular interest in please Andy?
> Sure. Although JSF 2.0 did a great job of tackling many of the
> highest visibility spec limitations/issues, it was simply not possible
> to address all requirements in one release. JSF 2.1 ended up being a
> fairly minor spec rev, in part because this work was done via the
> JCP's maintenance release process rather than as a formal JSR. JSF
> 2.2 (jsr-344) is our first post-2.0 to opportunity to really advance
> the specification again.
> Rather than summarize the 2.2 work, I'll instead recommend reading
> this wonderful (and regularly updated) summary written by Arjan Tijms:
> As for my particular areas of interest, well� to be honest my biggest
> interest, which goes beyond anyone particular feature, is performance.
> As you've probably seen, we build some fairly complex JSF-based
> apps/UIs here at Oracle. We also focus a significant amount of energy
> on devising optimizations to allow our complex apps to perform/scale.
> One of my most important goals for any rev of the JSF spec is to (try
> to) ensure that we do not unintentionally introduce any new sources of
> overhead that might regress performance/scalability.
> As for specific features, aside from Faces Flows, two other features
> that I find particularly interesting (and, sadly, have not yet had
> time to review thoroughly), are window id support (which Trinidad/ADFv
> already provides) and view actions.
>> In turn what is an interesting question is the fact for many years ADF
>> was ahead of the game for JSF, but recently in parts JSF has caught up
>> and implemented some common features. For example the AJAX support
>> added in JSF 2.0. This does seem to create an issue for Oracle
>> because where it was ahead of the game, it's now kind of off on it's
>> own game in some parts of the Oracle JSF solution, or indeed there's
>> two solutions - the Oracle one and the JSF one. Given that you're
>> part of the expert group designing the upcoming JSF specs, how do you
>> balance the need for stability for Oracle vs the need for improvements
>> for the wider JSF community?
> Great question!
> Fortunately, for the most part these two goals (stability for existing
> apps + enhancements that advance the platform) have not been mutually
> exclusive. Most of the new APIs that were introduced in JSF 2.0
> complement existing APIs, thus allowing (relatively) smooth upgrades.
> There are some subtleties here (eg. new tree visiting requirements),
> though these tend to impact component and framework developers more so
> than application developers. (Upgrading Trinidad/ADF to JSF2 was not
> trivial. However, upgrading Trinidad/ADF-based applications to JSF2
> should be.)
> As an expert group member, my top priority is to help produce the best
> possible result for all JSF users. I am always happy to see folks
> having positive application development experiences with JSF,
> regardless of what component set they happen to be using. SImilarly,
> I am always interested in what sorts of difficulties our users are
> struggling with, regardless of their choice of component set.
> As a representative of Oracle/ADF, I of course have an interest in
> seeing new APIs evolve in a way that is compatible with our existing
> ADF feature set. However, this does not simply mean pushing for
> unchallenged standardization of our Trinidad/ADF APIs. The expert
> group is made up of some extremely talented developers who bring their
> own experiences and viewpoints to the table. I always welcome
> engagement from my fellow EG members (and community members) even if
> this means having to rethink existing designs.
> As you point out, this does mean that we end up with overlap between
> JSF and ADF features. The best outcome is when our overlapping
> features can work together in an integrated fashion (eg.<f:ajax> and
> partialTriggers). In some cases it is simply tough to avoid having
> parallel features (eg. JSF2 composite components vs. ADF declarative
> components). For such cases, we'll continue to support our existing
> APIs (which is critical for our own apps) while looking for ways to
> ease migration from old to new.
And even the simplest partial submit, which refreshes only one or two items
within a tab, still causes the whole UITree to be processed although the
browser only repaints the two items.
Make sure the task flow activation is set to deferred in the page def.
Also, you could prevent that with some hook (most likely a PhaseListener),
that would mark most tabs as setRendered(false) when a partial submit
occurs so that the processing gets short circuited. Another way (even more
drastic) would be to use a fitler that, when a partial submit is detected,
create a request wrapper to inject an URL parameter
named "oracle.adf.view.rich.PROCESS". This will short-circuit the lifecycle
to process only the ids within that comma separated list.
I read in your blog about JSF
2.0<http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/>
that Adam Winer created a solution for partial state saving on trinidad
years ago which was used as the basis for PSS in JSF 2.0. This might imply
that ADF Faces already uses some sort of PSS but that isn't true is it?
Yes Trinidad and ADF Faces RC have a partial state saving on which JSF 2.0
was based. From the comment, I simply assume that the ADF Faces team think
that the way it's handled in JSF 2.0 is not yet as good as the one in ADF
Faces, so they're sticking to the latter for now.
Regards,
~ Simon
On Mon, May 7, 2012 at 7:21 AM, Steven Davelaar
<steven.davel...@oracle.com>wrote:
> Good to hear your biggest interest is performance. For me that's the
> biggest concern....
> There are quite a few customers who build really large pages, often
> encouraged by (custom) implementations of our UI Shell Dynamic Tab template.
> With this design, you easily have a number of independent tabs open, each
> tab holding an af:region with taskflow with page fragments.
> Many ADF developers don't seem to realize that all those tabs are still
> one page with one UITree.
> And even the simplest partial submit, which refreshes only one or two
> items within a tab, still causes the whole UITree to be processed although
> the browser only repaints the two items.
> I have seen a significant impact on performance in apps with many tabs
> open and large page fragments with lots of sub-tabs and accordions.
> Currently, the only (supported) way to improve performance in such a
> scenario is to use the activie property on the taskflow binding and set the
> activation property to conditional (active=false when tab is not selected
> tab). When active property evaluates to false the af:region tag handler
> skips processing of the entire region. But this is troublesome, and means
> all server-side state of these taskflow is lost when switching tabs. (The
> unsupported way is to change the regiontag handler and skip processing when
> region.isRendered evalutes to false)
> *Partial state saving
> To reduce the overhead of state saving and management, JSF 2.0 introduces
> partial state saving
> as new functionality. In an effort to provide continued backwards
> compatibility, ADF Faces will
> utilize its existing state saving implementation while the new JSF 2.0
> implementation matures.
> *
> This statement concerns me a bit. Can you explain what this means?
> I read in your blog about JSF 2.0<http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/>
> that Adam Winer created a solution for partial state saving on trinidad
> years ago which was used as the basis for PSS in JSF 2.0. This might imply
> that ADF Faces already uses some sort of PSS but that isn't true is it?
> Steven.
> On 06/05/2012 16:34, Andy Schwartz wrote:
> On Fri, May 4, 2012 at 5:05 AM, Chris Muir <chriscm...@gmail.com> <chriscm...@gmail.com> wrote:
> Not all ADF EMG members will be familiar with what the main goals of
> JSF 2.2 are. Could you summarize and give an idea of what areas you
> have a particular interest in please Andy?
> Sure. Although JSF 2.0 did a great job of tackling many of the
> highest visibility spec limitations/issues, it was simply not possible
> to address all requirements in one release. JSF 2.1 ended up being a
> fairly minor spec rev, in part because this work was done via the
> JCP's maintenance release process rather than as a formal JSR. JSF
> 2.2 (jsr-344) is our first post-2.0 to opportunity to really advance
> the specification again.
> Rather than summarize the 2.2 work, I'll instead recommend reading
> this wonderful (and regularly updated) summary written by Arjan Tijms:
> http://jdevelopment.nl/jsf-22/#730
> Beat me to it! ;-)
> As for my particular areas of interest, well… to be honest my biggest
> interest, which goes beyond anyone particular feature, is performance.
> As you've probably seen, we build some fairly complex JSF-based
> apps/UIs here at Oracle. We also focus a significant amount of energy
> on devising optimizations to allow our complex apps to perform/scale.
> One of my most important goals for any rev of the JSF spec is to (try
> to) ensure that we do not unintentionally introduce any new sources of
> overhead that might regress performance/scalability.
> As for specific features, aside from Faces Flows, two other features
> that I find particularly interesting (and, sadly, have not yet had
> time to review thoroughly), are window id support (which Trinidad/ADFv
> already provides) and view actions.
> In turn what is an interesting question is the fact for many years ADF
> was ahead of the game for JSF, but recently in parts JSF has caught up
> and implemented some common features. For example the AJAX support
> added in JSF 2.0. This does seem to create an issue for Oracle
> because where it was ahead of the game, it's now kind of off on it's
> own game in some parts of the Oracle JSF solution, or indeed there's
> two solutions - the Oracle one and the JSF one. Given that you're
> part of the expert group designing the upcoming JSF specs, how do you
> balance the need for stability for Oracle vs the need for improvements
> for the wider JSF community?
> Great question!
> Fortunately, for the most part these two goals (stability for existing
> apps + enhancements that advance the platform) have not been mutually
> exclusive. Most of the new APIs that were introduced in JSF 2.0
> complement existing APIs, thus allowing (relatively) smooth upgrades.
> There are some subtleties here (eg. new tree visiting requirements),
> though these tend to impact component and framework developers more so
> than application developers. (Upgrading Trinidad/ADF to JSF2 was not
> trivial. However, upgrading Trinidad/ADF-based applications to JSF2
> should be.)
> As an expert group member, my top priority is to help produce the best
> possible result for all JSF users. I am always happy to see folks
> having positive application development experiences with JSF,
> regardless of what component set they happen to be using. SImilarly,
> I am always interested in what sorts of difficulties our users are
> struggling with, regardless of their choice of component set.
> As a representative of Oracle/ADF, I of course have an interest in
> seeing new APIs evolve in a way that is compatible with our existing
> ADF feature set. However, this does not simply mean pushing for
> unchallenged standardization of our Trinidad/ADF APIs. The expert
> group is made up of some extremely talented developers who bring their
> own experiences and viewpoints to the table. I always welcome
> engagement from my fellow EG members (and community members) even if
> this means having to rethink existing designs.
> As you point out, this does mean that we end up with overlap between
> JSF and ADF features. The best outcome is when our overlapping
> features can work together in an integrated fashion (eg. <f:ajax> and
> partialTriggers). In some cases it is simply tough to avoid having
> parallel features (eg. JSF2 composite components vs. ADF declarative
> components). For such cases, we'll continue to support our existing
> APIs (which is critical for our own apps) while looking for ways to
> ease migration from old to new.
> --
> 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-methodology+unsubscribe@googlegroups.com
Just wanted to let you all know that I've got some high priority day job
work that I need to take a look at now: an escalated bug, perhaps belonging
to someone here. ;-)
Again, apologies for the lag in response time. Hopefully folks aren't
finding this too frustrating. I appreciate all of the excellent questions
that have come in and I am looking forward to responding to all of them!
