RE: [Shale] How to cancel the s:commonsValidator/
Thanks Gary,
I created my first submission to the issue tracker. Do I get a jacket
or a certificate now that I belong to this exclusive group?
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 23, 2006 3:52 PM
To: Struts Users Mailing List
Subject: RE: [Shale] How to cancel the s:commonsValidator/
From: James Reynolds [EMAIL PROTECTED]
Hmm, I downloaded the latest Shale libs and the first thing I notice
is that the validator fires for an h:inputText that isn't rendered.
This is what I have on my page:
h:outputText value=Last Name:/
h:outputText
value=#{sessionScope.visit.user.lastName}
style=font-weight:bold;
rendered=#{!members$myAccount.editName}/
h:inputText id=lastName
value=#{sessionScope.visit.user.lastName}
rendered=#{members$myAccount.editName}
binding=#{members$myAccount.lastNameInput}
required=true
s:commonsValidator type=required
arg=Last name
server=true
client=true/
h:message for=lastName
errorClass=errorText/
/h:inputText
The inputText boxes are not rendered unless the user clicks a Update
Name button that changes the boolean editName property. The problem
is that the Update Name button is triggering the validation on the
un-rendered InputText control.
I suppose the form's onSubmit event caller assumes the existence of
the Input boxes.
Yeah, that's a bug. The ValidatorScript should not generate javascript
for components that are not rendered.
Please create an issue tracker for this one -
http://issues.apache.org/struts/.
As a quick fix, you might try adding the same value binding to the
commonValidator client attribute.
s:commonsValidator type=required
arg=Last name
server=true
client=#{members$myAccount.editName}/
Gary
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 23, 2006 12:52 PM
To: Struts Users Mailing List
Subject: Re: [Shale] How to cancel the
From: James Reynolds
I'm coding a cancel button on an update form. I've set its immediate
attribute to true, but that isn't skipping the client side
validation.
Is there a way to do this, or must I only use server validation in
this case?
If you are using the JSF runtime commandButton or commandLink
component,
the JavaScript, bCancel=true;, will be injected into the onclick
event
when the immediate is set to true.
http://issues.apache.org/struts/browse/SHALE-37
Originally, this worked for all the javax.faces.Command family but
it
was just limited to the two JSF runtime command components due to a
tomahawk component issue,
http://issues.apache.org/struts/browse/SHALE-68.
Gary
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] How to cancel the s:commonsValidator/
I'm coding a cancel button on an update form. I've set its immediate attribute to true, but that isn't skipping the client side validation. Is there a way to do this, or must I only use server validation in this case? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] How to cancel the s:commonsValidator/
It was the last announced Alpha update finished around the end of March. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, May 23, 2006 12:44 PM To: Struts Users Mailing List Subject: Re: [Shale] How to cancel the s:commonsValidator/ On 5/23/06, James Reynolds [EMAIL PROTECTED] wrote: I'm coding a cancel button on an update form. I've set its immediate attribute to true, but that isn't skipping the client side validation. Is there a way to do this, or must I only use server validation in this case? This sounds like an issue that has been reported previously[1], and resolved as fixed. How recent is the version of Shale you are using? Thanks Craig [1] http://issues.apache.org/struts/browse/SHALE-37 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] How to cancel the s:commonsValidator/
Hmm, I downloaded the latest Shale libs and the first thing I notice is
that the validator fires for an h:inputText that isn't rendered. This
is what I have on my page:
h:outputText value=Last Name:/
h:outputText
value=#{sessionScope.visit.user.lastName}
style=font-weight:bold;
rendered=#{!members$myAccount.editName}/
h:inputText id=lastName
value=#{sessionScope.visit.user.lastName}
rendered=#{members$myAccount.editName}
binding=#{members$myAccount.lastNameInput}
required=true
s:commonsValidator type=required
arg=Last name
server=true
client=true/
h:message for=lastName
errorClass=errorText/
/h:inputText
The inputText boxes are not rendered unless the user clicks a Update
Name button that changes the boolean editName property. The problem
is that the Update Name button is triggering the validation on the
un-rendered InputText control.
I suppose the form's onSubmit event caller assumes the existence of the
Input boxes.
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 23, 2006 12:52 PM
To: Struts Users Mailing List
Subject: Re: [Shale] How to cancel the s:commonsValidator/
From: James Reynolds [EMAIL PROTECTED]
I'm coding a cancel button on an update form. I've set its immediate
attribute to true, but that isn't skipping the client side validation.
Is there a way to do this, or must I only use server validation in
this case?
If you are using the JSF runtime commandButton or commandLink component,
the JavaScript, bCancel=true;, will be injected into the onclick event
when the immediate is set to true.
http://issues.apache.org/struts/browse/SHALE-37
Originally, this worked for all the javax.faces.Command family but it
was just limited to the two JSF runtime command components due to a
tomahawk component issue,
http://issues.apache.org/struts/browse/SHALE-68.
Gary
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click)
Oh, I totally missed the point. Best of luck. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 1:21 PM To: Struts Users Mailing List Subject: Re: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) hmmm that isn't going to solve my issue. I don't want the button disabled on reload. I only want it to be disabled from the time the user clicked the button, until the time the server is able to send back a response. Here is an example: On a login form... enter username and pwd and click the submit button. While the server is processing the login form (the IE globe is spinning) the button becomes disabled so that the user can't resubmit the same login form. I'm more curious about how setting a DOM property on a element would change the way it is handled on the server side. Thanks for the try though, Jason On 5/11/06, James Reynolds [EMAIL PROTECTED] wrote: The first thought that occurs to me is, how about binding the button's JSF 'disabled' attribute to a boolean property on your backing bean? As part of the button's action method, you could set the boolean to true, thereby disabling the button when the page reloads. -Original Message- From: Jason Vincent [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 10:42 AM To: user@struts.apache.org Subject: Shale: onclick=disabled='true'; not calling Action Method. (stopping double click) Hi all, My project spec is asking me to disable form buttons once they are clicked. It seemed easy to me, just add onclick=disabled='true' to the commandButton. But as anything I've found with JSF, it isn't that easy. When I do this, the action method isn't being called after it passes validation. If I remove the onclick attribute, the form works fine; so I know it isn't a logic failure in the ViewController. I noticed that JSF inserts some of its own onclick logic to the button too. So I thought I'd try to disable the button by using the onsubmit attribute of the form tag. This also had the same behavior. What is going on here? Is disabling the button changing the submitted request parameters? Thanks all, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale/JSF] Frustrating Navigation Quirk
My problem deals with navigation between two pages, a Contract list page
and a Contract detail page. On the list page is a Boolean check box
that filters the list according to a certain criteria with a
ValueChangeListener. When the user click on a contract, the id of that
contract is sent as a parameter to the detail page. That parameter is
used in the init() method of the detail page's backing bean to load a
contract object and place it in session. All this works great.
The user can go back and forth between the list page and the detail page
*except* if the booleanCheckBox is clicked. Here is the sequence: The
user is viewing the detail page, then goes back to the list page _via
the back button of the browser_ (I suspect that's a key issue of the
problem), then the user clicks the booleanCheckBox. Instead of
filtering the list (and reloading the list page), the user is returned
to the detail page.
What I've done so far: My first thought was that the detail page was
still the most recent view because the user employed the browser's back
button to return the list. The ValueChangeListener method, wired to the
list page (and that bean is in session scope), changes a Boolean
property, then calls renderResponse(). That which would reload the
current view - which is the detail page, according to my thought
process.
To compensate for this, I placed additional code in the
ValueChangeListener that loaded the ViewId. If it didn't match my List
page ViewId, I set up the necessary code to navigate to the correct
ViewId. It didn't make any difference, so I'm not sure if my hypothesis
was correct.
I'm frankly stumped right now, so any advice would be appreciated. I'm
thinking that this must have something to do with the
ValueChangeListener, which I've listed below. Should I be adding
something else in there?
Thanks,
public void compOnlyChecked(ValueChangeEvent vce) {
compOnly = (Boolean) vce.getNewValue();
getFacesContext().renderResponse();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale/JSF] Frustrating Navigation Quirk
Thanks Gary,
I was stuck in ValueChange rut. Switching to a command link fixed the
problem and is much simpler.
Have a great day!
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Monday, May 08, 2006 12:03 PM
To: Struts Users Mailing List
Subject: Re: [Shale/JSF] Frustrating Navigation Quirk
From: James Reynolds [EMAIL PROTECTED]
My problem deals with navigation between two pages, a Contract list
page and a Contract detail page. On the list page is a Boolean check
box that filters the list according to a certain criteria with a
ValueChangeListener. When the user click on a contract, the id of that
contract is sent as a parameter to the detail page. That parameter is
used in the init() method of the detail page's backing bean to load a
contract object and place it in session. All this works great.
The user can go back and forth between the list page and the detail
page
*except* if the booleanCheckBox is clicked. Here is the sequence: The
user is viewing the detail page, then goes back to the list page _via
the back button of the browser_ (I suspect that's a key issue of the
problem), then the user clicks the booleanCheckBox. Instead of
filtering the list (and reloading the list page), the user is returned
to the detail page.
What I've done so far: My first thought was that the detail page was
still the most recent view because the user employed the browser's
back button to return the list. The ValueChangeListener method, wired
to the list page (and that bean is in session scope), changes a
Boolean property, then calls renderResponse(). That which would reload
the current view - which is the detail page, according to my thought
process.
To compensate for this, I placed additional code in the
ValueChangeListener that loaded the ViewId. If it didn't match my List
page ViewId, I set up the necessary code to navigate to the correct
ViewId. It didn't make any difference, so I'm not sure if my
hypothesis was correct.
I'm frankly stumped right now, so any advice would be appreciated. I'm
thinking that this must have something to do with the
ValueChangeListener, which I've listed below. Should I be adding
something else in there?
It seems like you are trying to use the ValueChangeListener for
navigation
instead of for state management. The action method binding on a command
component is where you would want to place the conditional navigation
rules.
Could you set the boolean flag in the ValueChangeListener that an action
method would use to determine the correct navigation path? The action
binding would be hooked to the command you are using to submit the page.
From the action, you could look at the boolean value a choose a logical
outcome. Something like:
public String filterList() {
if (wasCheckBoxChanged)
return showList;
else
return showDetail;
}
navigation-rule
from-view-id/list.jsp/from-view-id
navigation-case
from-outcomeshowDetail/from-outcome
to-view-id/detail.jsp/to-view-id
/navigation-case
navigation-case
from-outcomeshowList/from-outcome
to-view-id/list.jsp/to-view-id
/navigation-case
/navigation-rule
Gary
Thanks,
public void compOnlyChecked(ValueChangeEvent vce) {
compOnly = (Boolean) vce.getNewValue();
getFacesContext().renderResponse();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Starting out with JDBCTemplate
A previous question to this list resulted in many recommendations to use Spring's JDBCTemplate (among other fine alternatives) to connect to my database. It looks like an attractive solution for me so I've been wading through a plethora of material. There are so many tutorials and a wealth of information available, but they all incorporate many many features of Spring that I'm not ready to tackle yet. I'm having trouble discerning which configuration pieces are really necessary just to use JDBCTemplate. I'm asking this group because I'm using JSF/Shale and I'm not sure how my choice of framework will affect the Spring configuration. Could you tell me the minimum pieces I need to assemble to employ JDBCTemplate? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] AbstractViewController for Dummies
My understanding of the JSF lifecycle is a bit tenuous. As a result, I'm confused about the proper use of init(), preprocess(), and prerender(). Thus far, I've just been using init() and destroy() to handle the creation and closing of Connections and other minor duties because they have just worked for what I needed. Now, I'm moving on with some more complex pages and I want to be sure that I'm leveraging the AbstractViewController for all it's worth. The documentation does a good job of explaining when and under what conditions the events are fired, however, my weakness is that I just don't know what kind of jsf programming events to stuff in each one. If I have a component that uses select items (that don't live in the application or session scopes), should I build them in init() or prerender()? These are the kinds of questions I wrestle with. An actual issue that I'm working through now is this: I have a page that lists 'Contracts'. If the user clicks one, the plan is to navigate to a detail page, with the Contract's id number stored in the parameter map. The detail page's backing bean needs to instantiate a Contract object based on the id value, but do I do that in the bean constructor, the init() or the prerender() methods? Any advice would be appreciated. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] AbstractViewController for Dummies
I printed your answer and hung it on my cubical wall, where it will continue to help me in the future. 24k gold, Thank you! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, April 24, 2006 4:03 PM To: Struts Users Mailing List Subject: Re: [Shale] AbstractViewController for Dummies On 4/24/06, James Reynolds [EMAIL PROTECTED] wrote: My understanding of the JSF lifecycle is a bit tenuous. As a result, I'm confused about the proper use of init(), preprocess(), and prerender(). Thus far, I've just been using init() and destroy() to handle the creation and closing of Connections and other minor duties because they have just worked for what I needed. Now, I'm moving on with some more complex pages and I want to be sure that I'm leveraging the AbstractViewController for all it's worth. The documentation does a good job of explaining when and under what conditions the events are fired, however, my weakness is that I just don't know what kind of jsf programming events to stuff in each one. If I have a component that uses select items (that don't live in the application or session scopes), should I build them in init() or prerender()? These are the kinds of questions I wrestle with. That's a really useful question to help you understand the differences. The short answer is either of these will technically work. Some help, huh :-). But there is an important difference in behavior that can help you choose. * The init() method is *always* called if this view controller is ever instantiated. * The prerender() method is *only* called if the corresponding view is actually going to be rendered. If you have navigated to some different page, the prerender() method on *that* page's view controller will be called instead of this one. That can save you from having to do a bunch of expensive database queries that you do not need. So, one way to look at what event method should be used for what kind of application logic is to consider the following two questions: (1) Do I need the results of this computation in order to process a form submit? (2) Do I need the results of this computation in order to render the page? Based on the anaswers, I would suggest sorting things out like this: * Use init() for (1) and (2) * Use preprocess() for (1) only * Use prerender for (2) only And, you can always put any necessary cleanup code in destroy(). So, what's the answer for the use case you just described? It turns out that init() is actually the correct answer -- because when you the form for this view, the UISelectOne or UISelectMany component performs validation on the input value(s) against the set of select items that are defined. If you are not storing the items in session or application scope, then you will need to reload them in order for these validations to not fail. On the other hand, if you *did* have the select items in session or application scope, then you could move the logic to prerender() and only spend the effort to accumulate the items list the first time it is rendered. An actual issue that I'm working through now is this: I have a page that lists 'Contracts'. If the user clicks one, the plan is to navigate to a detail page, with the Contract's id number stored in the parameter map. The detail page's backing bean needs to instantiate a Contract object based on the id value, but do I do that in the bean constructor, the init() or the prerender() methods? Does the detail page itself have a form that can be submitted back in again? If so, then init() would be the right place -- by the same logic as above (you need it for both form processing and rendering). If the page just has navigation links, prerender() would work. Any advice would be appreciated. Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale/JSF] Can I redirect/forward in the init() method?
I want to test a value in session, then redirect or forward to a different view based on the result. I tried using getExternalContext().redirect(/theOtherPage.jsp); but I received an exception stating that I cannot redirect after the request is committed. What's the proper way to do this? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale/JSF] Can I redirect/forward in the init() method?
That's doing it. Thank you! -Original Message- From: Richard Wallace [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 3:17 PM To: Struts Users Mailing List Subject: Re: [Shale/JSF] Can I redirect/forward in the init() method? James Reynolds wrote: I want to test a value in session, then redirect or forward to a different view based on the result. I tried using getExternalContext().redirect(/theOtherPage.jsp); but I received an exception stating that I cannot redirect after the request is committed. What's the proper way to do this? Try using getExternalContext ().dispatch (viewId); That should forward to the page you want. Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] When to create a database Connection?
I'm getting a null pointer error in my backing bean. My grand plan was
to create a Connection in the init() method extended from the
AbstractViewController, so it can be used by any number of methods and
getters in my bean, and then close it in destroy().
In this simple case, the only place this Connection is used is in a
getter that returns a Result for a dataTable. However, it doesn't seem
to be working as I get a null pointer exception. If I move the
getConnection() method out of the init() method and into this getter,
then everything works great.
Am I miss-using the init() method?
Import lots.of.stuff;
public class Testimonial extends AbstractViewController {
private Connection conn = null;
public Testimonial(){
}
public void init() {
try {
conn = DbConnection.getConnection();
System.out.println();
} catch (SQLException e) {
e.printStackTrace();
}
}
public void destroy() {
try {
if (!conn.isClosed()) {
conn.close();
}
} catch (SQLException sqle) {
log(sqle.getMessage(), sqle);
sqle.printStackTrace();
}
}
public Result getAllTestimonials() {
/* ### moving the conn = DbConnection.getConnection() here
solves the problem ### */
Result result = null;
PreparedStatement ps = null;
try {
ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS);
result = ResultSupport.toResult(ps.executeQuery());
} catch (SQLException sqle) {
System.out.println(SQL Exception: + sqle.getMessage());
sqle.printStackTrace();
} catch (Exception e) {
System.out.println(Exception: + e.getMessage());
e.printStackTrace();
} finally {
try {
if (ps != null) {
ps.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
return result;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] When to create a database Connection?
Never mind, I mis-spelled the bean name in the Faces-Config. Oh the
shame :(
-Original Message-
From: James Reynolds [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 29, 2006 10:33 AM
To: Struts Users Mailing List
Subject: [Shale] When to create a database Connection?
I'm getting a null pointer error in my backing bean. My grand plan was
to create a Connection in the init() method extended from the
AbstractViewController, so it can be used by any number of methods and
getters in my bean, and then close it in destroy().
In this simple case, the only place this Connection is used is in a
getter that returns a Result for a dataTable. However, it doesn't seem
to be working as I get a null pointer exception. If I move the
getConnection() method out of the init() method and into this getter,
then everything works great.
Am I miss-using the init() method?
Import lots.of.stuff;
public class Testimonial extends AbstractViewController {
private Connection conn = null;
public Testimonial(){
}
public void init() {
try {
conn = DbConnection.getConnection();
System.out.println();
} catch (SQLException e) {
e.printStackTrace();
}
}
public void destroy() {
try {
if (!conn.isClosed()) {
conn.close();
}
} catch (SQLException sqle) {
log(sqle.getMessage(), sqle);
sqle.printStackTrace();
}
}
public Result getAllTestimonials() {
/* ### moving the conn = DbConnection.getConnection() here
solves the problem ### */
Result result = null;
PreparedStatement ps = null;
try {
ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS);
result = ResultSupport.toResult(ps.executeQuery());
} catch (SQLException sqle) {
System.out.println(SQL Exception: + sqle.getMessage());
sqle.printStackTrace();
} catch (Exception e) {
System.out.println(Exception: + e.getMessage());
e.printStackTrace();
} finally {
try {
if (ps != null) {
ps.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
return result;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] When to create a database Connection?
Hi Hermod,
Here's my reason whineI'm under pressure to get this project complete
so I'm reluctant to take on learning Hibernate and Spring at this
time./whine There's no question that would be a better way to do it,
but (as you can probably tell) I'm not an expert programmer.
Maybe my assumption is invalid, how challenging are these technologies
for new comers?
Thanks
-Original Message-
From: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 29, 2006 11:45 AM
To: 'Struts Users Mailing List'
Subject: SV: [Shale] When to create a database Connection?
Hi
Give me one good reason as to why you are doing this. If you let
existing tools do the job for you, you are going to relieve your self of
a lot of trouble. Have a look at Hibernate or equivalent, combined with
Spring.
What you are doing here is really is something of the past.
Hermod
-Opprinnelig melding-
Fra: James Reynolds [mailto:[EMAIL PROTECTED]
Sendt: 29. mars 2006 19:33
Til: Struts Users Mailing List
Emne: [Shale] When to create a database Connection?
I'm getting a null pointer error in my backing bean. My grand plan was
to create a Connection in the init() method extended from the
AbstractViewController, so it can be used by any number of methods and
getters in my bean, and then close it in destroy().
In this simple case, the only place this Connection is used is in a
getter that returns a Result for a dataTable. However, it doesn't seem
to be working as I get a null pointer exception. If I move the
getConnection() method out of the init() method and into this getter,
then everything works great.
Am I miss-using the init() method?
Import lots.of.stuff;
public class Testimonial extends AbstractViewController {
private Connection conn = null;
public Testimonial(){
}
public void init() {
try {
conn = DbConnection.getConnection();
System.out.println();
} catch (SQLException e) {
e.printStackTrace();
}
}
public void destroy() {
try {
if (!conn.isClosed()) {
conn.close();
}
} catch (SQLException sqle) {
log(sqle.getMessage(), sqle);
sqle.printStackTrace();
}
}
public Result getAllTestimonials() {
/* ### moving the conn = DbConnection.getConnection() here
solves the problem ### */
Result result = null;
PreparedStatement ps = null;
try {
ps = conn.prepareStatement(SqlStatements.ALL_TESITIMONIALS);
result = ResultSupport.toResult(ps.executeQuery());
} catch (SQLException sqle) {
System.out.println(SQL Exception: + sqle.getMessage());
sqle.printStackTrace();
} catch (Exception e) {
System.out.println(Exception: + e.getMessage());
e.printStackTrace();
} finally {
try {
if (ps != null) {
ps.close();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
return result;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Getting the JSF Session Started
I'm having to click twice to get a session started. I based my app on the Shale-blank code, which includes an index.jsp file which contains a jsp:forward tag to welcome.jsf to, as I understand it, get a session started in the framework. However, I still need to click twice on command buttons or command links to get any action. Should I be using a more thorough method to ensure a session begins? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Getting the JSF Session Started
Ah, I was barking up the wrong tree again :) Thanks for the suggestion. I do have a messages component on my page and I'm not seeing any errors. However, I have not implemented a backing bean for this first page (no real need for it yet) so I am seeing the corresponding warnings in the console. That wouldn't play any part would it? Also, I do have many navigation commandLinks with the immediate attribute set to true in order to bypass the required fields in the login section of the page. I've read in some posts that it might be desirable to set up the navigation as a result of ActionEvent rather than the action. Is that true, or am I misinterpreting what I've read? Thanks again! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 4:04 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds [EMAIL PROTECTED] wrote: I'm having to click twice to get a session started. I based my app on the Shale-blank code, which includes an index.jsp file which contains a jsp:forward tag to welcome.jsf to, as I understand it, get a session started in the framework. JSF itself doesn't start the session -- in this particular application, the session is created as a side effect of executing the index.jsp page ... JSP pages always create a session (if it does not exist) unless you declare that you do not want one. So why the forward in this case? Because some containers do not correctly support a welcome file name of welcome.jsf where there is no actual resource in the webapp at that location. However, I still need to click twice on command buttons or command links to get any action. Should I be using a more thorough method to ensure a session begins? Without seeing your code, it's difficult to determine what might be causing the behavior you are seeing, but it seems unlikely to me that session existence has an impact. One thing to check, though, is if your page is triggering a validation error somehow -- unless you have an h:message or h:messages component on your page, to show the messages when the page gets redisplayed, this can be a bit puzzling to JSF newcomers. Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Getting the JSF Session Started
(Oh I hope there's nothing stupid here)
%@ taglib prefix=f uri=http://java.sun.com/jsf/core; %
%@ taglib prefix=h uri=http://java.sun.com/jsf/html; %
%@ taglib prefix=t uri=http://myfaces.apache.org/tomahawk; %
%@ taglib uri=http://java.sun.com/jstl/core; prefix=c %
f:view
%@ include file=messages.jspf %
html
head
titleh:outputText value=#{std.title}//title
t:stylesheet path=/resources/standard.css/
script type=text/javascript src=resources/js.js/script
head
body
t:htmlTag value=div id=container forceId=true
f:subview id=header
c:import url=includes/header.jspx/
/f:subview
t:htmlTag value=div styleClass=content
div id=news
h:form
h1NPP News/h1
h5h:outputText value=#{std['welcome.base.h1']}//h5
ph:outputText value=#{std['welcome.base.p1'] }/
h:outputLink value=http://www.ctconsulting.com/nppsignup.php;
target=_blank
onmouseover=self.status = 'Web Seminars'; return
true;
onmouseout=self.status = ''; return true;
h:outputText value=click here/
/h:outputLink/p
hr/
h5h:outputText value=#{std['welcome.base.h2']}//h5
ph:outputText value=#{std['welcome.base.p2']} /
h:commandLink action=go_nppRegister value=click here
onmouseover=self.status = 'Register'; return
true;
onmouseout=self.status = ''; return true;
immediate=true//p
hr/
h5h:outputText value=#{std['welcome.base.h3']}//h5
ph:outputText value=#{std['welcome.base.p3']} /
!--todo: code this action--
h:commandLink action= value=click here
onmouseover=self.status = 'Mission, Goals
Purpose'; return true;
onmouseout=self.status = ''; return true;
immediate=true//p
hr/
h2Plus/h2
h3* * */h3
!--todo: code this action--
h3h:commandLink value=About Membership
action= immediate=true
onmouseover=self.status = 'About Membership';
return true;
onmouseout=self.status = ''; return
true;//h3
h3h:outputLink value=http://www.myplacetolearn.com/;
target=_blank
h:outputText value=NPP E-Learning Center/
/h:outputLink/h3
!--todo: code this action--
h3h:commandLink value=Vendor Applications
action= immediate=true
onmouseover=self.status = 'Vendor Applications';
return true;
onmouseout=self.status = ''; return
true;//h3
h3h:commandLink value=Testimonials
action=go_testimonials immediate=true
onmouseover=self.status = 'Testimonials'; return
true;
onmouseout=self.status = ''; return
true;//h3
h4nbsp;/h4
/div
/h:form
t:htmlTag value=div
h1
h:outputText value=#{std['welcome.h1']}/
/h1
p
h:outputText value=#{std['welcome.p1']}/
/p
/t:htmlTag
t:htmlTag value=div
p
h:outputText value=#{std['welcome.p2']}/
/p
p
h:outputText value=#{std['welcome.p3']}/
/p
p
h:outputText value=#{std['welcome.p4']} /
h:outputLink value=mailto:[EMAIL PROTECTED]
h:outputText value=[EMAIL PROTECTED]/
/h:outputLink
/p
/t:htmlTag
/t:htmlTag
f:subview id=footer
c:import url=includes/footer.jspx/
/f:subview
/t:htmlTag
/body
/html
/f:view
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Tuesday, March 28, 2006 4:39 PM
To: Struts Users Mailing List
Subject: Re: [Shale] Getting the JSF Session Started
On 3/28/06, James Reynolds [EMAIL PROTECTED] wrote:
Ah, I was barking up the wrong tree again :)
Thanks for the suggestion. I do have a messages component on my page
and I'm not seeing any errors. However, I have not implemented a
backing bean for this first page (no real need for it yet) so I am
seeing the corresponding warnings in the console. That wouldn't play
any part would it?
You mean the warning about not finding a view controller? No, that's
not part of the picture ... indeed, if you pick up tonight's nightly
build that log message has been demoted from a warning to a debug
message -- it's perfectly legal to not use view controllers.
Also, I do have many navigation commandLinks with the immediate
attribute set to true in order to bypass the required fields in the
login section of the page. I've read in some posts that it might be
desirable to set up the navigation as a result of ActionEvent rather
than the action. Is that true, or am I misinterpreting what I've
read?
I've read the same ... but don't necessarily agree :-). I use immediate
for either navigation buttons, or for a cancel button.
It'd be helptul to see some code on your JSP page to help figure out
what's really going on.
Thanks again!
Craig
-Original
RE: [Shale] Getting the JSF Session Started
Thanks so much for taking the time to do this. Actually, I do have outputLinks and commandLinks inside the same form sound of scrambling to the JSF books is that bad practice? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 5:12 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds [EMAIL PROTECTED] wrote: (Oh I hope there's nothing stupid here) Nothing obvious stands out (I presume that the std thing is loaded in messages.jspx?). When I run into scenarios like that, I try to get to the simplest possible case first (say, a form with a command link and an output link embedded inside) in it, and see that work, before fleshing it back out again. (Also, of course, check the servlet container logs for any errors.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Getting the JSF Session Started
Oh, OK. Thanks again, I'm going back under the hood :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 5:33 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds [EMAIL PROTECTED] wrote: Thanks so much for taking the time to do this. Actually, I do have outputLinks and commandLinks inside the same form sound of scrambling to the JSF books is that bad practice? No, that's fine ... I'm just suggesting that temporarily creating a 10 line JSP page without all the extra stuff might help illuminate where the problems are. Craig -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Tuesday, March 28, 2006 5:12 PM To: Struts Users Mailing List Subject: Re: [Shale] Getting the JSF Session Started On 3/28/06, James Reynolds [EMAIL PROTECTED] wrote: (Oh I hope there's nothing stupid here) Nothing obvious stands out (I presume that the std thing is loaded in messages.jspx?). When I run into scenarios like that, I try to get to the simplest possible case first (say, a form with a command link and an output link embedded inside) in it, and see that work, before fleshing it back out again. (Also, of course, check the servlet container logs for any errors.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] jsp vs. jspx
As part of converting my app from vanilla faces to Shale, I decided to convert my jsp files to jspx for two reasons. First, to prevent someone else from employing scriplets in the future and, second, because I've read that it's a good idea (maybe I've been reading all the wrong stuff). Now I'm running into some newbie problems getting jspx pages to display correctly so I'm starting to second guess myself. Is there any advantage one way or the other as far as Shale is concerned? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [FRIDAY] Re: has struts reached the saturation
Ted, Craig and everyone else, Thanks so much for your dedication and support to these projects. The advice I've received on this list has been a life-saver and has helped me immensely in my career. Your contributions are greatly appreciated. Sincerely, The silent majority - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale]/jsf Referencing a component
I'm enjoying the helper methods extended from the AbstractViewController and I'd like to send a message to a particular component. For example, here's the slick error() method. protected void error(javax.faces.component.UIComponent component, java.lang.String summary) I'm not sure how to reference the desired component. Can I refer to the component with its ID? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale]/jsf Referencing a component
Works like a charm! I used the binding method and now I'm off and
running.
Thanks!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Thursday, March 16, 2006 1:42 PM
To: Struts Users Mailing List
Subject: Re: [Shale]/jsf Referencing a component
On 3/16/06, James Reynolds [EMAIL PROTECTED] wrote:
I'm enjoying the helper methods extended from the
AbstractViewController and I'd like to send a message to a particular
component.
Good idea :-).
For example,
here's the slick error() method.
protected void error(javax.faces.component.UIComponent component,
java.lang.String summary)
I'm not sure how to reference the desired component. Can I refer to
the component with its ID?
You can't use a component identifier, because the method signature
quoted above requires a component *instance*. There are two reasonable
approaches to how you can acquire such a component reference.
* Use the UIComponent.findComponent() method, perhaps on the
root UIViewRoot component, to find the component instance for
the specified client id. NOTE -- the Proposed Final Draft 2 version
of the JSF 1.2 spec has added an additional related option here.
* Use the binding attribute on your JSP tag to attach the component
instance into your backing bean. The most common use case I've had
for this is when you want to implement pagination on a table component
(but the same principle applies to the question you are asking).
Consider
a component with the following JSP custom tag:
h:dataTable ... binding=#{mybean.table} .../
In the backing bean class referenced by the managed bean name
mybean, you need to define a property for the component itself,
as opposed to its value:
private HtmlDataTable table = null;
public HtmlDataTable getTable() { return this.table; }
public void setTable(HtmlDataTable table) { this.table = table; }
Using the latter approach, any event handler method in the same backing
bean has direct access to the component instance -- without even having
to know its id. The same sort of approach can be used to expose
component instances needed for the first parameter to methods like
error().
If you think, on the other hand, that we should also support passing a
string (the client id) instead of the component instance, please file an
RFE in the issue tracking system:
http://issues.apache.org/bugzilla/
Under product Struts and category Shale.
Thanks
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Creating my Managed Bean template
I'm about to set up a template file for managed-beans and I was planning on inserting the methods supported by the ViewController interface. My question is, does it hurt to have empty ViewController methods in the bean if I'm not using them? If, for some reason, I'm not using the init() method, should I remove it from the file to avoid confusing Shale? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Shale] Creating my Managed Bean template
I get it. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, March 13, 2006 3:30 PM To: Struts Users Mailing List Subject: Re: [Shale] Creating my Managed Bean template On 3/13/06, James Reynolds [EMAIL PROTECTED] wrote: I'm about to set up a template file for managed-beans and I was planning on inserting the methods supported by the ViewController interface. My question is, does it hurt to have empty ViewController methods in the bean if I'm not using them? If, for some reason, I'm not using the init() method, should I remove it from the file to avoid confusing Shale? If your backing bean implements ViewController then you are going to be *required* to implement all the methods (even if they are empty) to avoid compile errors. The simplest thing to do is extends AbstractViewController. Besides the fact that this class implements (as empty methods) all the callbacks, so you only have to override the ones you care about, it also offers you a bunch of useful helper methods too. Thanks Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: Shale Container Managed Security
Thank you Craig, that's very helpful to understand. There are two things I was hoping to accomplish with Container Managed Security. 1. Ensuring that a user is logged in before serving up protected pages. I believe this is handled easily by using a Servlet Filter to check for a required session object (like username), similar to the example provided by Kito Mann in JSF in Action. 2. Protecting certain parts of the site based on a user's role. This is where I'm having difficulty. Among Shale/JSF programmers, is there a popular/best practice for implementing this requirement? Any advice would be appreciated. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Friday, March 03, 2006 4:52 PM To: Struts Users Mailing List Subject: Re: Shale Container Managed Security On 3/3/06, James Reynolds [EMAIL PROTECTED] wrote: Allow me to refine my question. I'm wondering if the Shale filter is intercepting requests to the container. Do I need to adjust the filter mapping? Is there an FM somewhere that I should R? Shale's filters do indeed intercept whatever requests it is mapped to, but there are two important things to understand with respect to container managed security: * Container managed security is applied *before* any filters (including the one that Shale provides). * Container managed security is applied *only* on the initial request, not on RequestDispatcher.forward() calls. In JSF (and therefore Shale) apps, that means you can protect the incoming form submits (they will be mapped to something like /editCustomer.jsf if you are using extension mapping, and the page being submitted was /editCustomer.jsp). The second issue means that it is your application's responsibility to decide whether or not the user should be allowed to navigate to a particular page. Container managed security won't help you there. That being said, it might be interesting for Shale to deliver a custom JSF navigation handler that would optionally impose that sort of control (only a manager can navigate to the salary details page). Craig -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 3:02 PM To: Struts Users Mailing List Subject: Shale Container Managed Security I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale Container Managed Security
If you are using J2EE container managed security, why not use the standard declarative security constraint on a url-pattern? You then assign roles to the constraint and to groups and/or users. Gary Thanks Gary, Maybe I'm misunderstanding Craig's response (below). Perhaps he is referring to page-by-page control, while you are referring to a url pattern that encompasses all contents of a folder (/members_only/*). Is that the subtle difference here? Shale's filters do indeed intercept whatever requests it is mapped to, but there are two important things to understand with respect to container managed security: * Container managed security is applied *before* any filters (including the one that Shale provides). * Container managed security is applied *only* on the initial request, not on RequestDispatcher.forward() calls. In JSF (and therefore Shale) apps, that means you can protect the incoming form submits (they will be mapped to something like /editCustomer.jsf if you are using extension mapping, and the page being submitted was /editCustomer.jsp). The second issue means that it is your application's responsibility to decide whether or not the user should be allowed to navigate to a particular page. Container managed security won't help you there. That being said, it might be interesting for Shale to deliver a custom JSF navigation handler that would optionally impose that sort of control (only a manager can navigate to the salary details page). Craig -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 3:02 PM To: Struts Users Mailing List Subject: Shale Container Managed Security I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale Container Managed Security
Now I get it completely (I'm still getting up to speed on a lot of this). Thanks! -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 1:26 PM To: Struts Users Mailing List Subject: RE: [OT] RE: Shale Container Managed Security From: James Reynolds [EMAIL PROTECTED] If you are using J2EE container managed security, why not use the standard declarative security constraint on a url-pattern? You then assign roles to the constraint and to groups and/or users. Gary Thanks Gary, Maybe I'm misunderstanding Craig's response (below). Perhaps he is referring to page-by-page control, while you are referring to a url pattern that encompasses all contents of a folder (/members_only/*). Is that the subtle difference here? Oh, right. I guess you would also have to use redirects instead of forwards for navigation since the forwards are trusted. navigation-case from-outcomeviewSalary/from-outcome to-view-id/secured/viewSalary.faces/to-view-id redirect/ /navigation-case You could also add programmatic checks in your action methods to return outcomes based on security. Gary Shale's filters do indeed intercept whatever requests it is mapped to, but there are two important things to understand with respect to container managed security: * Container managed security is applied *before* any filters (including the one that Shale provides). * Container managed security is applied *only* on the initial request, not on RequestDispatcher.forward() calls. In JSF (and therefore Shale) apps, that means you can protect the incoming form submits (they will be mapped to something like /editCustomer.jsf if you are using extension mapping, and the page being submitted was /editCustomer.jsp). The second issue means that it is your application's responsibility to decide whether or not the user should be allowed to navigate to a particular page. Container managed security won't help you there. That being said, it might be interesting for Shale to deliver a custom JSF navigation handler that would optionally impose that sort of control (only a manager can navigate to the salary details page). Craig -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 3:02 PM To: Struts Users Mailing List Subject: Shale Container Managed Security I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] RE: Shale Container Managed Security
There is a subtle but important issue. Container managed security only operates on the original URL to which a GET or POST was directed ... it does *not* apply to RequestDispatcher.forward() calls. In JSF terms, that means you can protect the form submit, but it is up to the application to decide whether or not navigation to a particular page is allowed. The RFE being discussed here could do something like a custom navigation handler with a pluggable strategy for choosing whether or not navigation (according to the navigation rules) is actually going to be permitted or not. One implementation of this strategy could be based on user roles, but you could also do something more fine grained or context sensitive (since the strategy implementation would have access to FacesContext, it can do whatever it needs). Craig I think I understand: if I use an action method to forward a user to a different page based on its String name in my Faces-Config.xml, I'm basically employing RequestDispatcher.forward(), which circumvents the container managed security. Did I get it? In theory, couldn't I set a role property for each page in its managed-bean element and then conditionally render the page, or redirect elsewhere, based on my user's role stored in session? If so, should this evaluation take place in the init() method of every page's bean, or is there a better way to handle it globally? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale Navigation Error
I've set up a very basic web app (running on tomcat 5.5.15) based on the Shale-blank.war I downloaded on 3/1/06. It compiles and runs, but if I navigate to a page, it throws the error listed below. I found some messages in the mail archives that described a similar problem that related to Spring integration. I've since removed any jars that appeared to be Spring related, but it still throws the error. Any ideas? Thanks exception javax.servlet.ServletException: No WebApplicationContext found: no ContextLoaderListener registered? javax.faces.webapp.FacesServlet.service(FacesServlet.java:121) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) root cause java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered? org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationC ontext(FacesContextUtils.java:78) org.springframework.web.jsf.DelegatingVariableResolver.getWebApplication Context(DelegatingVariableResolver.java:134) org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(D elegatingVariableResolver.java:112) org.apache.shale.spring.WebApplicationContextVariableResolver.resolveVar iable(WebApplicationContextVariableResolver.java:87) org.apache.shale.view.faces.ViewViewHandler.setupViewController(ViewView Handler.java:233) org.apache.shale.view.faces.ViewViewHandler.createView(ViewViewHandler.j ava:126) org.apache.shale.tiles.TilesViewHandler.createView(TilesViewHandler.java :184) org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(Na vigationHandlerImpl.java:145) org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(D ialogNavigationHandler.java:193) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionLi stenerImpl.java:84) javax.faces.component.UICommand.broadcast(UICommand.java:106) javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164) org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleIm pl.java:316) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86 ) javax.faces.webapp.FacesServlet.service(FacesServlet.java:106) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale Navigation Error
Never mind. NetBeans is somehow adding the Spring jars back in when I build the project. Manually removing them fixed the problem and it's navigating now. -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 9:55 AM To: user@struts.apache.org Subject: Shale Navigation Error I've set up a very basic web app (running on tomcat 5.5.15) based on the Shale-blank.war I downloaded on 3/1/06. It compiles and runs, but if I navigate to a page, it throws the error listed below. I found some messages in the mail archives that described a similar problem that related to Spring integration. I've since removed any jars that appeared to be Spring related, but it still throws the error. Any ideas? Thanks exception javax.servlet.ServletException: No WebApplicationContext found: no ContextLoaderListener registered? javax.faces.webapp.FacesServlet.service(FacesServlet.java:121) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) root cause java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered? org.springframework.web.jsf.FacesContextUtils.getRequiredWebApplicationC ontext(FacesContextUtils.java:78) org.springframework.web.jsf.DelegatingVariableResolver.getWebApplication Context(DelegatingVariableResolver.java:134) org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(D elegatingVariableResolver.java:112) org.apache.shale.spring.WebApplicationContextVariableResolver.resolveVar iable(WebApplicationContextVariableResolver.java:87) org.apache.shale.view.faces.ViewViewHandler.setupViewController(ViewView Handler.java:233) org.apache.shale.view.faces.ViewViewHandler.createView(ViewViewHandler.j ava:126) org.apache.shale.tiles.TilesViewHandler.createView(TilesViewHandler.java :184) org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(Na vigationHandlerImpl.java:145) org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(D ialogNavigationHandler.java:193) org.apache.myfaces.application.ActionListenerImpl.processAction(ActionLi stenerImpl.java:84) javax.faces.component.UICommand.broadcast(UICommand.java:106) javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164) org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleIm pl.java:316) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86 ) javax.faces.webapp.FacesServlet.service(FacesServlet.java:106) org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationF ilter.java:285) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(Extensi onsFilter.java:122) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale Container Managed Security
I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shale Container Managed Security
Allow me to refine my question. I'm wondering if the Shale filter is intercepting requests to the container. Do I need to adjust the filter mapping? Is there an FM somewhere that I should R? -Original Message- From: James Reynolds [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 3:02 PM To: Struts Users Mailing List Subject: Shale Container Managed Security I'm a newbie setting up container managed security for a basic Shale-blank application. For my first attempt, I'm trying a simple BASIC authentication but I'm having troubles so I'm trying to rule out the unknowns. My question for this list is, does Shale have an impact on traditional Container Managed Security Methods? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
