IAmA Long-Time Developer of Oracle's UI Technology

[Andy]

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

[Chris Muir]

Hi Andy

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.

> --
> 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
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Michael Koniotiakis]

Hello and welcome Andy.

+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.
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

[Jan Vervecken]

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".

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

[Andy Schwartz]

On Wed, May 2, 2012 at 8:32 PM, Chris Muir <chris...@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.

Andy

[1] http://weblogs.java.net/blog/edburns/archive/2009/03/response_to_a_c.html
[2] http://jcp.org/en/jsr/detail?id=348
[3] http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive
[4] http://java.net/projects/javaserverfaces-spec-public/lists

>
> CM.

[Andy Schwartz]

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?

Andy

[Andy Schwartz]

Hi Jan -

On Thu, May 3, 2012 at 9:46 AM, Jan Vervecken <ver...@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:

http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/513078.pdf

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).

Andy

[Jan Vervecken]

Thanks for your reply Andy.

> 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:
> Hi Jan -
>

> 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:
>

> http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/51...

[Chad Thompson]

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?)

Thanks,

Chad

-- 
Chad Thompson 
chad_t...@mac.com

[missgeburt]

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.

Regards, Todor

--

[Chad Thompson]

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.)

- Chad

-- 
Chad Thompson 
chad_t...@mac.com

[Amr Gawish]

Hello Andy,

First welcome to ADF EMG.

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?

Best Regards,

Amr Gawish
Senior Oracle Middleware Consultant
    

-- 
Chad Thompson 
chad_t...@mac.com

--

[Chris Muir]

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.

[Michael Koniotiakis]

Thank you very much for your feedback Andy.

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.

Thanks again for your time
MK

[John Flack]

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.

[Andy Schwartz]

Gang -

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!

Andy

[Andy Schwartz]

On Thu, May 3, 2012 at 3:12 PM, Chad Thompson <chad_t...@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.

Some relevant links...

Spec issue:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-730

A summary of the proposal can be found here:

http://javaserverfaces-spec-public.java.net/nonav/proposals/JAVASERVERFACES_SPEC_PUBLIC-730/proposal.txt

And if you want to really get your hands dirty, check out Ed's recent
communication on the status of the prototype and doc:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-05/message/0

As always, feedback and questions are welcome.

> 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:

http://sfjsf.blogspot.com/2006_02_01_archive.html

We'll continue to push for standardization of functionality that meets
these criteria.

> (I also recall some rumblings about an "ADF Community Edition" sometime back
> - is that possibly related?)

This is a topic that other folks on the thread (eg. ADF product
managers) might be able to cover better than I can. Any takers?

Andy

[Jan Vervecken]

hi Michael Koniotiakis

- 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

[Andy Schwartz]

On Thu, May 3, 2012 at 7:13 PM, missgeburt <missg...@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:

http://www.rollingstone.com/music/news/beastie-boys-co-founder-adam-yauch-dead-at-48-20120504

And this comment:

:-(

Andy

[Andy Schwartz]

On Thu, May 3, 2012 at 10:33 PM, Amr Gawish <amr.g...@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:

http://venturebeat.com/2012/05/02/linkedin-ipad-app-engineering/

(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

[Simon Lessard]

Hi Andy,

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

--
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

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--
Simon Lessard, ADF Architect

CMA SYSTeMS

( +33(0) 6 79 37 39 85 (France)

( +1.418.930.0279 (Canada)

[Andy Schwartz]

On Fri, May 4, 2012 at 5:05 AM, Chris Muir <chris...@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.

Andy

[Steven Davelaar]

Hi Andy,

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)

Which brings me to my question: In this JSF 2.0 and ADF Roadmap white paper we can read the following about partial state saving:

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� 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 <chris...@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?

--

Steven Davelaar| Consulting Solutions Architect Oracle Webcenter | FMW Architecture Team (A-Team) Tel +31 30 669 8113 | Mobile +31 6 55 33 24 28 Twitter: @stevendavelaar

A-Team ADF/Webcenter Blog | JHeadstart

NEED A-TEAM SUPPORT? File your request here!

[Simon Lessard]

Hi Steven,

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  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....@oracle.com> wrote:

Hi Andy,

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)

Which brings me to my question: In this JSF 2.0 and ADF Roadmap white paper we can read the following about partial state saving:

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  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 <chris...@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?

--

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
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Andy Schwartz]

Gang -

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!

Andy

[Steven]

Simon,

Activation=deferred is the default but does not help, the TF is activated once a new dynamic tab is opened. If you then Switch to another tab, the TF should not be processed during state saving, but it is, unless you set activation=conditional and active to boolean property that reflects tabs selected state.

But my point it that it is too complex, JSF / ADF faces should do a better job in state saving OOTB. In my tests, the state for not rendered tab TF's  is still processed, degrading performance significantly.

Regards,

Steven

[missgeburt]

I have another question, this time regarding WebCenter.

As WC/WC Spaces is a crafty ADF application with special functionalities added, who is responsible for its development - Is this your gang Andy?

Plus, there are interesting components in WC like panelCustomizable, which are not part of ADF Faces, although in my opinion they should. For those that are not acquainted, when panelCustomizable is on a page, one can add taskflows/portlets inside of it runtime.

Do you think, that at a certain point, such functionalities will become part of ADF rather than stay in WC? And is there any specific reason, except political one, that might stop this event?

Regards, T.Gigilev!

[Andy Schwartz]

Hi Michael -

On Fri, May 4, 2012 at 5:56 AM, Michael Koniotiakis <mko...@hotmail.com> wrote:
> Thank you very much for your feedback Andy.

You bet. Thanks for sharing your ADF experiences with me!

> On May 3, 8:01 pm, Andy Schwartz <andy.g.schwa...@gmail.com> wrote:
>> 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.

We see this as well. Though IE8 > IE7, and IE9 seems to finally be
catching up. Are you also seeing performance improvements with the
"newer" versions of IE? Does your user base typically run one
particular version of IE?

> Also java scripts and css changes does not behave the same in
> different browsers.

Just to be sure I understand… by "changes" - are you referring to
custom/app-specific JavaScript/css?

> 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)

Ah, interesting. I hadn't thought about how some of these subtle
browser differences can bleed through. If you've seen other cases
like this that you find particularly irksome, please let me know.

>> 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

Does the "accessKey" attribute not do what you are looking for here?

> --> Shortcut keys on main page not to be functional when a popup is
> open.
> etc...

Wow, thanks for this thorough list - very interesting to see these requirements.

> 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.

Yep, I agree that this sort of functionality is going to be very
difficult to implement at the app level. I will definitely pass this
feedback along to our team.

One small question that I am curious about… some of the data entry
optimizations (eg. removing items from the tab traversal) might cause
issues for keyboard-only users. Is that a concern for you?

Are other folks on this thread facing similar problems - ie. is the
data entry use case relatively common, perhaps for folks who are
upgrading from Oracle Forms?

Andy

[Stephen Johnson]

We have 2 apps running on ADF 11.1.1.4 (live since beginning of November),
browser-wise we've generally found the following (out of the versions we and
our users have tried):
Chrome 18 > Firefox 11 > Firefox 7 > Firefox 3.6 > IE 9 > IE 8 > IE 7

So newer versions are usually better regardless of the browser, and anything
is generally better than IE regardless of the version. And the difference
between current versions of Chrome and FF is less than the difference
between those and IE.

In addition to the sizable text boxes, there are instances where IE prevents
users from copying text (primarily in tables), that was very frustrating to
our users and most have switched to FF or Chrome.

We had the unfortunate issue for a while of having a significant portion of
our user base that still used a legacy Siebel application that ran inside a
Java plugin that was only compatible with IE7. Gratefully, they're finally
moving off of that.

> --> Focus to be inside query criteria when query page opens When a
> --> value is selected in an input list of values field the

[Andy Schwartz]

Hi Simon -

On Sat, May 5, 2012 at 5:57 AM, Simon Lessard <simon.l...@gmail.com> wrote:
> Hi Andy,
>
> 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.

