ed connell

Greenhorn
+ Follow
since Oct 26, 2009
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 ed connell

Have been considering the return 2 idea, pretty much as you've described, and since I thought of it, it must be pretty straightforward. Problem again with that seems to come back to restoring the info on the origin page, when one of the original pages was full of other stuff. Seems that takes me right back to the needing a session bean for all that original busy page info, or carrying around a whole lot of parameters, just as you described earlier. Fun fun.
14 years ago
JSF
That's consistent with our installation of WAS 7. It can toggle between SUNRI or MyFaces through the admin console. I've been unsuccessful in overriding the IBM version of the SUNRI, even after following some WAS documentation which seems to suggest it can be done. If anyone has had any success in that, I'd like to know how.
14 years ago
JSF
Thanks Tim - great insight as always.

Seeing you use phrases like "work arounds" and words like "tricks" gives me comfort I'm not completely missing everything.

I came across another interesting situation the past couple days where I have a common page that can be navigated to from two different origins. Thought it might be nice to add a cancel button on that destination page and well, you can probably see how that goes bad. Started to scheme about possibly trying to devise a slick solution which could hook the initial navigation to a page, maybe even keep a whole series of pages, push the input params on a session maintained stack then be able to also hook a cancel button action, pop the stack and replace the param map in the restore view possibly or something, and maybe get JSF to magically go back to the origin page. Lol. Don't think that's gonna work out too well, since the param map is immutable, but was fun to think about. Haven't given up quite yet...

Thanks again for the reply.
14 years ago
JSF
I've got what I assumed is a simple situation, but doesn't quite work as I intended, so just shows how much of a novice I still am with JSF. But, I'm trying, that's what brings me here.

So, in trying to keep with request scoped beans, and away from session scoped. The simple page idea is the user navigates to the page from another page. The action method enroute loads the backing bean initially.

Backing Bean 1 is loaded with the initial value.
Initial value is shown in column 1 as output text.
Backing Bean 2 is to receive a user entered value from input text in column 2.

Now, since BB1 and BB2 are basically identical, they're the same object, just different names.

On form submit, want to compare col1 and col2 values. If different am going to update the external source with the new value.

In comes issues I kind of expected. First, col1 was preloaded by the external action. If the page needs redisplayed, that value needs to be carried into the redisplay. So, I add a <h:inputHidden> with the value of the BB1 to carry the original value forward for a redisplay. Is that commonplace? That method actually seems to work okay, but goes wrong if I add a validation to col2. If col2 fails validation, the col1 value is not carried forward into the output text of col1. It's not applied, but it does carry forward as a hiddenField oddly enough.

This just seems a fairly general problem to me, and wondering why I'm struggling to find a fairly general solution. I don't feel like creating a single backing bean with col1 and col2 dup'd as "original field", "submitted field".

Yes, why two columns. Just because.

I probably can get it to work without any validations, and just doing validations on the application phase.

Anyone know what I'm talking about here?
14 years ago
JSF
Many thanks to you both - I'll discard that line of thinking then and plow ahead with styling up my panelgroups and grids.

I must admit-my little experiement at resorting back to html markup was making the code look just downright ugly.

Ed.
14 years ago
JSF
If I were just using JSF, and not a nice component library like RichFaces, there's obviously quite a lack of control with the panelgrid component.

I believe I saw mention on this forum somewhere, think it was Tim H, to just use html tables to gain control of the formatting.

I just started to experiment, and it seems to be what I should've done from the start, rather than try and shoe horn everything into panelgroups and panelgrids.

So, would this be considered common place to just use the html markup, peppered with JSF tags? Any pitfalls I'm likely to run into before I go too far down this road?

Thanks
14 years ago
JSF
I've developed a JSF application using Tomcat 6. Target state is Websphere 7.

I've made what I assumed sensible use of backing beans. Application scope for caching static data from RDBMS, session for typical "shopping cart" info which includes session related information such as a customer id, account details, and request beans for single request type stuff.

It was great fun, a great challenge, lots of hurdles to overcome, but it's time to make it really work.

