RichFaces on JRE 1.6
by Brian Leathem
Hi Team,
One of the RichFaces requirements for WFK is to run on JRE 1.6. We
should run our test suite against JRE 1.6 as soon as possible to make
sure we have the desired compatibility. Ideally we would do this before
our 4.5.0.Final release.
@QE: can you proceed with setting up a run of our test suite with JRE 1.6?
Brian
10 years, 11 months
Chart component for mobile devices
by Matej Novotny
Somewhere along 4.5.0.Alpha2 release we decided not to support rich:chart for mobile devices.
I found two related issues to this - RF-13709[1] and RF-13702[2]. Both mention something like 'for the time being we are removing the charts from mobile devices'.
So the question is, do we want to support charts on mobile devices? If so, we should start addressing this issue until we hit final release.
____________________________________________
[1][RF-13709] Remove the chart components from the RichFaces mobile showcase - JBoss Issue Tracker (https://issues.jboss.org/browse/RF-13709)
[2][RF-13702] Charts Mobile Showcase - initial rendering is broken and with JS errors - JBoss Issue Tracker (https://issues.jboss.org/browse/RF-13702)
Posted by forums
Original post: https://developer.jboss.org/message/905219#905219
10 years, 11 months
Chart component naming
by Michal Petrov
I think the current naming of the chart sub-components is a little vague, especially when viewing the VDL doc where the components are all over the list.
The components are:
* rich:chart
* rich:legend
* rich:point
* rich:series
* rich:xaxis
* rich:yaxis
One solution would be to give all components a "chart" prefix so that it becomes more apparent what those components are for, we already have a precedent in tree (tree, treeNode, treeAdaptor) and notify (notify, notifyMessage, notifyStack). Then again, rich:column is one of the elements that can only be used inside another component and it's standing alone in the list.
What do you think?
Posted by forums
Original post: https://developer.jboss.org/message/903401#903401
11 years
Page Fragment API review
by Brian Leathem
Hello rich faced devs!
In reviewing a recent PR [1] for RF-13301:" Favor use of Page Fragments
in Framework Tests" [2] I've gotten a good chance to see page fragments
in action. I really like how they remove a much of the DOM setup of the
integration tests. A powerful abstraction indeed.
However I'm a little concerned over some of the generic names we have in
the page fragments API. Consider the RichFacesTabPanel fragment [3] in
the above PR. It has methods (among others) with the following names:
* RichFacesTabPanel#getRootOfContainerElement() to return the content
element of the TabPanel component
* RichFacesTabPanel#getSwitcherControllerElements() to get the headers
of the parent Tab
Both of these names are quite generic since they are inherited from a
parent class that shared amongst all switchable components. However,
for both these methods the super method is abstract, so there is no
shared implementation. Can someone with more knowledge of the page
fragments implementation explain the benefit of the method inheritance
here? IMO the abstraction leaves us with an unclear API which won't
help adoption.
If we can come to an agreement of how we can improve this, we can scan
the remaining page fragments for methods that can benefit from a similar
naming improvement.
Also, while on the subject of page fragments, I noticed the javadoc for
page fragments is not included in our generated javadoc. This also will
hurt adoption. I've created a jira RF-13816 [4] to address including
the javadoc for page fragments. Please comment there if you feel they
shouldn't be included.
Cheers,
Brian Leathem
[1] https://github.com/richfaces/richfaces/pull/108
[2] https://issues.jboss.org/browse/RF-13301
[3]
https://github.com/richfaces/richfaces/blob/master/build/page-fragments/s...
[4] https://issues.jboss.org/browse/RF-13816
11 years
Re-scheduling 5.0.0.Alpha4 issues
by Brian Leathem
Hey guys,
I realized we had a bunch of unresolved issues scheduled for RichFaces
5.0.0.Alpha4. I've reviewed them, many were obsolete and have been
resolved as such, while some I've scheduled for 4.5-Tracking. There are
however a few that issues where it's not clear if they still apply.
Please check any unscheduled issues assigned to you for verification
ASAP so we can include them in 4.5.0 if necessary:
https://issues.jboss.org/issues/?filter=12316302
Cheers,
Brian
11 years
