[bleathem]

+1 Paul, good reply.  It'll be interesting to see if anything breaks with the JSF 2.2 release, we certainly don't *expect* anything to break.  We'll address any issues as they come up, with releases appropriate dependning on the timing of the 2.2 release.

Brian

[gadge]

Hi, guys. I was wondering, do you plan to make arrangeable orderingList with drag and drop ? Here's an example of what I have in mind: http://www.primefaces.org/showcase-labs/ui/orderList.jsf

[paul.dijou]

Are you talking about something like: http://bootstrap-richfaces.rhcloud.com/component/orderingList/index.jsf ?

Coming soon! Stay tuned.

[gadge]

Yes, exactly. I was aware that it might be started but couldn't find the place where to look. Thanks Paul

Maybe you could provide a link where the progress is shown or a milestone of this feature ?

[paul.dijou]

Sorry, I can't. RichFaces Bootstrap components are a bit special and still in Sandbox. There is discussion about what their future should be, but right now, it's still uncertain. I think they will probably emerged as a top-level project which will be usable side-by-side with current RichFaces Components, so it will not be a milestone. But as I said, just my personnal though about it.

[hantsy]

I am using Richfaces 4.2 and Bootstrape css(I have not used the Richfaces Bootstrap sandbox project) in my newest project, but I avoided the heavy Rich components, in fact, I only used very few components from Richfaces components, beside dataTable and scroller.

I deployed a version into openshift for demostration, http://ticklerapp-hantsylabs.rhcloud.com/ (username/password is hantsy/123).

I used Richfaces since 3.x, the problem I encountered when I was using Richfaces is the final generated HTML codes is a little tedious...especially, some componenets, suchas toolbar, it still used table based layout in Richfaces4, no any improvements in Richfaces4. I dislike table based layout in projects, but when I used Richfaces 3/4, it seems I must use table layout. If I used css layout, and place some richfaces in page, it could cause some weird alignment problem. So in the new projects, I gave up most of richfaces components.

About the Richfaces 4 CDK, I have a very stupid question, why cdk templates generate the final long Render class for the component, instead of generating a jsf 2 composite compoenent...in jsf2, a composite component could be consist of xhtml facelet and some resources, such as  js, css... why we still use the legacy approach to produce jsf 2 components.

Regards

Hantsy

[lfryc]

hantsy bai wrote:

I used Richfaces since 3.x, the problem I encountered when I was using Richfaces is the final generated HTML codes is a little tedious...especially, some componenets, suchas toolbar, it still used table based layout in Richfaces4, no any improvements in Richfaces4. I dislike table based layout in projects, but when I used Richfaces 3/4, it seems I must use table layout. If I used css layout, and place some richfaces in page, it could cause some weird alignment problem. So in the new projects, I gave up most of richfaces components.

In time of writing RF 4.x components, there were not enough standard ways how to support certain layouts with HTML and CSS without tables. We can't re-design them without losing backward compatibility.

With Bootstrap, we are moving to light-weight HTML5 like widgets and thus your concerns should be solved, shouldn't they? :-)

About the Richfaces 4 CDK, I have a very stupid question, why cdk templates generate the final long Render class for the component, instead of generating a jsf 2 composite compoenent...in jsf2, a composite component could be consist of xhtml facelet and some resources, such as  js, css... why we still use the legacy approach to produce jsf 2 components.

Composite Components was were buggy at time of 2.0 and still have a lot of problems with interoperability.

That's why we use CDK, which have templates that are very similar to Composite Components syntax (in fact, it uses subset of CC tags).

In RF 4.3.0.Final (and with Bootstrap components), we will ship those templates in *-sources.jar alongside Java renderers and components. This will allow you to see a renderer's XML source easily.

We will also format the Java renderer sources according to JBoss formatting rules - which will make them more readable and improve debuggability.

Did it help you perceive CDK better? :-)

I deployed a version into openshift for demostration, http://ticklerapp-hantsylabs.rhcloud.com/ (username/password is hantsy/123).

Very nice!

[vrelits]

Had hoped 4.3 could also look at performance related issues, such as RF-11742, but that seems to not be the case.

[bleathem]

We are aiming to address these performance issue over the next several releases.  Currently we are looking at RF-11382 to be resolved in the 4.3 timeframe. 

Note to all, keep voting for issues, as that is one of the metrics we take into account when scheduling issues.

Brian

[gonzalad]

Another idea for a future improvement (not a vital one, but nice to have) :

• try to reduce Richfaces size (9.3 Mo for RF 4.3, it's quite huge)