SCXML - onError event, custom ExcpetionHandler?
Hi. Got some question. onError events at scxml level are reported by the SimpleErrorReporter. Is there a way in shale, to plug in other ExceptionHandling classes? I thought something about onError as xml element. onTransition, onEntry and onExit are also interesting. First one is the more important. For now, every exception thrown in action states (failed initalizations etc. pp) are catched and the real cause is not reported. I want to plug in some ErrorHandling class which does take the Exception - redirect to a defined error page and exits the dialog wich is currently in progress. Is this possible with current implementation, or something else near that? Torsten smime.p7s Description: S/MIME cryptographic signature
JSF: SERVLET calling a jsf/jsp page from one context to another
Hi,
I have two directory named d1,d2 inside my tomcat container . and inside d1,
there is page a.jsp and inside d2 there is page b.jsp . so i want to call
b.jsp from a.jsp page , i have given a link for calling b.jsp in a.jsp as
h:commandLink action=''#{fwd.forward} value=CALL
where fwd is name of managed bean and forward is method inside managed bean.
like this
class Forward
{
public String forward()
{
return String jforum;
}
can anybody help me resolving the issue.
Thanks
Ratnesh Pd. Sirvastava
V2Solutions India
--
View this message in context:
http://www.nabble.com/JSF%3A-SERVLET-calling-a-jsf-jsp-page-from-one-context-to-another-tf3680135.html#a10284554
Sent from the Shale - User mailing list archive at Nabble.com.
Re: SV: Dialog SCXML Data class - Setter injection, ViewController etc. pp.
On 4/29/07, Torsten Krah [EMAIL PROTECTED] wrote: No - i want to migrate to spring later - and some things are spring already through a DelegatigVariableResolver from SWF. But i am not using the shale-spring integration. But the question is - is it possible to have this without springs IoC Container, but using the facility provided through JSF, or shale. snip/ There isn't a (built-in) way to declaratively wire things to the dialog data ATM: * The dialog data exists its the dialog (pseudo) scope i.e. its instantiation (and disposal) is managed by the dialog implementation in use, rather than the JSF impl. * I'd say the intended primary purpose of the dialog data is meant to capture the interaction with the user in a given instance of a dialog, so I personally haven't given much thought to DI in this context. * Finally, it might be possible to leverage certain listener callbacks to procedurally manage some of the (simpler) dependencies, say on DCL#onActivate(). -Rahul Torsten Am Sonntag, den 29.04.2007, 14:24 +0200 schrieb Hermod Opstvedt: Hi Are you using the Shale-spring integration? Hermod -Opprinnelig melding- Fra: Torsten Krah [mailto:[EMAIL PROTECTED] Sendt: 29. april 2007 12:08 Til: user@shale.apache.org Emne: Dialog SCXML Data class - Setter injection, ViewController etc. pp. The configured data class is not managed trough the bean facility - am i right? However, it would be nice to have things like setter injection view controller for this data class too. Is there already a good way there yet to do this? Torsten
Re: SCXML - onError event, custom ExcpetionHandler?
On 5/2/07, Torsten Krah [EMAIL PROTECTED] wrote:
Hi.
Got some question.
onError events at scxml level are reported by the SimpleErrorReporter.
Is there a way in shale, to plug in other ExceptionHandling classes?
I thought something about onError as xml element.
onTransition, onEntry and onExit are also interesting.
First one is the more important.
For now, every exception thrown in action states (failed initalizations
etc. pp) are catched and the real cause is not reported.
snip/
As an aside (I'll adress the main question below) -- I can look into
improving the error reporting. I'm traveling (without access to a dev
box) for a couple of weeks more, so if you want to file a JIRA ticket,
this will stay on the radar. Might require changes to the Commons
library, if it is the one not bubbling the real cause.
I want to plug in some ErrorHandling class which does take the Exception
- redirect to a defined error page and exits the dialog wich is
currently in progress.
Is this possible with current implementation, or something else near
that?
snap/
No, but I agree it should be. As you're probably aware, the dialog
implementations have maintained the DialogContext abstraction (the DC
impls are package private). However, there are a bunch of services
that the Commons SCXML impl has the ability to provide, which are
currently shielded behind the abstraction (note that
on{Entry,Transition,Exit} you mention above are exposed). There are a
couple of avenues going forward:
1) Continue to maintain this abstraction, in which case additional
vocabulary would need to be added to the SCXML dialog-config.xml DTD.
2) Make the SCXMLDialogContext public such that knowing that an
application is using SCXML dialogs, it will be possible to cast to an
implementation specific API (which can then expose the underlying
SCXMLExecutor, and all the Commons SCXML APIs that provide additional
functionality).
As much as the first one is cleaner, I/we will probably loathe having
to maintain another involved vocabulary for the dialog-config (and
perhaps so will those having to use it). Similarly, while the second
one will provide an all access card at the expense of an
implementation specific cast, it also implies greater responsibility
since direct interactions with the SCXMLExecutor are getting at the
heart of the mechanics of the dialog execution itself.
Opinions welcome.
-Rahul
Torsten
Re: [validator] possible bug in validator script generation for child comp. inside not rendered parent comp.
From: Hasan Turksoy [EMAIL PROTECTED]
hi all,
it seems there is a buggy case at validator script generation(at
findCommonsValidators method to be exact).. issue is; when i use a component
inside another parent component(that's NOT RENDERED), it's still generating
validator scripts for my child component.. this causes script errors when i
submitted my page... Because, there is a validation script exists for a not
rendered(because parent's not rendered) component.
To visualize;
// child components won't be rendered
because parent's not rendered
client=true /
as seen above, my textbox(txt_name) won't be rendered since it's parent
won't be rendered.. But client validator scripts are still being generated
for this field. This causes javascript errors at form submit...
Should we enter an issue for this case?
Please create a JIRA ticket for this one. Thanks!
Below is a test method for the case; (necessary methods already in jar's
test package)
/*---*/
public void testScriptNotGeneratedForComponentsInsideNotRenderedParent()
throws Exception {
// find the view root
UIViewRoot root = facesContext.getViewRoot();
assertNotNull(root);
UINamingContainer namingContainer = (UINamingContainer)
application.createComponent(javax.faces.NamingContainer);
namingContainer.setId(root.createUniqueId());
root.getChildren().add(root.getChildCount(), namingContainer);
//create a form 1
UIComponent form1 = this.createForm(test1, namingContainer);
//create a dummy parent panel component
HtmlPanelBox panelbox = createPanelBox(pnl_name, form1);
//create a dummy component 1
HtmlInputText component1 = createInputText(txt_name, panelbox);
//create a required field/server rule
CommonsValidator validator1 = createValidator(component1,
required, null);
//create a script component
ValidatorScript script = createValidatorScript(root);
// render the javascript for the form
StringBuffer htmlSnippet = encode(script);
System.out.println(htmlSnippet.toString());
// search tokens to test for in the javascript
String[] searchTokens = {
test1_required(),
this[0] = new Array(\test1:txt_name\);
};
// none of search tokens exist..
checkScriptForNotExist(htmlSnippet, searchTokens);
}
private void checkScriptForNotExist(StringBuffer htmlSnippet, String[]
searchTokens) {
for (int i = 0; i searchTokens.length; i++) {
Assert.assertFalse(Found: + searchTokens[i], (
htmlSnippet.indexOf(searchTokens[i]) != -1));
}
}
/*---*/
hope the issue is clear enough...
best regards,
Hasan...
AJAX and shale (sub)dialog
Hi, What I have is a floating dojo ContentPane (popup) that loads its content though AJAX. What I wish to achieve is for this ContentPane to handle multiple requests/responses without interfering with the underlying view state of the actual non-AJAX jsf page. From what I understand JSF can solve this by using a phaseListner, but shale's (sub)dialog seems to be stronger and better suited for the job. As I'm new to this area I might be off and wrong here. Before I start coding away and solve the problems I run into, I would love to see some examples or documentation laying out how this can be done elegantly. Can anyone point me in the right direction? Regards, Joost
Re: AJAX and shale (sub)dialog
On 5/2/07, JS Portal Support [EMAIL PROTECTED] wrote: Hi, What I have is a floating dojo ContentPane (popup) that loads its content though AJAX. What I wish to achieve is for this ContentPane to handle multiple requests/responses without interfering with the underlying view state of the actual non-AJAX jsf page. From what I understand JSF can solve this by using a phaseListner, but shale's (sub)dialog seems to be stronger and better suited for the job. As I'm new to this area I might be off and wrong here. Before I start coding away and solve the problems I run into, I would love to see some examples or documentation laying out how this can be done elegantly. Can anyone point me in the right direction? The dialog support will work nicely for you if you want the content of the popup to itself be composed with JSF components. Because the popup is an independent window, it has its own component tree independent of the main page, and goes through its own lifecycle separately. The dialog system even knows how to have separate dialogs in progress in each window without getting confused. There are samples of how to start such popups in the shale-test-dialog-basic and shale-test-dialog-scxml sample apps. In your case, however, it sounds like you want to let Dojo deal with the UI in the popup, and just need a way to provide the back end services for the Ajax callbacks. For that use case, I would also take a look at using Shale Remoting for the callbacks. Among other things, this will let you map a request URL (originated by an XMLHttpRequest from the client) directly to a public method on a particular managed bean. These requests do not have a component tree of their own (and they don't affect the component tree for the main view). The point here is to let you leverage the non-UI server side features of JSF (particularly managed beans and EL evaluation) for Ajax callbacks. Besides the documentation on the Shale Remoting page itself, this technique was used inside the Autocomplete Text Field component in the Blueprints Catalog[1], which can serve as a pretty good coding example for use within an application as well. Craig [1] https://bpcatalog.dev.java.net/ Regards, Joost
RE: AJAX and shale (sub)dialog
Craig, First off, thanks for your elaborate explanation. I believe I'm slowly starting to get a better grasp of all subtleties involved. Remoting seems great for a situation where only one call to the server needs to be made without state saving. - Is it possible to make a remoting call to a regular *.jsf page which may contain commandLink's and other jsf components? As for the ContentPane I must apologize as by popup I did not mean a new window, but a floating div acting as a dojo ContentPane (see attachement). - In this situation, is it possible to start a subdialog from the floating ConetntPane without affecting the underlying page? Thanks, Joost -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, May 03, 2007 1:52 PM To: user@shale.apache.org Subject: Re: AJAX and shale (sub)dialog On 5/2/07, JS Portal Support [EMAIL PROTECTED] wrote: Hi, What I have is a floating dojo ContentPane (popup) that loads its content though AJAX. What I wish to achieve is for this ContentPane to handle multiple requests/responses without interfering with the underlying view state of the actual non-AJAX jsf page. From what I understand JSF can solve this by using a phaseListner, but shale's (sub)dialog seems to be stronger and better suited for the job. As I'm new to this area I might be off and wrong here. Before I start coding away and solve the problems I run into, I would love to see some examples or documentation laying out how this can be done elegantly. Can anyone point me in the right direction? The dialog support will work nicely for you if you want the content of the popup to itself be composed with JSF components. Because the popup is an independent window, it has its own component tree independent of the main page, and goes through its own lifecycle separately. The dialog system even knows how to have separate dialogs in progress in each window without getting confused. There are samples of how to start such popups in the shale-test-dialog-basic and shale-test-dialog-scxml sample apps. In your case, however, it sounds like you want to let Dojo deal with the UI in the popup, and just need a way to provide the back end services for the Ajax callbacks. For that use case, I would also take a look at using Shale Remoting for the callbacks. Among other things, this will let you map a request URL (originated by an XMLHttpRequest from the client) directly to a public method on a particular managed bean. These requests do not have a component tree of their own (and they don't affect the component tree for the main view). The point here is to let you leverage the non-UI server side features of JSF (particularly managed beans and EL evaluation) for Ajax callbacks. Besides the documentation on the Shale Remoting page itself, this technique was used inside the Autocomplete Text Field component in the Blueprints Catalog[1], which can serve as a pretty good coding example for use within an application as well. Craig [1] https://bpcatalog.dev.java.net/ Regards, Joost
Re: AJAX and shale (sub)dialog
On 5/2/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, First off, thanks for your elaborate explanation. I believe I'm slowly starting to get a better grasp of all subtleties involved. Remoting seems great for a situation where only one call to the server needs to be made without state saving. - Is it possible to make a remoting call to a regular *.jsf page which may contain commandLink's and other jsf components? As for the ContentPane I must apologize as by popup I did not mean a new window, but a floating div acting as a dojo ContentPane (see attachement). - In this situation, is it possible to start a subdialog from the floating ConetntPane without affecting the underlying page? The mailing list blocks most attachments, so I didn't see what you attached ... but Shale Dialogs has two restrictions to be aware of: * Only one active dialog per window or frame. If the Dojo ContentPane used an IFrame, this might not be a problem, but if it is just a div that is getting dynamically updated, then this won't work. * Shale Dialog assumes that the popup UI is actually composed with JSF components. Since that is not the case here, it seems like Remoting might be a better solution. Craig Thanks, Joost -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, May 03, 2007 1:52 PM To: user@shale.apache.org Subject: Re: AJAX and shale (sub)dialog On 5/2/07, JS Portal Support [EMAIL PROTECTED] wrote: Hi, What I have is a floating dojo ContentPane (popup) that loads its content though AJAX. What I wish to achieve is for this ContentPane to handle multiple requests/responses without interfering with the underlying view state of the actual non-AJAX jsf page. From what I understand JSF can solve this by using a phaseListner, but shale's (sub)dialog seems to be stronger and better suited for the job. As I'm new to this area I might be off and wrong here. Before I start coding away and solve the problems I run into, I would love to see some examples or documentation laying out how this can be done elegantly. Can anyone point me in the right direction? The dialog support will work nicely for you if you want the content of the popup to itself be composed with JSF components. Because the popup is an independent window, it has its own component tree independent of the main page, and goes through its own lifecycle separately. The dialog system even knows how to have separate dialogs in progress in each window without getting confused. There are samples of how to start such popups in the shale-test-dialog-basic and shale-test-dialog-scxml sample apps. In your case, however, it sounds like you want to let Dojo deal with the UI in the popup, and just need a way to provide the back end services for the Ajax callbacks. For that use case, I would also take a look at using Shale Remoting for the callbacks. Among other things, this will let you map a request URL (originated by an XMLHttpRequest from the client) directly to a public method on a particular managed bean. These requests do not have a component tree of their own (and they don't affect the component tree for the main view). The point here is to let you leverage the non-UI server side features of JSF (particularly managed beans and EL evaluation) for Ajax callbacks. Besides the documentation on the Shale Remoting page itself, this technique was used inside the Autocomplete Text Field component in the Blueprints Catalog[1], which can serve as a pretty good coding example for use within an application as well. Craig [1] https://bpcatalog.dev.java.net/ Regards, Joost