Hah! No worries. :-)

I of course recognize you from the MyFaces and the OTN forums.
(Thanks for answering so many ADF questions!) And also… weren't you
active on the JSF expert group, perhaps before I joined?

> 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).

Ah, yep. This is a popular issue. See:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-776

9 votes - quite a lot for a spec issue. This was one of my top 5
votes during JSF 2.2 issue voting, though I don't think it made the
cut.

> 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?

As you mentioned, JSF 2.0 has begun a trend to escape from the old JSF
1.x world of "everything is a POST". I suspect that JSF will continue
down this path: JSF 2.2's view actions are another good step in this
direction.

Although it doesn't look like issue 776 (get support for h:form) is in
for JSF 2.2, I'll ping the EG to raise awareness of this issue.

> 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.

Not perfect?!? Er… yeah, okay. I'll buy that.

> I have my own personal shame about the tr:train which use nested

Don't get me started about my old code!

> 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.

I think (well, hope) that we are all getting wiser over time, at least
when it comes to HTML/DOM. :-)

While we do try to favor simpler HTML for our newer component
additions, at times we run into conflicts between feature requirements
vs. DOM complexity - ie. we have cases where simplified feature
requirements would facilitate simpler DOM structures. In many cases,
the feature requirements win out. (I am thinking of features like
toolbar/menubar "overflow" handling, which lead to significantly more
complex DOM than you might see in other toolbar/menubar
implementations.)

> Also I'd like to know what kind
> of validation the generated HTML for a component goes through before being
> released.

We review component HTML/DOM and skinning keys as part of our
code/design review process. However, given your comments here along
with the earlier ADF EMG discussion on skinning pain, I am thinking
that it would be worthwhile for our team to review our review process
to ensure that HTML/DOM/skinning complexity is receiving sufficient
attention.

> 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.

Right. We try to expose selectors that target key points in the DOM
subtree. We know that our DOM is likely to change over time. By
asking skinners to code against our supported selectors, we have some
hope of not randomly breaking custom skins with every DOM-related bug
fix.

> 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.

I agree that there are certain types of DOM simplifications/overhauls
that our existing selector API won't be able to tolerate. However, I
still think that there is benefit to this abstraction, if only to
reduce brittleness for the smaller (eg. bug fix) DOM changes.

> 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?

Totally not out of your mind. These are exactly the issues that we
are evaluating now. HTML5/CSS3 presents us with the opportunity to
simplify our DOM, though as you point out, such simplifications may
impact assumptions built into our current skin selector APIs. Given
our backwards compatibility requirements, we likely won't be removing
any supported selectors from existing skins. However, we'll certainly
be looking for ways that we can simplify our HTML/DOM/CSS for any
(theoretical) future skins.

> 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.

Hrm. I do like the state style class approach, though I still think
that we're going to need selectors for targeting subelements.
Currently we leverage pseudo-classes for state-specific styles, eg:

af|button:disabled

With the idea that this would be a familiar pattern for CSS users. Do
you feel that this approach makes life difficult for designers?

> 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.

For me this is perhaps the most interesting aspect of this skinning
discussion. We like to think of our documented skin selectors as
being the source of truth for folks who are building custom skins.
But clearly the process of building a custom skin doesn't always work
out quite how we imagine it would - ie. sounds like designers are just
as likely to start with our generated style classes and work backwards
to the skin APIs. Seems like these different views of how we approach
skinning are at the heart of at least some of the
frustrations/difficulties that folks are having.

> 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.

I am so worried about DOM brittleness. Are you thinking that this
would require the rendered DOM structures to be specified as part of
our skinning APIs? Or just that folks who are building custom skins
would be tolerant of DOM changes that potentially break their skins?

> 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.

I haven't looked too closely at the other *Faces client-side APIs, but
I do think that our client-side component framework is one of the
things that makes ADF Faces special. It's obviously plays a huge role
in our own component development efforts.

> 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.

Fair observation.

> 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?

We definitely steer our users towards composite/declarative components
first. The Developer's Guide provides some documentation for custom
component developers, but, yeah, there is not a lot of tooling
support. Not sure whether there are plans to improve this, though I
will pass along this feedback to our team.

> 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.

Yep. Did you end up implementing this as a composite or as a
custom/rich component?

> 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.

I've been wondering about this as well.

> 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?

I haven't had a chance to review Ed's prototype + documentation just
yet, but will do so soon and will keep this in mind. I'll also follow
up with our ADFc folks to see whether they have any thoughts on this.

Seems like defining a Java API for custom activities should be fairly
straightforward. The slightly tricky part is going to be integrating
this with faces-config.xml and DT environments.

> 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?

We debated this point when upgrading ADF to JSF 2. In the end we
decided that preemptively invoking method call activities was simply
not an option. We ended up deciding that preemptive navigation should
only be supported in the case where you are navigating directly to a
view activity.

We'll definitely need to review this question in the context of the
JSF 2.2 spec. If you've got thoughts on this topic I would love to
hear them!

Thanks for all of the great questions and for sharing your JSF/ADF
issues. Pretty sure I am learning more from this thread than you all
are. :-)

Andy

[Simon Lessard]

Hi Andy,

And also… weren't you active on the JSF expert group, perhaps before I joined? 

Yeah, I represented Fujitsu Limited on JSR-314 but I was not as active as I wished. As the release date draw near, the decision was made to use conference calls instead of mainly mailing list, which was the right idea to get things done, but unpractical for me since Fujitsu, although supporting my effort, wasn't actually freeing any time for it so I was to participate out of my paid (and business) hours, meaning conf calls were out of question. Anyway, I could still get some little things in.

Hrm.  I do like the state style class approach, though I still think that we're going to need selectors for targeting subelements. Currently we leverage pseudo-classes for state-specific styles, eg:

 af|button:disabled

With the idea that this would be a familiar pattern for CSS users.  Do you feel that this approach makes life difficult for designers? 

Oh the state styleClass is totally good and I would definitely not get rid of it, I think I was not clear on that point. Let say you have a component, for example af:train which also have a stop subelement. I totally see the purpose of having something like:

af|train::stop:visited

What I meant is more to get rid of those like:

af|commandMenuItem::bar-item-text

af|menu::menu-item-antonym-text-selected

And I would not be disgusted of using the following for example:

af|commandMenuItem span 

I think it would be easier for the web designer to work with that since they're used to that type of CSS. Furthermore, I think I'd create a new base skin without any alias, -tr-rule-ref and color scheme. So a truly minimal skin with only mandatory layout property so that a popup looks like a popup. Web designers dislike to have to inhibit and I have yet to see one use the pre-defined aliases, although they do like to define their own, so that'S not a bad feature per se.

I am so worried about DOM brittleness.  Are you thinking that this would require the rendered DOM structures to be specified as part of our skinning APIs?  Or just that folks who are building custom skins would be tolerant of DOM changes that potentially break their skins? 

That's indeed the heart of the matter. I don't think the generated DOM would have to be part of the API, I just think they would be more tolerant to seeing some DOM element changes over time than having to struggle with the CSS like they are now. DOM changes are quite rare anyway, even with the current skinning approach that theoretically allow it. That's from my experience though and a more thorough survey of other customers' experience and assumptions toward migrations. Another thing that would help them and is felt more in RC than Trinidad is the inline styles added by the framework, padding in the table header come to my mind. It's not pervasive in the sense that it's not all (not even most) component that do it, but some of my projects had to use !important in their skin to circumvent that and when that happened the web designer wanted to gouge my eyes as I told them that it was the only way. For example we had:

.LierForums_Arbre > af|tree,

.LierForums_Arbre > af|tree > af|table::data-body

{

        height:               250px !important;

        width:                auto !important;

        overflow-x:           visible;

}

/* ena-2397 */

.LierForums_Arbre > af|tree > div:last-child

{

        width:          30px !important;

        z-index:        5 !important;

        overflow-x:     hidden !important;

        outline:        none;

}

