Help coderanch get a
new server
by contributing to the fundraiser

Vance Montague

Greenhorn
+ Follow
since May 13, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Vance Montague

The actionListener property will execute the code properly. Here's how it looks:





The actionListener property specifies managed bean code to run when that button is clicked. The difference between this and the action property is the action property must be a string equal to one of your navigation rules - this can be hard-coded, or returned from a managed bean function (as you have done with action="#{PracticeBean.kill}"). actionListener, on the other hand, must be a function in the managed bean with an ActionEvent parameter. It does not forward the page afterwards, like the action property does. Both of these properties, however, call the bean code when the button is clicked.

onclick, however, is just a string specifying the javascript to run when the button is clicked.

<h:commandButton onclick="jsfunction();" /> renders to something along the lines of <input type="button" onclick="jsfunction()">

Referencing a JSF bean in this property is valid, but the key is that it runs when the page renders and expects a String value to be returned to fill in the property.



within bean class:


This is valid and the resulting page will render to something like this:

<input type="button" onclick="foo();">
13 years ago
JSF
Just pick the style you like the best and stick with it. The important thing isn't which style you use, but to be consistent throughout the code, all for the purpose of making it easier for you to read and scan quickly with your eyes.

One common style is to use underscores/lowercase for private data (some_private_variable), and camel case for public (somePublicMethod). It's not set in stone, it just makes it easier for your eyes to pick things out faster.
13 years ago
The Trinidad library has a date input component. The calendar pop-up window is built-in:

http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_inputDate.html
13 years ago
JSF
I heard of the view scope - unfortunately, the project I'm working on is using JSF 1.2. Maybe someone using JSF 2.0 can share their review of it?

Anyway, I gave Orchestra a shot and it seems to be working nicely. For anyone that may run into this problem in the future: in spite of requiring Spring and Orchestra libraries to be added, the solution still managed to work pretty seamlessly with an existing JSF project, without adding much complexity - managed beans will function the same, Orchestra just adds a new conversation scope.

Just need to throw spring.jar into your lib folder, and add the spring config file called "applicationContext.xml" to WEB-INF.

Then, orchestra jar files go into the lib folder as well, and the definitions for Orchestra's conversation-scoped beans are added to applicationContext.xml (it uses Spring's custom scope capability, hence the need for spring). Other than a few more lines needed in web.xml and faces-config.xml, that's all there is for setup.

The result is:
1) your existing JSF managed beans remain the same, and you can continue declaring request/session scope beans in faces-config.xml
2) now managed beans can also be declared in applicationContext.xml using the new conversation scope
3) beans from either of these two files are accessed the usual way from source: #{bean.whatever}

There is also a decent Orchestra API for the back-end stuff. If you're accustomed to using FacesContext to access beans from the session, Orchestra has something similar with ConversationManager, which gives you access to the beans stored in the conversation scope.

Thanks for the input, everyone.
13 years ago
JSF
Sorry, maybe I didn't explain clearly enough. I actually don't even want two browsers to have access to the same bean (so race conditions are not applicable). I want each browser to have its own instance of the session bean.

I've been researching more and I think I found something that addresses the problem - a library called Orchestra:

http://myfaces.apache.org/orchestra/index.html

It leverages off of Spring to create a new bean scope called "conversation" scope, which I believe would create a new instance of the bean for every browser or tab that is opened. I'll post an update if I find it solves the problem.
13 years ago
JSF
I am building a web app that allows users to create and edit records. The forms are somewhat complex with a lot of fields, and use heavy partial page rendering for adding and removing entries. The managed beans are session-scope.

Here is the perhaps familiar problem related to session-scoped beans: when a user opens more than one browser, bean data from one browser is unsafely altering the state of the other browser.

For example, if a user opens record A in browser #1, and then opens record B in browser #2, then record A will be over-written in the session. Browser #1 is now an invalid view of the current session data, and doing anything in this window will have unknown results.

This is an unfortunate side-effect of having session-scoped managed beans. And yet request beans just don't cut it for the amount of data and the amount of processing being done. For example, even before the record is ready to be submitted and saved, there is a ton of partial-page requests to add more fields, do custom validation, etc.

Ideally, I'd like only user information to be session-scoped (if a user logs in in one browser, and opens another browser, that one is also logged in. This bean works perfectly fine as a session bean). But individual records should have a feel of being request-scoped (a user should be able to edit two different records in two browsers; does not work so well as a session-bean). My attempt to rework this data into a request-scoped bean convinced me that it can't be done short of passing tons and tons of data back and forth with every action, and is therefore impractical, so there I am stuck.

I'm looking for solutions or alternative approaches. Any insight would be appreciated!

I'm using JSF 1.2 + Facelets + Trinidad.

Note: I've seen something called pageFlowScope mentioned in Trinidad's documentation. This is the closest thing I've found to a potential solution, but unfortunately it seems primitive and cumbersome. I've hit a dead-end looking into it - as complete as Trinidad's documentation is, much of it is briefly mentioned with no examples or resources to go with it. But if anyone has had success with this, please let me know.
13 years ago
JSF