Enter a clustered Websphere arena, the target state. Now, I've been curious all along how these different types of backing beans are to be persistent should the environment be multi-servered, instead of a single server as in my Tomcat development. Throughout development, whenever I viewed source, there was obviously lots of embedded JSF related stuff, which I assumed was some type of session object serialization. I've had the STATE_SAVING_METHOD set to client, just because that was the default. (A little reading, and it seems that SSM configuration option has to do with the view, and I'm assuming that might suggest it has nothing to do with any backing beans?)

It was obvious as soon as I rolled into Websphere I've got big problems with my backing bean states. I've not ruled out something stupid on my part. The first session scoped backing bean is created for the application. The next page has a mixture of a request scope bean, and some session scoped bean information generated in the first page. It invokes an action on the request scoped bean, which tries to pull in data from the session scoped bean, and the session scoped bean cannot be found. According to logs, the original page was renderred in WAS "WebContainer 0", but the second is being handled in "WebContainer1". So, naturally, I'm thinking the session bean is available in WC0, but is unavailable in WC1.

Can anyone explain the obvious thing I'm missing here, and hopefully tell me I'm not totally screwed? Oh yea, a solution would be good too.

Thanks

14 years ago
JSF
Out to prove once again a greenhorn I be, so here goes (keep it friendly all)

Appears to me what I want is a nested value in EL for the h:formatText

Of course, I could do this with a bean property, but was just trying to avoid it.

Here's the situation. Simple enough. One page has basically the same output simple toggled by an input param, either "daily" or "montly"

So, assume I want the title to say "Daily Statistics" or "Monthly Statistics". My resource bundles would be:

ingles:
stat_pg_title={0} Statistics

espanol:
stat_pg_title={0} estadísticas

Can I get "Daily" or "Monthly" to get its locale equivalent into {0}? I've tried different combinations of things, to no avail. One attempt was to store "Daily" or "Monthly" in a bean property "timePeriod" as so...


Any ideas?

Thanks.
14 years ago
JSF
Thanks to you both.
14 years ago
JSF
Thanks for your time, and your replies, Tim.

I'm not exactly sure you've answered my question, but you have given me some things to think about and look at as my stuff evolves. I think my question was a little more general, and I didn't necessarily want to get into a discussion about an authorization system. So, I'll try to phrase it again, in my usual stupid fashion.

Try to imagine a JSF application which needs an externally supplied input "FOO" that is not hard coded in faces-config.xml as a managed-bean property. If the primary JSF page is moose.jsp, I cannot launch the application as moose.jsp?FOO=xyz or moose.jsp?FOO=abc, correct? The way I read my google hits, I thought that was one of the issues the "NonFacesRequestServlet" was offering to address?

If I want FOO to become a managed-bean property, and carry forward throughout the session, again, how can that be done?

Sorry for being so dense.
14 years ago
JSF
Maybe we're getting somewhere now. But, I'm still at a loss on my issue.

Tomcat is just my dev environment. Actual target is IBM Websphere.

If the security mechanism is implemented as Realms for argument sake, and Realms were to gather the USERID field as part of the container managed auth, how would that USERID be made available to the JEE Webcontainer so it can be accessed by the initial JSF application page, assuming I got my lingo correct.
14 years ago
JSF
Funny how you should mention that. This is an internal network, and the "single sign on" application is exactly the concept I'm referring to. I believe it runs as a plugin on the web/appserver completely unbeknownst to the JSF application. I'm not clear on the exact details of the interactions. If I assume the plugin runs as a wrapper on the same server, I think my issue is the same. It is not part of a JSF application. How does the resultant USERID from that signon get passed to my JSF application so the JSF app can use it as part of its processing?

Is that a stupid question?
14 years ago
JSF
I'm a little unclear on the exact details, but here's what I'm assuming.

The web/app server traps my JSF url. If the user is not auth'd it redirects to the auth page. The auth page is external to the JSF application. The auth page takes credentials, userid/password, validates then redirects to my application URL as a post with USERID as an input param.

Makes sense so far?

My application URL wants to be an entry to a JSF application. How do I pass that USERID into the JSF application and say use it in a backing bean on the first page?

Is this a stupid question?
14 years ago
JSF
Disclaimer: JSF newbie.

Dev Env: Eclipse Galileo, JSF1.2, Tomcat6

Anticipating a situation where authentication is done external to the in development JSF application.

Successful authentication will invoke my application with a couple inputs describing the user, let's say /url?USERID=GREENHORN. Simple enough, right?

Now, I'm assuming the JSF app cannot be invoked directly and make use of USERID directly.

This I'm assuming is where the NonFacesRequestServlet mockup shown at http://wiki.apache.org/myfaces/InvokingJsfPagesWithStandardUrls comes into play.

I setup navigation rule from "/fake_out.jsp" on outcome success to "/moose.jsp" and have the mockup servlet successfully render the primary JSF page (moose.jsp). That page will have a backing bean (how to feed USERID into that I've not solved yet), and let's say 3 input fields. The form will have action and validation, the beginning of my JSF application.

Trouble - when the JSF moose.jsp page renders, the submit action feeds back to "moose.jsp" which throws a "requested resouce not available" error. If I run a modified "moose.jsp" outside of the servlet mockup, all actions feed to "moose.faces".

If I can't overcome this hurdle, I'll have to ditch JSF altogether. I though about trying to capture the rederred output and rewrite the "moose.jsp" to "moose.faces" but haven't been successful on that yet.

Any clues?

Thanks
14 years ago
JSF