And this is probably the worst we ever had to do, but it shows that sometimes the selectors are not enough (speaking of which I think there's a little bug in the skin parser not allowing "none" for url based properties):

/* ..... Messages generaux ..... */

af|messages::intro + table > tbody > tr > td > table > tbody > tr > td

{

        background-image:     url(images/commun/fonds/messages/bck_messages_separationNiv2.gif);

        background-repeat:    no-repeat;

        background-position:  center top;

        padding:              19px 0px 7px 0px;

}

af|messages::intro + table > tbody > tr > td > table > tbody > tr:first-child > td

{

        background-image:     none;

        padding:              7px 0px 7px 0px;

}

af|messages::intro + table > tbody > tr > td > table > tbody > tr > td:first-child,

af|messages::intro + table > tbody > tr > td > table > tbody > tr:first-child > td:first-child

{

        background-image:     none;

        padding:              0px;

}

Yep.  Did you end up implementing this as a composite or as a custom/rich component?

Custom. I favor custom over composite for 3 reasons most of the times:

1. Performance
2. DOM control reasons
3. Packaging as a simple JAR is much easier using Maven than an ADF lib (even if we made a plugin for that as well). I'm not even sure if it's still the only way to package a composite component though as I have not used them in a while. Defining the component in the project itself is also not an option since we have many ADF projects here and we have to share common components and features.

Seems like defining a Java API for custom activities should be fairly straightforward.  The slightly tricky part is going to be integrating this with faces-config.xml and DT environments.

faces-config.xml is, well, an xml file, so I would not be disgusted to have to declare a namespace to integrate custom activities.

We'll definitely need to review this question in the context of the JSF 2.2 spec. If you've got thoughts on this topic I would love to hear them!

I think that calling the method preemptively is indeed out of question. Simply imagining a menu with each item requiring a method call would be both ridiculous and confusing for developer, not to mention dangerous depending on the method call's content. So the other two options left is to exclude support, or create synthetic URL that get recognized by the ViewHandler and/or NavigationHandler when invoked that in turn call a method activity. I think most of the complexity would lie in ViewHandler.restoreView since it would have to resolve the method call and potentially a navigation (method call with multiple outcomes) before actually restoring (creating) the view. I don't see the latter as impossible though and it's certainly the most flexible and richest approach. Basically it would have to be generalized for any type of activity. In a sense it's like if any state in the flow is a resource, so it has its own URL. Another solution would be to alter the Lifecycle slightly so that the restore view phase does not necessarily call viewHandler.restoreView first, but rather have a general ActivityHandler from which ViewHandler would extends. I see many options here, but all of them would imply having every root activity have their own URL. I guess I miss the labs and framework design, because that's the kind of challenge I love.

Thanks for all of the great questions and for sharing your JSF/ADF issues.  Pretty sure I am learning more from this thread than you all are. :-)

Thank for taking the time for answering them.

Regards,

~ Simon

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-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Simon Lessard]

Hi Steven,

Activation=deferred is the default 

Not exactly true, Activation="Deferred" started being automatically added when dragging a task flow with 11.1.1.1.2 I think, before that it was just not specified, which was immediate (and was causing a lot of issues). This was a long shot, but if the application was old, it would have been possible that you were still in the very old mode and would have had a gain with the new one.

If you then Switch to another tab, the TF should not be processed during state saving 

How do you debug state saving? Code breakpoint? Anyway, you won't be able to prevent state saving from being called, this is not an ADF issue, but a JSF one (and not really an issue):  http://docs.oracle.com/javaee/5/api/javax/faces/component/UIComponent.html#processSaveState(javax.faces.context.FacesContext). As you see, this is almost the only process* method not evaluating the rendered property of the component. However it's evaluating the transient one which could be an option for you. Another would be to prune the component tree when switching tabs, or simply use a single dynamic region instead of many.

Regards,

~ Simon

[Steven]

Simon,

Yes, through breakpoints.

Dynamic region does not work, each tab represents a user task with its own transaction, we do not want to loose the TF state of non-selected tabs.

But the point is not to find some advanced  custom way to optimize state saving. I would like to see ADF Faces do a better job OOTB in this scenario. 

Regards,

Steven

[Andy Schwartz]

Hi Steven -

Sorry for taking so long to jump in on this...

On Wed, May 9, 2012 at 5:44 AM, Steven <steven....@oracle.com> wrote:
>
> Simon,
>
> Yes, through breakpoints.
> Dynamic region does not work, each tab represents a user task with its own
> transaction, we do not want to loose the TF state of non-selected tabs.
>
> But the point is not to find some advanced  custom way to optimize state
> saving. I would like to see ADF Faces do a better job OOTB in this
> scenario.

I agree that we have work to do to optimize the "large component tree"
case. This is definitely a focus of our team.

We do have one tab-related optimization that might be of particular
interest to you: the af:panelTabbed "childCreation" attribute. See
tag doc here:

http://jdevadf.oracle.com/adf-richclient-demo/docs/tagdoc/af_panelTabbed.html

When childCreation is set to lazy/lazyUncached, we attempt to avoid
tag execution/component subtree creation for non-disclosed tabs. I
say "attempt" because this is tricky business, and it is not always
possible to optimize this work away.

The tag doc is missing one important detail: the af:panelTabbed
childCreation attribute is only supported on JSP, not Facelets (for
now anyway). And one more subtle detail: the presence of EL bindings
for various af:showDetailItem lifecycle-influencing attributes (eg.
rendered, disclosed) can impact our ability to perform this
optimization.

af:popup provides a similar attribute. We are considering expanding
this to include other disclosure components (eg. af:panelAccordion,
af:showDetail). It might be interesting to see whether this type of
optimization would be viable for some of the large component tree
cases that you have encountered.

BTW, I notice that you are interested in state saving. Are you
focused on this area due to concerns about per-user/session memory
overhead? Or because you are seeing state saving as particularly
impacting response times?

For typical postback/ppr requests, response time overhead comes from a
variety of places, eg:

- Time spent restoring the component tree (though no overhead here if
view root caching is used)
- Time spent in the execute phases of the lifecycle
- Time spent re-executing tags
- Time spent rendering
- Time spent state saving

While state saving is clearly significant, I wouldn't expect it to
necessarily be the biggest time sink.

Earlier you mentioned:

> 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.

You are right: we do more processing than necessary for this case.
Our plan is to leverage JSF2's tree visiting to optimize this,
allowing us to avoid traversing uninteresting portions of the
component tree.

Regarding your earlier questions on partial state saving:

> Which brings me to my question: In this JSF 2.0 and ADF Roadmap white
> paper we can read the following about partial state saving:
>
> 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?

Sure. JSF2 partial state saving works great for simple
applications/components but can be problematic for more complex cases
- eg. for components that dynamically create/add/move/remove other
components during the JSF lifecycle (outside of tag execution). As
authors of a variety of such complex components, we have found that we
have more work to do to ensure that these components work well with
partial state saving. (For example, it's important to properly mark
"temporary" component subtrees as transient in order to ensure that
the JSF implementations won't track these dynamic changes for state
saving purposes.) We have also found issues with the Mojarra (the
JSF reference implementation) when dealing with such complex cases.
We are working closely with the Mojarra team to resolve these issues.

Our goal is to provide robust support for JSF2 partial state saving
across all of our components. We aren't quite there yet but are
working ever closer towards this goal.

> I read in your blog about JSF 2.0  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?

Unfortunately, no… Trinidad does provide a "delta" state saving
solution that was the inspiration for JSF2 partial state saving, but
this suffers from similar problems.

Andy

[Simon Lessard]

> I read in your blog about JSF 2.0  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?

Unfortunately, no…  Trinidad does provide a "delta" state saving
solution that was the inspiration for JSF2 partial state saving, but
this suffers from similar problems. 

Oh! Didn't know that! I thought ADF was using Trinidad's delta saving.

~ Simon

--
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

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Andy Schwartz]

Hi Todor -

On Mon, May 7, 2012 at 4:34 PM, missgeburt <missg...@gmail.com> wrote:
>
> I have another question, this time regarding WebCenter.
>
> As WC/WC Spaces is a crafty ADF application with special functionalities
> added, who is responsible for its development - Is this your gang Andy?

