thats right, some components like rich:spacer & rich:separator where removed in RichFaces 4
is there a replacement for rich:spacer ???!
Nope, this is really a job for CSS. We did have a lot of debate about it early in the cycle in our team meetings, but in the end did not want to duplicate the job.
Although it is repetitive, but no one thought about backward compatibility.
My justification why it was removed- ALTERNATIVELY, you guys measured by how many companies have implement rich faces 3 and more companies will go with rich faces 4 means it is growing, so it makes sense to remove it.
if you want to add spacer.gif to your application pages - just create composite component. In JSF 2 it will take about 20 min and then all the rich:spacer's could be bulkly replaced with your composite component. But as it's not recommended for usage according to semantic HTML principles - we decided not to inlcude as ready-to-use tag.
what about shuttle and pick list ?
ListShuttle component was implemented just too complex. And pickList was just lightweight version of LS (which was not easy to implement because of all that converter-equals-hashCode stuff). So we decided not to migrate them in such state(Having duplicated staff just for the different data cases) but perform redesign to have single component which easilly configurable working with SelectItem(s) base data and requires additionall settings only working with custom objects.
That's really sad that them not fit final - but we decided that it will be more accurate so it's worth to be postponed. We already discussiong plannign for such "hot" components for near versions.
+1 to this. RichFaces 4.0 has turned out to be a major headache for us, so much so that we've decided not to migrate. We have no time to go through our applications and rewrite them because the team decided to remove components or classes that were previously there. It is ridiculous.
it is your decision to ged rid of rich:spacer in RICHFACES 4. OK.
But I dont see how I can get an easy solution with CSS alone when it comes to Tables.
Since tables in JSF work in columns, many times I need an "spacer" to keep the column count working:
SInce there is nomore a spacer, what would be an easy solution to fill an empty cell?
if I use <h:outpuText with value="" the table will not accept it as a cell and hence shift all following columns to the left
if I use <h:panelGroup it is too much Code for nothing
should I go with an image tag? or may be just a <span/>
what is an appropiate solution?
tx in advance. (I am migrating from RF 3.3 to 4, and we used plenty of rich:spacer)
We are now looking at alternatives to RichFaces, because we refuse to deal with the attitude of the developers that backward compatability doesn't matter.
"backward compatability" is very important, I agree, just think what JAVA would be like if it was Action script from FLASH (rewriting all the app every year) lol...
Yes we also noticed that many things have changed, especially when I think about as tiny things as
"rich:datascroller" changed to "rich:dataScroller" and I had to go through all the pages, and was thinking: "was that nescesary?"
We decided not to migrate existing richfaces apps to 4.x because the work of chaage is tremendous. I agree!
But starting new Projects we go straight with Richfaces 4. and hope that things will be OK in a future and there will be more backward compatability.
OR at least one generation of deprecation.
So I still wonder what Solution to use in Tables, without rich:spacer?
We are currently on 3.3.1 and considrering migrating to 4.0. ( few issues that went away in 4.0 in the incentive )
However we are heavily relying on the Spacer object. I totally disagree with Jay Balunas comment above. When to use css or spacer is up to the developer and not the framework!!! This is plain software engineering: Framework should not dictate application implementation but should provide flexibility to the developers who use it. In our case, a Spacer object is mandatory since we let users create very basic "layouts" and the only way to do that ( for us ) in a user friendly way is to stick spacers of different sizes where the user wishes. But again , this is not the point.
Any chance you put back the Spacer in 4.X ? Unlike the list shuttle etc. it is not a complex component and for the sake of backward compatibility ( and my own situation ) I really think it should go back in, or maybe richfaces gus can provide simple instruction + source code so we can create a custom component ?
Was not able to skip that thread comments. Guys, community had hundreds of issues and RFCs filled for 3.3.x. And we went through every of them fixing most of them and postponing some(even some really important) of them just because some changes was really impossible from backward compatibility point of view. Because we also believed that the compatibility within major version (3.3.x) is the most important thing which all developers expect to be maintained.
But 4.x design - was the time to consider all serious issues which was not solved in 4.x. That included performance, markups and so on. Yup much of the stuff was rewritten and many changes introduced. But hey, didn't you asked for that? Good example will be - data table models and component classes was changed.. And you can't just run the same code in 4.x because of those changes. But if you will do some POC and try out the changes you should see that it's because of refactoring related to improvements introduced. If you will work some more time on some performance testing you will see even more proc in our "refactoring" approach. Same is about some components attributes set changes (easier and more transparent customization). And about CSS styling changes (Didn't you see that we reduced the numerous classes decreasing HTML size and making styling easier?).. And some other little thins which could look not really convenient because make migration slightly more comples but instead provides improvements which was asked for so long time.
Finally speaking about particular <rich:spacer> absense - it's really sad that some of you counting that as a critical issue for the migration. Try to consider semantic markups principles to learn more about better ways to do the same things. And if you really missing that "component" - http://community.jboss.org/wiki/SpacerImplementationForJSF2OrRichFaces4 that composite component creation requires about 5 minutes of your time(you could even use the same rich: prefix and only add namespace where needed). Then you could continue using that great "spacer.gif" in future.