This week's book giveaway is in the HTML/CSS/JavaScript forum.
We're giving away four copies of Practical SVG and have Chris Coyier on-line!
See this thread for details.
Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Richfaces doShow() method

 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm bringing up a context menu in the oncomplete handler of an a4j:function:



For the life of me, I can't find out what that second parameter to doShow is for. All my Googling has only produced the information that it is called "context", but no examples or explanations of how it could be used. It bugs me not knowing things like that.

For that matter, what's the difference between doShow() and show()?

 
Tim Holloway
Bartender
Posts: 18422
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did a bit of quick searching of the RichFaces 3 docs, which is all I have handy. RichFaces 4 is, as I've said before the "VB.Net" of RichFaces, and the conversion cost is going to be so high that I haven't dared even begin.

In the RF3 docs, however, there is no sign of a "doShow()", just "show()". I found someone exactly doing what you described on another forum, however, with a doShow(). So maybe it's a RichFaces 4 thing.

The RF3 docs seem to imply that contextMenu is a form of componentControl, but there, too, documentation is lacking. So these parameters may be more important in that context than in a contextMenu.

My best guess is that the event parameter is basically just an indicator of what type of event is being fired and the context likely applies to where and at what level the menu would appear.

To know more, I'd have to have an example that I could breakpoint and dissect, but apparently the defaults are good enough for most purposes.
 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I agree about Richfaces 4. I tried and failed to do an upgrade to its first stable release about a year and a half ago. It was still functionally incomplete though, and just horribly documented. I was hoping to give it another whack now that it's at 4.3, but it sounds like it's still a painful transition. The big problem is that Richfaces 3.3.3, which we use now, has big stylesheet problems with IE9 and above and IE is our targeted browser. I have to force the browser into IE8 mode for the application to work even passably. So, with that and the conflicts with Richfaces 3 and JSF 2.0, I'm caught between a rock and a hard place. I suppose a lot of people maintaining Richfaces apps are caught in the same dilemma.

That's interesting about doShow() vs. show(). The doShow() call is working for me with Richfaces 3, and I found some examples, including probably the one I modeled from, that use doShow() as well under Richfaces 3. The documentation does seem to say only show() should work though, so I have no idea what's going on.

My real goal, besides just wanting to know how things work, is to get the context menu to close more reliably when the user mouses off of it. Right now the context menu is positioned so that the mouse cursor is at its 0,0 corner. If the mouse is immediately moved left or up, that doesn't seem to trigger a mouseout event and the context menu can just stay floating there. I thought that maybe if the context menu was offset so the mouse pointer started inside its boundaries, then that problem could be reduced. There are horizontaloffset and verticaloffset parameters, but not until Richfaces 4. I thought something in the context might help, but I can't even figure out an experiment to test that.
 
Tim Holloway
Bartender
Posts: 18422
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good documentation is a rare and precious find. Most non-commercial (and some commercial) documentation ultimately comes from people who'd rather be doing creative software design than writing a manual, is often written by people who forgot how un-intutitive their core concepts are (since they've likely been using the stuff daily for a year or so by that time - AND the basic architecture probably mutated as the system developed).

Then there's the other problem, which is that the primary author(s?) of RichFaces are not native English speakers.

I know it's fashionable to complain about stuff written in Indian English, but I'd rather have that than Russian English. Russian lacks the definite and indefinite articles and when you're dealing with technical nuances, often "circle", "a circle" and "the circle" have critically different meanings. Indian English mostly just has problems in prepositions, and don't we all?

I think RF4 is functionally more solid now, although I was disappointed that dealing with pick lists is still a horror. I really do think that they could have put more effort into backwards compatibility, though. I'd volunteer for the job myself if I could afford it. Java isn't supposed to leave you twisting in the wind. That's what Microsoft is for. Then again, in my more cynical moments, I remember that they're apparently willing to provide conversion services. For a fee.
 
Greg Charles
Sheriff
Posts: 3010
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I see what you mean. I actually find Ilya understandable most of the time, and as a developer, I appreciate just how much work he's putting into Richfaces. At the time I was trying to do the upgrade though, it wasn't a matter of the documentation being poorly written ... it just didn't exist at all. I'd go to the page documenting attributes for a particular component and it would just list the attribute names, while all the descriptions were empty. That's been mostly taken care of I think, but even in the wilds of open source software, I would have expected that to be complete one before RichFaces 4 was labeled "final". Oh, well.

Pick lists aren't a big deal to me, because the application I'm maintaining just doesn't use them. It uses a lot of extended data tables though, and the new table components (at the time anyway) didn't seem to provide a reasonable substitute. Even something like column widths proportional to the browser window was hard to accomplish. The new scrollable tables seemed to assume that if you wanted a table to scroll vertically, you'd also want it to scroll horizontally, which goes against a pretty well-established standard for browser-based applications. That's the main thing I want to revisit.
 
Tim Holloway
Bartender
Posts: 18422
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have an application that uses pick lists. It allows you to bring up a page for a JavaRanch moderator and allow him/her to select what forum(s) he/she/it would like to moderate.

For me, an ideal pick list would leverage the JSF SelectItem and provide a model class containing 2 lists: 1 being the total list of selectable items and the other being the ones actually selected.

The actual RichFaces PickList violates Alan Kay's stricture that "Simple things should be Simple and Complex things should be Possible" in that their construct makes it possible to do very elaborate renderings of the lists but even the simplest plain-jane selection list requires (I think) a custom user-defined model class plus a custom user-defined converter class. Except that the documentation doesn't even make that clear - you are expected to look at the code samples Which I generally don't have handy, since I'm using Maven to pull the RichFaces stuff I need. I also don't trust un-annotated code samples, as they are specific solutions to someone else's problem and may not cover all that I need to know.

The docs typically were simply reflecting the attributes of their base classes, even when the inheriting class differed. And don't even get me started on the mysterious "data" feature that can be used to send JSON data back to the AJAX code on the client. I had to figure that out from scratch.

I'd do more whining on the actual JBoss forum except that my dealings with JBoss go back to before Red Hat's acquisition of the technology when any criticism of the way they did things was seen less as an opportunity for improvement and more and a personal insult. As is often the case with software products and it's why I am a fan of the CodeRanch, the long-missed Commodore Amiga development team and the ObjectWeb JOnAS group. All of which have been more encouraging and some of which have even actually implemented my suggestions.

Besides, the captcha that JBoss was using last time I tried to get onto their forums was so unintelligible I wasn't able to re-activate my account. Ironically, however, based on the displayed messages, it hadn't been an obstacle to the spammers.
 
Gravity is a harsh mistress. But this tiny ad is pretty easy to deal with:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!