Spaces is developed by the WebCenter team, so, different gang, though
one of our key clients.

> Plus, there are interesting components in WC like panelCustomizable, which
> are not part of ADF Faces, although in my opinion they should. For those
> that are not acquainted, when panelCustomizable is on a page, one can add
> taskflows/portlets inside of it runtime.
>
> Do you think, that at a certain point, such functionalities will become
> part of ADF rather than stay in WC? And is there any specific reason, except
> political one, that might stop this event?

Interesting. I haven't been in on any discussion of this area. The
ADF Faces portion of ADF tends to stick to lower-level UI building
blocks. So for example, we provide components that allow you to build
similar layouts (thinking about af:panelDashboard and af:panelBox),
but we don't provide the higher-level infrastructure that would allow
an end user to add taskflows/portlets. This seems to require some
knowledge of/access to a repository of these content providers, which
I guess is a bit higher level than our typical ADF Faces component.

Of course we do have some fairly high-level components (eg.
af:calendar), so it can be tough to know where to draw the line.

Possible that someone else here from the ADF team might have thoughts
on this topic?

Andy

[Andy Schwartz]

On Tue, May 8, 2012 at 6:23 AM, Stephen Johnson
<sjoh...@integretasinc.com> wrote:
> We have 2 apps running on ADF 11.1.1.4 (live since beginning of November),
> browser-wise we've generally found the following (out of the versions we and
> our users have tried):
> Chrome 18 > Firefox 11 > Firefox 7 > Firefox 3.6 > IE 9 > IE 8 > IE 7
>
> So newer versions are usually better regardless of the browser, and anything
> is generally better than IE regardless of the version.  And the difference
> between current versions of Chrome and FF is less than the difference
> between those and IE.

Sounds about right, though it does seem that the gap between IE and
the other browsers is shrinking (and hopefully will continue to do
so).

> In addition to the sizable text boxes, there are instances where IE prevents
> users from copying text (primarily in tables), that was very frustrating to
> our users and most have switched to FF or Chrome.

Hrm. Do you suspect that this is a generic IE issue? Or something
that ADF might be triggering (and thus might be able to avoid)?

> We had the unfortunate issue for a while of having a significant portion of
> our user base that still used a legacy Siebel application that ran inside a
> Java plugin that was only compatible with IE7.  Gratefully, they're finally
> moving off of that.

Hooray for that!

Andy

[Andy Schwartz]

On Thu, May 10, 2012 at 3:46 AM, Simon Lessard
<simon.l...@gmail.com> wrote:
>
> Oh! Didn't know that! I thought ADF was using Trinidad's delta saving.

Sorry to be the bearer of bad news. :-/ JSF2 partial state saving is
definitely our best forward at this point.

BTW, this reminds me of a related question that I've been meaning to
ask the EMG:

Have folks here made the transition from JSP to Facelets? For
projects that haven't made this transition, is this something that you
are planning/hoping to do? Any folks here who particularly prefer to
stay on JSP?

One reason I am curious about this: JSF2 partial state saving is only
available in Facelets. I suppose when we do finally complete our
partial state saving work, this could be another compelling reason for
ADF users to make the move from JSP --> Facelets.

Andy


>
>
> ~ Simon

[Chad Thompson]

On Thursday, May 10, 2012 at 9:15 AM, Andy Schwartz wrote:

BTW, this reminds me of a related question that I've been meaning to

ask the EMG:

Have folks here made the transition from JSP to Facelets? For

projects that haven't made this transition, is this something that you

are planning/hoping to do? Any folks here who particularly prefer to

stay on JSP?

For the most part, I'm still using JSPs on a regular basis primarily because the current releases of Fusion Middleware that I spend most of my time with (primarily WebCenter at this point) are to this point still JSP-based.  ("11gR1")

I'll happily make the switch when the time comes, but I'm somewhat stuck at the moment.  :-)

- Chad

[Andy Schwartz]

On Thu, May 10, 2012 at 10:27 AM, Chad Thompson <chad_t...@mac.com> wrote:

> I'll happily make the switch when the time comes, but I'm somewhat stuck at
> the moment.  :-)

Ah, that's right. I guess I should have started by asking whether
folks have made the upgrade to 11gR2/JSF2. :-)

Andy

[fnimphiu]

"> In addition to the sizable text boxes, there are instances where IE
prevents
> users from copying text (primarily in tables), that was very frustrating to
> our users and most have switched to FF or Chrome. "

If my memory serves me well then this is a known issue with IE and has
been fixed in ADF Faces for 12c. Didn't try but could find it on the
feature list.

Frank

[Andy Schwartz]

Hey Simon -

On Wed, May 9, 2012 at 4:24 AM, Simon Lessard <simon.l...@gmail.com> wrote:

> Oh the state styleClass is totally good and I would definitely not get rid
> of it, I think I was not clear on that point. Let say you have a component,
> for example af:train which also have a stop subelement. I totally see the
> purpose of having something like:
>
> af|train::stop:visited
>
> What I meant is more to get rid of those like:
> af|commandMenuItem::bar-item-text
> af|menu::menu-item-antonym-text-selected

Ah, I see. I took a quick look at our skin selector doc. For
af:commandMenuItem, we've got the following text-related selectors:

af|commandMenuItem::bar-item
af|commandMenuItem::bar-item-text
af|commandMenuItem::bar-item-antonym-text-default
af|commandMenuItem::bar-item-antonym-text-selected
af|commandMenuItem::menu-item
af|commandMenuItem::menu-item-text
af|commandMenuItem::menu-item-antonym-text-default
af|commandMenuItem::menu-item-antonym-text-selected

Seems like "bar" vs. :menu" could have been handled via containership.
And, yeah, default/selected sure seem like states to me (ie. not sure
why these aren't using pseudo-classes).

Thanks for calling attention to this. I'll raise this with our dev team.

> And I would not be disgusted of using the following for example:
> af|commandMenuItem span
>
> I think it would be easier for the web designer to work with that since
> they're used to that type of CSS.

Hrm… Although we expose selectors as a way to provide stability, I
suppose there isn't anything preventing web designers from forgoing
these and targeting HTML elements directly - even with our current
skins. Is your concern that this isn't possible to do today? Or more
that you find the added overhead of the style classes annoying?

> Furthermore, I think I'd create a new base
> skin without any alias, -tr-rule-ref and color scheme. So a truly minimal
> skin with only mandatory layout property so that a popup looks like a popup.

We do integrate with Trinidad's "simple" skin. It's not quite as
minimal as what you describe, but perhaps provides a better starting
point for designers who don't want to pick up the colors/styles of our
richer skins.

(Trinidad itself has a "minimal" skin, which might be closer to what
you want, though this is not usable with ADF Faces.)

> Web designers dislike to have to inhibit and I have yet to see one use the
> pre-defined aliases, although they do like to define their own, so that'S
> not a bad feature per se.

Right. This same sort of feature shows up in other CSS frameworks
(eg. similar to LESS and Sass support for "variables"). We find it
tremendously useful for building our own skins. If designers aren't
finding our pre-defined aliases useful, it's possible that we haven't
done a good enough job at designing these aliases.

> That's indeed the heart of the matter. I don't think the generated DOM would
> have to be part of the API, I just think they would be more tolerant to
> seeing some DOM element changes over time than having to struggle with the
> CSS like they are now.

I guess I am still not sure what would prevent a designer from
targeting our DOM now. Wondering whether there might be some subtle
issues with our skinning framework that is making this difficult. Or
is it just the complexity of our DOM? (Not that I am encouraging this
approach. Just curious whether there are technical limitations here
that I might be missing.)

> DOM changes are quite rare anyway, even with the
> current skinning approach that theoretically allow it. That's from my
> experience though and a more thorough survey of other customers' experience
> and assumptions toward migrations. Another thing that would help them and is
> felt more in RC than Trinidad is the inline styles added by the framework,
> padding in the table header come to my mind. It's not pervasive in the sense
> that it's not all (not even most) component that do it, but some of my
> projects had to use !important in their skin to circumvent that and when
> that happened the web designer wanted to gouge my eyes as I told them that
> it was the only way.

Hah! Or, yikes!

> For example we had:
>
> .LierForums_Arbre > af|tree,
> .LierForums_Arbre > af|tree > af|table::data-body
> {
>         height:               250px !important;
>         width:                auto !important;
>         overflow-x:           visible;
> }
>
> /* ena-2397 */
> .LierForums_Arbre > af|tree > div:last-child
> {
>         width:          30px !important;
>         z-index:        5 !important;
>         overflow-x:     hidden !important;
>         outline:        none;
> }
>
> And this is probably the worst we ever had to do, but it shows that
> sometimes the selectors are not enough

Got it. Thanks for calling this out. I agree that we need to favor
skinnable selectors over inline styles. (Another item I'll take back
to our team.)

> (speaking of which I think there's a
> little bug in the skin parser not allowing "none" for url based properties):

Oh, yep, that should be supported. Have you already logged a Trinidad
issue? (If not, I'll follow up.)

>> Yep.  Did you end up implementing this as a composite or as a custom/rich
>> component?
> Custom. I favor custom over composite for 3 reasons most of the times:
>
> Performance
> DOM control reasons
> Packaging as a simple JAR is much easier using Maven than an ADF lib (even
> if we made a plugin for that as well). I'm not even sure if it's still the
> only way to package a composite component though as I have not used them in
> a while. Defining the component in the project itself is also not an option
> since we have many ADF projects here and we have to share common components
> and features.

Hrm. ADF declarative components are intended to address exactly this
use case (sharing components across projects/teams) but if folks are
avoiding them because they are difficult to share/reuse, sounds like
we've got a usability problem.

>> Seems like defining a Java API for custom activities should be
>> fairly straightforward.  The slightly tricky part is going to be
>> integrating this with faces-config.xml and DT environments.
> faces-config.xml is, well, an xml file, so I would not be disgusted to have
> to declare a namespace to integrate custom activities.

Oh, yep. We would definitely want custom activities to be accessed
via custom namespaces. Although you can dump any XML content in
faces-config.xml extension elements, this would be the first time that
JSF itself would need to consume custom faces-config.xml content.
Not an especially hard problem. Just some more/new grunge.

DT/tooling integration is trickier, particularly if we wanted to
support integration of custom activities into a visual flow editing
environment.

>> We'll definitely need to review this question in the context of the JSF 2.2
>> spec. If you've got thoughts on this topic I would love to hear them!
> I think that calling the method preemptively is indeed out of question.
> Simply imagining a menu with each item requiring a method call would be both
> ridiculous and confusing for developer, not to mention dangerous depending
> on the method call's content.

Exactly.

> So the other two options left is to exclude
> support, or create synthetic URL that get recognized by the ViewHandler
> and/or NavigationHandler when invoked that in turn call a method activity. I
> think most of the complexity would lie in ViewHandler.restoreView since it
> would have to resolve the method call and potentially a navigation (method
> call with multiple outcomes) before actually restoring (creating) the view.
> I don't see the latter as impossible though and it's certainly the most
> flexible and richest approach. Basically it would have to be generalized for
> any type of activity. In a sense it's like if any state in the flow is a
> resource, so it has its own URL. Another solution would be to alter the
> Lifecycle slightly so that the restore view phase does not necessarily call
> viewHandler.restoreView first, but rather have a general ActivityHandler
> from which ViewHandler would extends. I see many options here, but all of
> them would imply having every root activity have their own URL.

Interesting idea!

One concern that I have is that for bookmarkability (and crawlability,
cacheability) purposes, ideally each URL should map to a single view.
So, for example, I should be able to bookmark an URL produced by
preemptive navigation or send it to a friend and always see the same
result. However, method call or router activities can trigger
navigation to an arbitrary # of different views based on the current
context. We could produce URLs that point back to an activity on a
subsequent request, but I worry that these URLs don't actually have a
stable relationship to any particular view.

A related issue is that method call and router activities might rely
on context/state that is not available on subsequent requests (eg. on
request scope state), which could make delaying evaluation of these
activities dangerous.

In any case, you've got me thinking about this is a way that I hadn't
previously, which is awesome!

> I guess I
> miss the labs and framework design, because that's the kind of challenge I
> love.

Er… don't suppose we could convince your current employer to give you
time to participate in the JSF 2.2 expert group? :-)

Andy

[Chris Muir]

"Hrm.  Do you suspect that this is a generic IE issue?  Or something
that ADF might be triggering (and thus might be able to avoid)?"

This probably relates to the af:table component, I blogged about it
when I was external to Oracle:
http://one-size-doesnt-fit-all.blogspot.com/2011/04/aftable-restoring-basic-browser-copy.html

I logged bug 9830307 and it was returned as-not-a-bug but in fact
desired functionality that copy wasn't supported (huh?). From the
history of the bug I can see it was discussed internally significantly
with the not-a-bug result. IMHO the conclusion is wrong, the table
should support copy regardless, I think they've forgotten the user in
considering their answer.

CM.

[Simon Lessard]

Hi Andy,

Hrm…  Although we expose selectors as a way to provide stability, I suppose there isn't anything preventing web designers from forgoing these and targeting HTML elements directly - even with our current skins.  Is your concern that this isn't possible to do today?  Or more that you find the added overhead of the style classes annoying? 

Oh it's very possible, the problem is subtle. What I think is that skin selectors are added to too many element with the obvious goal to allow designer to not have to worry about the generated HTML. Web designers seem to be overwhelmed by it and the overall DOM complexity. Some of those selectors are well chosen and placed, allowing to get a nice control of the look, but some seem simply superfluous and increase the selector count (which can in the end result in busting the IE selector count limit, which justified the CSS file fragmentation). As you just previously mentioned, some selector could have been generalized using a container class instead.

We do integrate with Trinidad's "simple" skin.  It's not quite as minimal as what you describe, but perhaps provides a better starting point for designers who don't want to pick up the colors/styles of our richer skins. 

If I remember correctly, minimal extends simple so has all the predefined aliases already. 

Right.  This same sort of feature shows up in other CSS frameworks (eg. similar to LESS and Sass support for "variables").  We find it tremendously useful for building our own skins.  If designers aren't finding our pre-defined aliases useful, it's possible that we haven't done a good enough job at designing these aliases. 

The worst one is AFDefaultFont and AFDefaultFontFamily I think. From a conceptual point of view they are good, but the problem is that they get referenced by so many selectors in the simple skin that the font-family gets applied to way too many elements, sometime preventing the more use case specific one defined by the designer to be applied. I would need to find an exact example of this, but the general idea is

In simple skin

af|inputText::content {

  -tr-rule-ref("AFDefaultFont:alias");

}

In custom skin extending simple (you're forced to extend something)

.SomeClass {

    font-size:  18px;

}

Now, in the page you have

<af:panelGroupLayout styleClass="SomeClass">

    <af:outputLabel value="Label" for="field"/>

    <af:intputText id="field"/>

</af:panelGroupLayout>

Then the inputText's content will still use AFDefaultFont:alias and not font-size: 18px, forcing designer to instead define:

.SomeClass,

.SomeClass af|inputText::content {

    font-size:  18px;

}

which is bloating the skin. That's the general idea of one of the most frequent complaint I get. Aliases are good, but I don't think the forced base skin should define any, or at least not reference any.

Oh, yep, that should be supported.  Have you already logged a Trinidad issue?  (If not, I'll follow up.)

I don't think I logged any JIRA ticket yet for this (I might even have ninja fixed it already). It's working at runtime, it's just giving a warning (was giving?). 

Another one that really doesn't work though is the following format (format that I hate, but in the specific page that's using it, I failed to use the explicit form with the same result so I had to explicitly reference the .css for now):

font: normal normal 1em/1.2 Arial, Helvetica, FreeSans, sans-serif;

Hrm.  ADF declarative components are intended to address exactly this use case (sharing components across projects/teams) but if folks are avoiding them because they are difficult to share/reuse, sounds like we've got a usability problem.

It still seem to require an ADF Library (http://docs.oracle.com/cd/E18941_01/tutorials/jdtut_11r2_40/jdtut_11r2_40.html). So for those of us using Maven and continuous integration it's not an option out-of-the-box as it requires a custom plugin (or one calling ojdeploy). I forgot how we manage them in 2.0 so I'll have to go back to it and see how they are packaged, this problem might be n/a with 2.0 (we're still using 11.1.1.x).

p.s. I just found this page http://docs.oracle.com/cd/E16162_01/web.1112/e16181/ad_custom.htm by luck, it seems that you've already documented custom component development more than I thought.

DT/tooling integration is trickier, particularly if we wanted to support integration of custom activities into a visual flow editing environment.

Not if custom activities, like custom tags, requires the equivalent of a tld (or facelets tag lib).

One concern that I have is that for bookmarkability (and crawlability, cacheability) purposes, ideally each URL should map to a single view. So, for example, I should be able to bookmark an URL produced by preemptive navigation or send it to a friend and always see the same result.   However, method call or router activities can trigger navigation to an arbitrary # of different views based on the current context.  We could produce URLs that point back to an activity on a subsequent request, but I worry that these URLs don't actually have a stable relationship to any particular view.

A related issue is that method call and router activities might rely on context/state that is not available on subsequent requests (eg. on request scope state), which could make delaying evaluation of these activities dangerous.

Those are 2 very good points. For the first one I wonder if we could have preemptive navigation to method call activity only if those have a single outgoing navigation case. However, if we go that we're, we're going very close to what ADFc does with bookmarkable view activities and their bookmark method. Basically, maybe f:metadata should instead support a f:view-method that would get called after f:view-param activation to ensure that there's a single view per URL. The second one, although relevant, is not as critical as the same can be said with view activities when using redirect or preemptive navigation, it's just something the developer has to be aware of, not a systemic weakness imho.

Have a nice day!

~ Simon

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-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[prateek shaw]

Hi Andy ,

I would like to ask question which is related to  select one choice element .

Here i would like compare select component between Adf and jsf.

<af:selectOneChoice> component of adf and similar component in jsf is <h:selectOneMenu >.

When <af:selectOneChoice>  components render in UI by default it's added blank space as first element of the select one choice.I saw the source code in Mozilla Firefox  it added <option value=""></option> value on the top of the select one choice and on other side in jsf  <h:selectOneMenu > is render with out any blank space .

Please let me know why there is blank space in adf components.


Thanks
Prateek

On Wed, May 2, 2012 at 7:31 PM, Andy <andy.g....@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-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--

Thanks And Venerate
Prateek Kumar Shaw

[Simon Lessard]

Hi  Prateek ,

This is one spot where the ADF component is much better than the original. The blank space represents a null value. Let say you have a POJO with an Integer property amount that is used in a shopping cart to control the amount of an item type you want to buy. In its initial state, the POJO's attribute is null. You then display that field as a dropdown with select items ranging from 1 to 10 (the user has to click on a trashcan button to delete the item from his selection).

The on first display, the h component will display 1, even if it's not one in the pojo itself. Now one can say that it does matter because the value will get submitted when the user submit the form next. However, if you have a <f:ajax/> on the field to update a total price outputText in the same page then you're screwed since you won't get the event that made the selectOneMenu select value 1. The correct way to handle this with the h component is to make sure that the POJO never have a null value.

Now the same example with af will be different. Initial display will be blank so that when the user selects 1, you will get the event and be able to refresh your output component. The having a not null default value in the POJO will also work with the af component, so it's really simply giving you more flexibility. Also note that if the field is required, the blank value won't get rendered anymore once the user choose a value.

Regards,

~ Simon

[prateek shaw]

Thanks Simon for sharing us your valuable information.

What are you saying that is correct .ADF  components are more feature compare to JSF.

As your point of view the blank space is the positive not negative part of the select one choice.

Our requirement is  by default first item will selected .So we can achieve it with different way that is not an issue .

Again thanks for sharing information :)


Thanks
Prateek

[Wilfred van der Deijl]

Should "auto-selecting" the first value when the model value is null in a selectOneChoice really be a responsibility of the UI component itself? If you want to initialize with the first value as a default couldn't you just set an appropriate default in the POJO, ViewObject, or whatever you are using?

[Steven Davelaar]

Andy,

Yes, I am aware of the child creation property, I use that at all the time.
But in the dynamic tabs scenario, all tabs have been visited by the user (a new tab is opened by the user to start a new task), so that doesn't make a difference.
At one internal customer, we modified the RichRegion tag class which by default only checked for model.getViewId==null (which only returns null if the TF binding active property evaluates to false) to check for the rendered property, this caused a significant improvement in performance because all regions in non-selected dynamic tabs were no longer processed.

You are right, it is not so much the state saving part but overall UI component processing in the lifecycle phases that slows down performance. By changing the RegionTag class we were able to cut down significantly on this processing. In addition to childCreation property we would need something like a childDeletion property as well....

I understand from the doc that use of facelets in JDev 11.1.2 generally should increase performance, but how can that be if childCreation property does not work with facelets (yet)?

Steven.

On 10/05/2012 04:25, Andy Schwartz wrote:

Hi Steven -

Sorry for taking so long to jump in on this...

On Wed, May 9, 2012 at 5:44 AM, Steven <steven....@oracle.com> wrote:

Simon,

Yes, through breakpoints.
Dynamic region does not work, each tab represents a user task with its own
transaction, we do not want to loose the TF state of non-selected tabs.

But the point is not to find some advanced �custom way to optimize state
saving. I would like to see ADF Faces do a better job OOTB in this
scenario.

Which brings me to my question: In this JSF 2.0 and ADF Roadmap white
paper we can read the following about partial state saving:

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?

Sure.  JSF2 partial state saving works great for simple
applications/components but can be problematic for more complex cases
- eg. for components that dynamically create/add/move/remove other
components during the JSF lifecycle (outside of tag execution).  As
authors of a variety of such complex components, we have found that we
have more work to do to ensure that these components work well with
partial state saving.  (For example, it's important to properly mark
"temporary" component subtrees as transient in order to ensure that
the JSF implementations won't track these dynamic changes for state
saving purposes.)   We have also found issues with the Mojarra (the
JSF reference implementation) when dealing with such complex cases.
We are working closely with the Mojarra team to resolve these issues.

Our goal is to provide robust support for JSF2 partial state saving
across all of our components.  We aren't quite there yet but are
working ever closer towards this goal.

I read in your blog about JSF 2.0� 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?

Unfortunately, no�  Trinidad does provide a "delta" state saving
solution that was the inspiration for JSF2 partial state saving, but
this suffers from similar problems.

Andy

[Simon Lessard]

Hi Steven,

Can you send me an example of the component structure that you use? I think you may be requesting something out of ADF Faces that is really an application/custom framework specific concern. More specifically, if it's the whole lifecycle you're worrying about and not just state saving, that this could be handled by switching the rendered property on various component. With a simple structure including the tab and the region I'm sure I can come up with something. That being said, checking if the view id of the RegionModel returns null in UIXRegion.processRegion before calling the process does not seem like an horrible idea from a conceptual point a view either.

Regards,

~ Simon

On Mon, May 14, 2012 at 12:04 PM, Steven Davelaar <steven....@oracle.com> wrote:

Andy,

Yes, I am aware of the child creation property, I use that at all the time.
But in the dynamic tabs scenario, all tabs have been visited by the user (a new tab is opened by the user to start a new task), so that doesn't make a difference.
At one internal customer, we modified the RichRegion tag class which by default only checked for model.getViewId==null (which only returns null if the TF binding active property evaluates to false) to check for the rendered property, this caused a significant improvement in performance because all regions in non-selected dynamic tabs were no longer processed.

You are right, it is not so much the state saving part but overall UI component processing in the lifecycle phases that slows down performance. By changing the RegionTag class we were able to cut down significantly on this processing. In addition to childCreation property we would need something like a childDeletion property as well....

I understand from the doc that use of facelets in JDev 11.1.2 generally should increase performance, but how can that be if childCreation property does not work with facelets (yet)?

Steven.

On 10/05/2012 04:25, Andy Schwartz wrote:

Hi Steven -

Sorry for taking so long to jump in on this...

On Wed, May 9, 2012 at 5:44 AM, Steven <steven....@oracle.com> wrote:

Simon,

Yes, through breakpoints.
Dynamic region does not work, each tab represents a user task with its own
transaction, we do not want to loose the TF state of non-selected tabs.

But the point is not to find some advanced  custom way to optimize state
saving. I would like to see ADF Faces do a better job OOTB in this
scenario.

Which brings me to my question: In this JSF 2.0 and ADF Roadmap white
paper we can read the following about partial state saving:

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?

Sure.  JSF2 partial state saving works great for simple
applications/components but can be problematic for more complex cases
- eg. for components that dynamically create/add/move/remove other
components during the JSF lifecycle (outside of tag execution).  As
authors of a variety of such complex components, we have found that we
have more work to do to ensure that these components work well with
partial state saving.  (For example, it's important to properly mark
"temporary" component subtrees as transient in order to ensure that
the JSF implementations won't track these dynamic changes for state
saving purposes.)   We have also found issues with the Mojarra (the
JSF reference implementation) when dealing with such complex cases.
We are working closely with the Mojarra team to resolve these issues.

Our goal is to provide robust support for JSF2 partial state saving
across all of our components.  We aren't quite there yet but are
working ever closer towards this goal.

I read in your blog about JSF 2.0  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?

Unfortunately, no…  Trinidad does provide a "delta" state saving
solution that was the inspiration for JSF2 partial state saving, but
this suffers from similar problems.

Andy

--

Steven Davelaar| Consulting Solutions Architect Oracle Webcenter | FMW Architecture Team (A-Team) Tel +31 30 669 8113 | Mobile +31 6 55 33 24 28 Twitter: @stevendavelaar

A-Team ADF/Webcenter Blog | JHeadstart

NEED A-TEAM SUPPORT? File your request here!

--

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
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[prateek shaw]

Hi Simon ,

One more confuse ,I am not able to justify following statement which you gave in my answer .

Also note that if the field is required, the blank value won't get rendered anymore once the user choose a value.

I try to achieve the same but it's  behave same for  both. If it has required true then when the page load that time one black value rendered on the top of the list(this is accepted behavior ) .After  selecting any value the black value is going .

But if it does not has required true still the behavior is same.


Apart of this question i would like to also ask following question as well

i have written select one choice component of Adf and JSf on same page.like following code


     <af:selectOneChoice value="#{pageFlowScope.backingBean.selectValue}"  >
      <f:selectItems value="#{pageFlowScope.backingBean.programmaticallyLOV}"></f:selectItems>
      </af:selectOneChoice>
     
    <h:selectOneMenu value="#{pageFlowScope.backingBean.selectValue1}" >
     <f:selectItems value="#{pageFlowScope.backingBean.programmaticallyLOV}"></f:selectItems>
 
    </h:selectOneMenu >


And java code of the programmaticallyLOV which is returning the list of select one choice is following

 public List<SelectItem> getProgrammaticallyLOV() {
        if (programmaticallyLOV == null) {
            programmaticallyLOV = new ArrayList<SelectItem>();
            programmaticallyLOV.add(new SelectItem("SUNDAY", "SUNDAY"));
            programmaticallyLOV.add(new SelectItem("MONDAY", "MONDAY"));
            programmaticallyLOV.add(new SelectItem("TUESDAY", "TUESDAY"));
            programmaticallyLOV.add(new SelectItem("WEDNESDAY", "WEDNESDAY"));
            programmaticallyLOV.add(new SelectItem("THURSDAY", "THURSDAY"));
            programmaticallyLOV.add(new SelectItem("FRIDAY", "FRIDAY"));
            programmaticallyLOV.add(new SelectItem("SATURDAY", "SATURDAY"));
           }
        return programmaticallyLOV;
    }

But the rendering of the html code  of af:selectonechoice   and h:selectOneMenu  has no similarity . Although the html code of af:selectonechoice is looking odd.Let me paste the code

html of < af:selectonechoice >

<option value="" _adfTmpOpt="t"></option>
<option value="0">SUNDAY</option>
<option value="1">MONDAY</option>
<option value="2">TUESDAY</option>
<option value="3">WEDNESDAY</option>
<option value="4">THURSDAY</option>
<option value="5">FRIDAY</option>
<option value="6">SATURDAY</option>


and html of the <f:selectOneMenu>

<select name="j_id_id5" size="1">
&#9;<option value="SUNDAY">SUNDAY</option>
&#9;<option value="MONDAY">MONDAY</option>
&#9;<option value="TUESDAY">TUESDAY</option>
&#9;<option value="WEDNESDAY">WEDNESDAY</option>
&#9;<option value="THURSDAY">THURSDAY</option>
&#9;<option value="FRIDAY">FRIDAY</option>
&#9;<option value="SATURDAY">SATURDAY</option>
</select>

Different  point which i observe that are

1-The biggest misleading thing is option value.If you observe value part in af:selectonechoice is index value even in backing bean i am setting same value what label has.
2-After seeing this confuse i put the value change listener over af:selectonechoice then i got the correct value means if i selected SUNDAY then i got SUNDAY .But in html code it is confusing.

Please let me know your view of point over above question

Thanks
Prateek

On Sat, May 12, 2012 at 12:47 AM, Simon Lessard <simon.l...@gmail.com> wrote:

[Simon Lessard]

Hi Prateek,

My statement might no longer hold true from what you're telling me, maybe you need to specify the unselectedLabel to have the the null value choice once the POJO has a value now. I'll have to test it locally. However, I do try to specify the unselectedLabel whenever I have a dropdown that must support a "no-value" option. Note that you can get a no value option in the h:selectOneMenu starting with JSF 2.0 using:

<h:selectOneMenu .../>

    <f:selectItem itemLabel=" " noSelectionOption="true"/>

    <f:selectItems value=""/>

</h:selectOneMenu>

Now with the generated HTML, again ADF Faces is superior imho since using index on the client side allows you to have any type of value as well as have potential duplicated labels (this can be confusing to some users, but can still come in handily). Let take your use case, but let add another day to the list and use a Date object for the value instead of a String. Now maybe you'd want to display 8 days instead of 7 to allow the user to select the next Sunday. With h: you would need to make sure the next Sunday has a different label (like "Next Sunday") for the component to work, else it would select simply the first Sunday even if the user was to choose the second one. Note that this is more of a theoretical issue than a real one since we rarely have the same label twice in a dropdown. With ADF Faces, if the f:selectItems always resolves to the same list (this is how the index gets converted back) then both values will be accessible. Also note that it's possible to pass the String value ot the client as well by specifying valuePassThrough="true" on the af:selectOneChoice.

I hope I was clear even if my example was terrible.

Regards,

~ Simon

[Andy Schwartz]

Hey Chris -

On Fri, May 11, 2012 at 12:26 AM, Chris Muir <chris...@gmail.com> wrote:
> "Hrm.  Do you suspect that this is a generic IE issue?  Or something
> that ADF might be triggering (and thus might be able to avoid)?"
>
> This probably relates to the af:table component, I blogged about it
> when I was external to Oracle:
> http://one-size-doesnt-fit-all.blogspot.com/2011/04/aftable-restoring-basic-browser-copy.html
>
> I logged bug 9830307 and it was returned as-not-a-bug but in fact
> desired functionality that copy wasn't supported (huh?).

Thanks for filling in these details.

> From the history of the bug I can see it was discussed internally significantly
> with the not-a-bug result.  IMHO the conclusion is wrong, the table
> should support copy regardless, I think they've forgotten the user in
> considering their answer.

I find it strange that selection/copy is hosed on IE but works just
fine on non-IE browsers. Seems that we must have hit some IE-specific
oddity that was making this particularly difficult to support.

I plan to do a post-mortem with my teammates: lots of good ideas in
this thread that I want to share. I'll include this issue in my
writeup.

Andy

[Andy Schwartz]

Hey Simon -

On Fri, May 11, 2012 at 4:33 AM, Simon Lessard
<simon.l...@gmail.com> wrote:
> Oh it's very possible, the problem is subtle. What I think is that skin
> selectors are added to too many element with the obvious goal to allow
> designer to not have to worry about the generated HTML. Web designers seem
> to be overwhelmed by it and the overall DOM complexity. Some of those
> selectors are well chosen and placed, allowing to get a nice control of the
> look, but some seem simply superfluous and increase the selector count
> (which can in the end result in busting the IE selector count limit, which
> justified the CSS file fragmentation).

Right. We don't have the option of undoing this for any of our
existing skins, but this is good feedback for any future skins that we
produce. (Though, even there, we've got cross-skin compatibility
concerns.)

> The worst one is AFDefaultFont and AFDefaultFontFamily I think. From a
> conceptual point of view they are good, but the problem is that they get
> referenced by so many selectors in the simple skin that the font-family gets
> applied to way too many elements, sometime preventing the more use case
> specific one defined by the designer to be applied. I would need to find an
> exact example of this, but the general idea is
>
> In simple skin
> af|inputText::content {
>   -tr-rule-ref("AFDefaultFont:alias");
> }
>
> In custom skin extending simple (you're forced to extend something)
> .SomeClass {
>     font-size:  18px;
> }
>
> Now, in the page you have
> <af:panelGroupLayout styleClass="SomeClass">
>     <af:outputLabel value="Label" for="field"/>
>     <af:intputText id="field"/>
> </af:panelGroupLayout>
>
> Then the inputText's content will still use AFDefaultFont:alias and not
> font-size: 18px, forcing designer to instead define:
>
> .SomeClass,
> .SomeClass af|inputText::content {
>     font-size:  18px;
> }
>
> which is bloating the skin. That's the general idea of one of the most
> frequent complaint I get.

Ah, I see. Thanks, that example really helps.

> Aliases are good, but I don't think the forced
> base skin should define any, or at least not reference any.

I would think that defining (mostly) empty aliases and referencing
these should be okay. That way, a custom skin at least has the option
of overriding the alias to specify common properties that should be
shared across selectors.

Actually, one benefit of the global AFDefaultFont/AFDefaultFontFamily
aliases is that you could use these to suppress font styles across a
custom skin in a centralized manner, rather than suppress these styles
for each selector. Have you tried this?

> Another one that really doesn't work though is the following format (format
> that I hate, but in the specific page that's using it, I failed to use the
> explicit form with the same result so I had to explicitly reference the .css
> for now):
> font: normal normal 1em/1.2 Arial, Helvetica, FreeSans, sans-serif;

When you say "doesn't work" - do you remember how this failed?

Andy

[Simon Lessard]

Hi Andy,

I would think that defining (mostly) empty aliases and referencing these should be okay.  That way, a custom skin at least has the option of overriding the alias to specify common properties that should be shared across selectors.

That's indeed a very valid approach as well.

Actually, one benefit of the global AFDefaultFont/AFDefaultFontFamily aliases is that you could use these to suppress font styles across a custom skin in a centralized manner, rather than suppress these styles

for each selector.  Have you tried this? 

Yes, we always redefine those and it works fine, except for the problem I mentioned before when you want to increase the size or change the font family within a container component.

When you say "doesn't work" - do you remember how this failed? 

From memory I would say a parser error that removed the property from the final CSS, but let me retry it to be sure... Ad it seems to work in 11.1.1.4.0 while it wasn't being taken into account in 11.1.1.5.0. I'll try to retest the latest version to find out exactly what was happening then.

However, inline image definition do fail.

background: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiA/Pgo8c3ZnIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgdmlld0JveD0iMCAwIDEgMSIgcHJlc2VydmVBc3BlY3RSYXRpbz0ibm9uZSI+CiAgPGxpbmVhckdyYWRpZW50IGlkPSJncmFkLXVjZ2ctZ2VuZXJhdGVkIiBncmFkaWVudFVuaXRzPSJ1c2VyU3BhY2VPblVzZSIgeDE9IjAlIiB5MT0iMCUiIHgyPSIwJSIgeTI9IjEwMCUiPgogICAgPHN0b3Agb2Zmc2V0PSIwJSIgc3RvcC1jb2xvcj0iI2ZmZmZmZiIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjUwJSIgc3RvcC1jb2xvcj0iI2ZmZmZmZiIgc3RvcC1vcGFjaXR5PSIxIi8+CiAgICA8c3RvcCBvZmZzZXQ9IjEwMCUiIHN0b3AtY29sb3I9IiNkMGQ5ZTAiIHN0b3Atb3BhY2l0eT0iMSIvPgogIDwvbGluZWFyR3JhZGllbnQ+CiAgPHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgZmlsbD0idXJsKCNncmFkLXVjZ2ctZ2VuZXJhdGVkKSIgLz4KPC9zdmc+);

produces:

java.lang.StringIndexOutOfBoundsException: String index out of range: -5

at java.lang.String.substring(String.java:1937)

at org.apache.myfaces.trinidadinternal.style.util.CSSUtils._resolveURL(CSSUtils.java:803)

at org.apache.myfaces.trinidadinternal.style.util.CSSUtils.resolvePropertyValue(CSSUtils.java:71)

at org.apache.myfaces.trinidadinternal.style.util.CSSGenerationUtils.writeCSS(CSSGenerationUtils.java:329)

at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createStyleSheetFiles(FileSystemStyleCache.java:835)

Thanks,

~ Simon

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-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Chris Muir]

While there may be a few more posts to this thread, it's naturally
concluding so I'd like to make a post near the end.

I think we're on a winner with the "I Am" ADF EMG series (even if I
did steal the idea from Redditt). The original thread with Ultan on
User Experience drew 33 messages, and this thread with Andy 56
messages. I hope members have enjoyed the overall thread as much as I
have, you've had a chance to learn a few things, see the expertise
inside Oracle and outside too.

On behalf of the members I'd like to thank Andy for taking time out to
participate. Members may not realize but Andy answered most of this
out of work time, had to deal with some priority 1 bug fixes during
the 2 weeks, and even had to deal after some sick children at home
during the week too. So thank you Andy, your time and effort is
really appreciated :-)

Thanks also must go to everyone who participated and posted. The EMG
doesn't exist without you actively joining in, and you came in with
spades. Thank you!

EMG members might be interested from here what "I Am" threads the EMG
is planning? I'm currently working with a key IDE UI/UX designer
which will provide a great chance to talk about the IDE and all it's
productive tooling. Beyond that I've just talked to an expert Fusion
Apps architect who should be able to give us the in-house story of how
ADF is used for one of Oracle's largest software developments.
Assuming no hiccups, I hope to run these sessions over the next
quarter.

Thanks again to Andy and members for staying tuned over the 2 weeks.

Regards,

Chris Muir
ADF EMG Group Moderator

[Andy Schwartz]

On Fri, May 18, 2012 at 2:16 AM, Chris Muir <chris...@gmail.com> wrote:
>
> On behalf of the members I'd like to thank Andy for taking time out to
> participate.  Members may not realize but Andy answered most of this
> out of work time, had to deal with some priority 1 bug fixes during
> the 2 weeks, and even had to deal after some sick children at home
> during the week too.

I even got to learn all about "Roseola". Had never heard of it
before. I guess it's the sort of thing only parents of kids in
daycare need to know about. :-)

>  So thank you Andy, your time and effort is
> really appreciated :-)

Thanks Chris. Just in case it wasn't obvious... I had a blast!

> Thanks also must go to everyone who participated and posted.  The EMG
> doesn't exist without you actively joining in, and you came in with
> spades. Thank you!

Yes! I feel like I am now able to look at ADF Faces with a new pair
of eyes. Thank you all for sharing your perspectives. Still pretty
sure I learned the most out of everyone here. :-D

Andy