Re: Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)
Gary VanMatre wrote: -- Original message -- From: Paul Spencer <[EMAIL PROTECTED]> Gary VanMatre wrote: Spencer <[EMAIL PROTECTED]> Humm, it looks like the shale test pom has a 1.4 profile that excludes the JSF 1.2 objects. The 1.1 trunk has the same type of profile. Unless I'm mistaken, we would need two deployments for JSF 1.1 and 1.2. Is this what "classifiers" are for? I see their is are profiles for jdk 1.4, 1.5, and 1.6. 1.4 is for Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5. Based on this I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and one for JSF 1.2 ( profile = shale-test-jdk15) Yeah, sounds like that's the ticket but it's the first I've heard of classifiers. Maybe one of our maven mavens could give some pointers on how to configure a dual deployment. Do you think we would need two maven projects? Any other apache projects doing this that we could borrow snippets? I have asked a related question on the Maven user list with the subject "Are classifiers the answer, are they mature, what are the pitfalls?"[1] As to other project using classifiers, I do not know :( Paul Spencer Gary Paul Spencer [1] http://markmail.org/message/l6v3nbnb6qwrdduy
Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)
Gary VanMatre wrote: -- Original message -- From: Paul Spencer <[EMAIL PROTECTED]> Gary VanMatre wrote: -- Original message -- From: Paul Spencer <[EMAIL PROTECTED]> Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x. Their may be components that are JSF version specific, but this is the exception. I agree but the shale test library for 1.1.x supports JSF 1.2 mock objects which means it has Java 1.5 & JSF 1.2 dependencies. The rest of the libraries are still JSF 1.1 based. So SHALE-262 - "Provide optional support for parsing faces-config.xml files in the classpath at startup time" will need to be backported to 1.0.x to test a JSF 1.1 application, like Tomahawk? Are their other alternatives the backporting? Humm, it looks like the shale test pom has a 1.4 profile that excludes the JSF 1.2 objects. The 1.1 trunk has the same type of profile. Unless I'm mistaken, we would need two deployments for JSF 1.1 and 1.2. Is this what "classifiers" are for? I see their is are profiles for jdk 1.4, 1.5, and 1.6. 1.4 is for Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5. Based on this I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and one for JSF 1.2 ( profile = shale-test-jdk15) Paul Spencer Gary Paul Spencer
Re: Where is Shale1.1.0?
Gary VanMatre wrote: -- Original message -- From: Paul Spencer <[EMAIL PROTECTED]> Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x. Their may be components that are JSF version specific, but this is the exception. I agree but the shale test library for 1.1.x supports JSF 1.2 mock objects which means it has Java 1.5 & JSF 1.2 dependencies. The rest of the libraries are still JSF 1.1 based. So SHALE-262 - "Provide optional support for parsing faces-config.xml files in the classpath at startup time" will need to be backported to 1.0.x to test a JSF 1.1 application, like Tomahawk? Are their other alternatives the backporting? Paul Spencer
Re: Where is Shale1.1.0?
Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x. Their may be components that are JSF version specific, but this is the exception. Paul Spencer Greg Reddin wrote: On Fri, Jun 6, 2008 at 2:49 AM, Mario Buonopane <[EMAIL PROTECTED]> wrote: No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 but with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1). What does mean "GA" codebase? I don't remember if JSF 1.2 is a requirement for Shale 1.1 or not. ISTR us deciding we would target JSF 1.2 but I don't think that introduces backwards incompatibility. GA means General Availability - basically a production release. Shale 1.0.4 is alpha quality because of dependencies on unreleased libraries. Greg
Re: Statistic
Sam, I use Shale Dialog in some customer projects. The Shale test framework is also used in MyFaces. Paul Spencer samju wrote: I just want to check how many user, Companies, etc. are using Shale. thanks For your feedback in advance! Sam
Re: Shale Status
Bernhard, I suggest you post this to the developer's list. Paul Spencer Bernhard Slominski wrote: Hi all, I make a small presentation about Shale in the JSF Days in Vienna, for that I'd like to have some information about the current status of Shale. I just went through the maillist, but it's a bit difficult to find hard facts. So my questions are the following - Next Shale relaese Right now there is no plan for a Shale 1.0.5 release right? Corresponding thread: http://markmail.org/message/nagpn7igxeowjtx6?q=org%2Eapache%2Eshale%2Edev - What goes where? There was this thread: http://markmail.org/message/3ws5fzthj2yfdjjp?q=org%2Eapache%2Eshale%2Edev+list:org%2Eapache%2Eshale%2Edev But there was no final decision on what goes where, so is it still open, or is there a decision? - Shale itsself Will it disappear as an Apache Top Level project? Cheers Bernhard
How to handle links outside a SCXML Dialog?
I am having an issued when users click links that are not known to the SCXML dialog. When this occurs an exception from ShaleApplicationFilter.doFilter() is thrown. The links are part of the page's headers, footer, and navigation bar. The expected behavior when the user click one of the links, like "Home", is the dialog will be closed and the desired page will be displayed. How do I support links that are outside the dialog without adding each possible link to each dialog? Paul Spencer
Re: h:outputFormat ignores escape="false" (Might be MyFaces)
Ian, See http://issues.apache.org/jira/browse/MYFACES-1396 Paul Spencer Ian.Priest wrote: My h:outputFormat tag is ignoring it's escape="false" attribute. My HTML is below. Can someone sanity check for me please! xmlns:t="http://myfaces.apache.org/tomahawk"; xmlns:h="http://java.sun.com/jsf/html"; xmlns:f="http://java.sun.com/jsf/core";> value="[EMAIL PROTECTED]" var="call" styleClass="call" > ... The value of @managed-bean-name.currencySymbol is "£", but it gets escaped to "£" by the formatter despite the escape="false". Any ideas anyone? (Am cross-posting this to the myfaces list too). Cheers, Ian.
Re: Shale 1.0.3 - init() method not called on ViewController bean
Costa, Their is an introduced bug in 1.0.4. See https://issues.apache.org/struts/browse/SHALE-409 I am using 1.0.4 because SCXML dialogs are needed. Paul Spencer Costa Basil wrote: My mistake. I didn't define org.apache.shale.view.faces.LifecycleListener as listener in web.xml. Now it works, but it is called twice... Anyway, the other question remains, is the upgrade 1.0.3 -> 1.0.4 flawless? What worries me are subtle side-effects that are hard to find... Costa Basil <[EMAIL PROTECTED]> wrote: Hi: I have a request backing bean class that extends AbstractViewController and overrides the init() method. I noticed the init method is not called, however the preprocess and prerender methods are called. Is this normal? I am using Shale 1.0.3 which begs the next question: How hard is to upgrade to Shale 1.0.4, that is am I to expect lots of issues? I have a big application I am reluctant to upgrade. I am using only the core, remoting and the validation modules. Thanks - Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail - Ask a question on any topic and get answers from real people. Go to Yahoo! Answers.
Re: How to use ConfigParser()?
I found the problem. The test was using a Tomahawk component. Since the ConfigParser does not load Tomahawk's JSF configuration, the render was not defined. My concerns around the absents of FacesContext where unfounded because the context is not need when adding renderers. Paul Spencer Paul Spencer wrote: I am trying to convert a test utility method that adds renders and other JSF components to the ConfigParser in 1.1.0-SNAPSHOT, but I getting nulls from context.getRenderKit().getRenderer(...) I have added the following in the utility method, which is NOT in an class that extends any of the shale abstract test classes. The method is called by the test's setUp() after super.setUp(). ConfigParser parser = new ConfigParser(); URL[] urls = parser.getPlatformURLs(); parser.parse(urls); Where the prior addRender() method passed FacesContext, I am not passing it to the ConfigParser. Is this the problem? See the addDefaultRenderers() method in the test utility class [1] for a more complete example. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup
How to use ConfigParser()?
I am trying to convert a test utility method that adds renders and other JSF components to the ConfigParser in 1.1.0-SNAPSHOT, but I getting nulls from context.getRenderKit().getRenderer(...) I have added the following in the utility method, which is NOT in an class that extends any of the shale abstract test classes. The method is called by the test's setUp() after super.setUp(). ConfigParser parser = new ConfigParser(); URL[] urls = parser.getPlatformURLs(); parser.parse(urls); Where the prior addRender() method passed FacesContext, I am not passing it to the ConfigParser. Is this the problem? See the addDefaultRenderers() method in the test utility class [1] for a more complete example. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup
Re: Beginning a dialog (basic dialog manager) with V1.0.3
Jan, Add a slash to the viewId. viewId="/Dienststellensuche.jsp" Paul Spencer [EMAIL PROTECTED] wrote: Hello ! When trying to begin a dialog with V1.0.3 (basic dialog manager) with the "dialog:" prefix in an action, I get: java.lang.IllegalArgumentException: You have requested a transition outcome named "dialog:Dienststellensuche" from a state named "Dienststellenliste" in a dialog named "Dienststellensuche", but no transition definition can be found. Double check the spelling of the transition outcome name. Any hints? jsp: dialog-config.xml: Jan K.
Re: URL to a dialog?
Craig, The doc just ways add the the parameter the the url, it does not say what the URL should be. The following URL does work http://foo.com/myApp/index.jsf?org.apache.shale.dialog.DIALOG_NAME=interview 1) The name of the page, index.jsf, is required but not appear to be used because the dialog is called and the page, index.jsf, is not displayed. 2) Is this a security hole? Specifically some of my dialogs are called from protected pages This allows the dialog to be called directly. In case where the first state is an action state, then action is not protected unless the action protects itself! Paul Spencer Craig McClanahan wrote: On 2/5/07, Paul Spencer <[EMAIL PROTECTED]> wrote: Shale 1.0.3+ I would like to start a dialog from a URL instead of an action. If the dialog is named "interview" and the base URL is foo.com/myApp, what is URL? In 1.0.4 there actually is a way to do this ... add a request parameter named "*org.apache.shale.dialog.DIALOG_NAME" that contains the name of the dialog you wish to start. See the "Starting a DialogContext via URL Parameters" section of the web docs[1] for more information on the options.* Paul Spencer Craig [1] http://shale.apache.org/shale-dialog/
URL to a dialog?
Shale 1.0.3+ I would like to start a dialog from a URL instead of an action. If the dialog is named "interview" and the base URL is foo.com/myApp, what is URL? Paul Spencer
Re: which IDE are you using for JSF ?
Adrian, I use Eclipse with MyEclipse. As to you need for "drag and drop and autocompletion for EL expressions and tags", that will be a challenge. MyEclipse does offer some autocompete and validation, but when you are using new release of MyFaces/Shale/... taglibs the IDE can lag behind. Paul Spencer Adrian Gonzalez wrote: Hello, Is there a good IDE (drag and drop and autocompletion for EL expressions and tags) for facelets or Clay technology ? What IDE are you using to create JSF apps ? My current purpose is to see if one can use JSF for mainstream development (developers with little experience in Java / web technologies), so drag & drop, autocompletion would be a must - the company has currently developed ~100 web apps. Seeking advice on the trinidad user list, I've been given pointers to use facelets or shale Clay, to really AVOID JSP for rendering, and to ask to this mailing list (thanks Gary for the tip !), since there's a lot of knowledgeable people (such as Ryan Wynn ;)). I'm just using IBM RAD 6, and it's quite difficult (ibm proprietary components, JSF 1.0, JSP...) - I've integrated myfaces on it, simulating dummy ibm components - since IBM's are tied to SUN RI, but it's doesn't appear to be a good solution even if it's working. Thanks P.S. sorry this question is not really a Shale question ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Need help with SCXML transition cond syntax.
Rahul,
Works as expected. You may mark the issue as resolved.
Thanks again.
Paul Spencer
Rahul Akolkar wrote:
On 1/30/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Version 1.1.0-SNAPSHOT
Could you try an updated snap, one thats post this issue:
http://issues.apache.org/struts/browse/SHALE-403
-Rahul
I would like a transition to be selected when a bean's field is not
empty. If the field is
an empty string, "", or null I do not want the transition executed.
Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
Paul Spencer
Re: Need help with SCXML transition cond syntax.
Rahul, Rahul Akolkar wrote: Bah, OK, it seems I missed one todo in code, about three lines needed to tie the application variable resolver to the Commons SCXML context for greater EL capabilities (such as this, arbitrary expressions beyond simply calling action state MBEs etc). Could you file a JIRA issue for this? Thanks! In any case, I intend to get to this later this afternoon, so there will be one soon enough. https://issues.apache.org/struts/browse/SHALE-404 -Rahul Thank you for you help on this. Paul Spencer
Re: Need help with SCXML transition cond syntax.
Rahul,
See below.
Rahul Akolkar wrote:
On 1/31/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2
if the
property Leased is checked on the page1, otherwise go to page2.
Neither is happening!
When the cancel button is clicked, the transition to menu works as
expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
The target of a element cannot be determined at runtime
(if we think of this in terms of a state chart diagrams, when we start
to draw a transition we need to also know the "end point/state", can't
have it TBD amongst some candidates) -- a slight exception is
(but thats OT, see SCXML WD or Commons SCXML test suite /
site for semantics).
But another way to look at this is that we simply have compound
conditional expressions, i.e. the one above whose target
we're trying to determine using conditionals () is conceptually
equivalent to the two s below (untested):
My previous configuration was simply a summary of my attempts. Although I my
first attempt matches your suggestion, I did not included it in the example.
Below is the configuration you suggested. I suspect that SCXML is not getting
the properties from dialog.data because the value of dialog.data.leased is
always
false.
***
* Value of dialog.data fields
***
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next' and dialog.data.leased} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next' and not dialog.data.leased} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [review]
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Can you point me to an example of this?
Other observations probably relevant here:
* Generally, all outbound transitions from a view state should be
guarded by the "faces.outcome" event (or they may be followed
immediately if the cond is satisfied)
This is good to know.
* The latest SCXML WD [1] (Jan '06) has removed the element
(though the 0.x line of Commons SCXML supports it for backwards
compatibility). It is recommended to use the target attribute of
instead (and once thats done, it becomes hard to provide
more than one based on some conditional logic anyway). The SCXML
examples in the Shale test app use the newer variants of any such spec
changes.
I only used in an attempt to get the transition working. I was
using an example from Commons SCXML's wiki.
* Upto v0.6 of Commons SCXML, the conds are expected to be mutually
exclusive (no two -- or more -- should evaluate to true at the same
time in a given scenario). That will lead to non-determinism, and the
related error being reported. I think the spec may talk about document
order priorities in the next rev.
This matches my expectations. I only had two potentially evaluating to
true for debugging and testing. Once in production only 1 transition will
evaluate to true.
-Rahul
Paul Spencer
Re: Need help with SCXML transition cond syntax.
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2 if the
property Leased is checked on the page1, otherwise go to page2. Neither is
happening!
When the cancel button is clicked, the transition to menu works as expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next'} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialogData.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.lease} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.leased eq 'true'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [page1]
Paul Spencer
Rahul Akolkar wrote:
On 1/30/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Version 1.1.0-SNAPSHOT
I would like a transition to be selected when a bean's field is not
empty. If the field is
an empty string, "", or null I do not want the transition executed.
Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
${not empty dialogData.companyId}
The SCXML implementation often doesn't have the liberty of knowing
anything about the expression based on the location of the expression
within the document (though cond attribute values are expected to
evaluate to booleans, in this particular case).
The evaluator Javadoc is here [1], and lists some relevant details.
-Rahul
[1]
http://shale.apache.org/shale-dialog-scxml/apidocs/org/apache/shale/dialog/scxml/ShaleDialogELEvaluator.html
Paul Spencer
Need help with SCXML transition cond syntax.
Version 1.1.0-SNAPSHOT
I would like a transition to be selected when a bean's field is not empty. If
the field is
an empty string, "", or null I do not want the transition executed. Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
Paul Spencer
Re: How to end a SCXML dialog in an action?
Rahul,
I was using 1.0.4. When I switch to 1.1.0-SNAPSHOT, it worked.
Paul Spencer
Rahul Akolkar wrote:
On 1/26/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul,
I an getting the following when I click on the home link. It appears
that the dialog
is still running even though it was stopped.
Couldn't spot anything so dropped your code snippets into the
shale-test-dialog-scxml app. Works for me, recipe below:
1) Used SessionManagerBean and the snippet, both verbatim
from below (snippet placed at the bottom of wizardpage1.jsp in the
test app above)
2) faces-config additions:
sessionManager
org.apache.shale.examples.test.dialog.scxml.SessionManagerBean
session
/*
#{sessionManager.gotoHome}
home
/menu.jsp
Then clicking on "Home" takes me to the test app home page (menu.jsp)
after stopping the active dialog.
-Rahul
***
* Stack Trace
***
ServletRequestAttributeAdded(org.apache.myfaces.config.beansUnderConstruction,[])
stop(id=1, name=addVendor)
remove(Removed DialogContext instance with ID '1'
handleNavigation(context='[EMAIL PROTECTED]',
fromAction='#{sessionManager.gotoHome}', outcome='home')
Dialog instance '1' for dialog name 'addVendor' has not yet been started
java.lang.IllegalStateException: Dialog instance '1' for dialog name
'addVendor' has not yet been started
at
org.apache.shale.dialog.scxml.SCXMLDialogContext.advance(SCXMLDialogContext.java:316)
at
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:139)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84)
at
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
at
org.apache.shale.view.faces.ShaleViewRoot.processApplication(ShaleViewRoot.java:40)
at
org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:343)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
***
* From the managed bean
***
public class SessionManagerBean
{
public String gotoHome()
{
stopActiveDialogIfAny(FacesContext.getCurrentInstance());
return "home";
}
private void stopActiveDialogIfAny(FacesContext facesContext)
{
DialogContext dcontext = (DialogContext)
facesContext.getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
if (dcontext != null)
{
dcontext.stop(facesContext);
}
}
}
**
* Form the view
***
Paul Spencer
Re: How to end a SCXML dialog in an action?
Rahul,
I an getting the following when I click on the home link. It appears that the
dialog
is still running even though it was stopped.
***
* Stack Trace
***
ServletRequestAttributeAdded(org.apache.myfaces.config.beansUnderConstruction,[])
stop(id=1, name=addVendor)
remove(Removed DialogContext instance with ID '1'
handleNavigation(context='[EMAIL PROTECTED]',
fromAction='#{sessionManager.gotoHome}', outcome='home')
Dialog instance '1' for dialog name 'addVendor' has not yet been started
java.lang.IllegalStateException: Dialog instance '1' for dialog name
'addVendor' has not yet been started
at
org.apache.shale.dialog.scxml.SCXMLDialogContext.advance(SCXMLDialogContext.java:316)
at
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:139)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84)
at
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
at
org.apache.shale.view.faces.ShaleViewRoot.processApplication(ShaleViewRoot.java:40)
at
org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:343)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
***
* From the managed bean
***
public class SessionManagerBean
{
public String gotoHome()
{
stopActiveDialogIfAny(FacesContext.getCurrentInstance());
return "home";
}
private void stopActiveDialogIfAny(FacesContext facesContext)
{
DialogContext dcontext = (DialogContext)
facesContext.getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
if (dcontext != null)
{
dcontext.stop(facesContext);
}
}
}
**
* Form the view
***
Paul Spencer
Rahul Akolkar wrote:
On 1/26/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Rahul Akolkar wrote:
>
> As mentioned above, that would be inside the method called by the MB,
> if at all we wanted to stop an active dialog and delegate to the
> faces-config navigation.
>
What is the name of the method, or where do I configure it, that is
called when the outcome, does is not configured?
In the above example page's header/footer define the outcomes "home",
"logout", and "menu". These outcomes are currently handled by
faces-config.xml, and I agree with your statement about avoiding the
modeling of "global" site navigation in each dialog.
Lets say outcome "home" is actually a commandLink, so simplistically:
This, by itself, would mess with an active dialog. Instead:
would ensure that we clean up correctly if there is an active dialog,
where:
// In the managed bean "globals" --
public String home() {
stopActiveDialogIfAny(); // the two lines of code from before
return "home"; // faces-config nav rules takes over here
}
Similarly for "logout" and "menu". Also may want to check with user
via onclick or suitable event handlers before wiping out the dialog.
-Rahul
Re: How to end a SCXML dialog in an action?
Rahul Akolkar wrote: On 1/25/07, Paul Spencer <[EMAIL PROTECTED]> wrote: Thanks for taking time to draw this out, heres the body of the untested addVendor.xml file (I've folded most of the view IDs into the state IDs but its possible to use custom action if we don't want to): http://www.w3.org/2005/07/scxml"; version="1.0" xmlns:shale="http://shale.apache.org/dialog-scxml"; initialstate="editVendor_1"> Note that we did not use faces-config navigation here, which is probably for the good since the entire page flow for this task is now captured in this model. Where does the code you mentioned below go and how is it called? As mentioned above, that would be inside the method called by the MB, if at all we wanted to stop an active dialog and delegate to the faces-config navigation. What is the name of the method, or where do I configure it, that is called when the outcome, does is not configured? In the above example page's header/footer define the outcomes "home", "logout", and "menu". These outcomes are currently handled by faces-config.xml, and I agree with your statement about avoiding the modeling of "global" site navigation in each dialog. -Rahul Paul Spencer
Re: How to display exception thrown by beans during a dialog?
Rahul,
So, if I want to display information from the exception to the user:
1) I need to maintain the exception in the bean, #{venderDialog}.
2) The view displaying the exception would reference a property in the
bean, #{venderDialog.caughtException}?
public class VendorDialog
{
private Exception caughtException;
// ..
public String setup() { // no throws clause
// ...
try {
// line(s) that can throw NotConfiguredException
} catch (NotConfiguredException nce) {
caughtException = nce;
return "notconfigured";
}
// ...
return "success";
}
Exception getCaughtException()
{
return caughtException;
}
}
Thank you,
Paul Spencer
Rahul Akolkar wrote:
On 1/26/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
I would like to display exception thrown by a managed bean during a
dialog to the user. How do I configure this?
As example:
vendorDialog.setup() can throw a NotConfiguredException.
1) I want to show this to the user.
2) I would also like to define the view that will display the exception.
3) In the above view, what is the bean/variable containing the thrown
exception?
An exception out of a MBE execution is merely yet another logical
outcome for the dialog state machine and should be treated as such.
IMO, introducing Java exception specific constructs into the dialog
description is a bit of a leaky abstraction since it muddys up the
modeling layer and state machine code generation etc. (for those who
care about that). So, for the simplest case, I would author the setup
method like so:
public String setup() { // no throws clause
// ...
try {
// line(s) that can throw NotConfiguredException
} catch (NotConfiguredException nce) {
return "notconfigured";
}
// ...
return "success";
}
whereby the flow markup is:
Note that by returning the NotConfiguredException as a logical outcome
we did lose actual Throwable instance (which might hold needed
information), but:
(a) Its arguable whether we need to display things like the trace to the
user
(b) We can always use dialog data to hold on to that bit, if its
needed by the subsequent view etc.
-Rahul
Paul Spencer
How to display exception thrown by beans during a dialog?
I would like to display exception thrown by a managed bean during a dialog to the user. How do I configure this? As example: vendorDialog.setup() can throw a NotConfiguredException. 1) I want to show this to the user. 2) I would also like to define the view that will display the exception. 3) In the above view, what is the bean/variable containing the thrown exception? Paul Spencer
Re: How to end a SCXML dialog in an action?
Rahul,
I do not completely follow you answer.
Assume the following:
1) stateId = "start"
Display the view /editVendor_1
OutcomeNext state
---
successpage2
cancel end
2) stateId = "page2"
Display the view /editVendor_2
OutcomeNext state
---
successsave
cancel end
3) stateId = "save"
Execute the action #{vendorDialog.save}
OutcomeNext state
---
successend
failurestart
4) End state stateId = "end"
Execute the action #{vendorManager.listAllVendors}. faces-config.xml
will take over form here.
5) dialog-config.xml
6) Using Shale 1.0.4
What does the dialog's scxml file look like?
Where does the code you mentioned below go and how is it called?
Paul Spencer
Rahul Akolkar wrote:
On 1/25/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
I have a dialog that adds a vendor. If the dialog successfully add the
vendor, or the dialog is canceled, then I want to end the dialog with a
call to the action #{vendorManager.listAllVendors}. The view to display
upon the completion of the action is configured in faces-config.xml.
How to do I configure this ?
For v1.0.4, this requires a bit of knowledge of the internals (the
recent DialogHelper addition to trunk really simplifies this ;-).
Knowing that the active DialogContext is stored as a request-scoped
attribute with key Constants.CONTEXT_BEAN, its possible to end the
dialog like so:
DialogContext dcontext = (DialogContext)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
dcontext.stop();
You can guard the stop() with a not null and isActive() predicate, if
deemed necessary. The good thing is this will also do the necessary
book-keeping cleanup associated with the DialogContextManager for you.
Assumes the view displayed (via the faces-config nav rule) is not part
of any dialog at that point.
-Rahul
Paul Spencer
How to end a SCXML dialog in an action?
I have a dialog that adds a vendor. If the dialog successfully add the
vendor, or the dialog is canceled, then I want to end the dialog with a
call to the action #{vendorManager.listAllVendors}. The view to display
upon the completion of the action is configured in faces-config.xml.
How to do I configure this ?
Paul Spencer
Re: How to use request scoped manage beans in a 1.0.4 dialog?
Craig,
I embedded my comments.
Craig McClanahan wrote:
On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Craig,
I embedded my comments. They are near the end.
Paul Spencer
Craig McClanahan wrote:
> On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
>
>>
> o For simple dialogs only configuration changes should be required, the
>
>> implementation of a interface like DialogContextListener, should
not be
>> required. The default DialogContextListener implemention should do
the
>> "please save and restore this stuff for me" in
>> onActivate()/onDeactivate().
>
>
>
> Isn't the list of what request scope beans you want to save and restore
> going to be specific to each dialog definition? I agree that we should
> provide a listener implementation that does the work, but it will still
> need
> to be configured.
Yes, the list of beans is specific to a dialog.
Up to this point the beans have been request scope. What if the user
configures a session or application scope bean? On the face it seems the
save/restore process will be wasted work, but can/should a request a
request
scope bean be created? Thus the bean will have a request and
session/appliction set of
properties.
It is technically legal to have beans with the same name in different
scopes. The EL evaluation rules guarantee that the same order will be
followed (request, then session, then application), at least for expression
evaluation, so the results will be predictable.
I think your point about wasted work is key ... if you are already keeping
your state information in session or application scope, you do not *need*
this new mechanism, so you should keep on doing what you are doing. The
accesses to sesion and application scope data will still work inside the
dialog execution.
If the user wants to configure a session or application scopes bean, they
can and it will work.
Cool
> Separately but related, I'm thinking that the configuration information
> would be a set of zero or more value binding expressions. Saving the
state
> information would end up calling getValue() on these, and storing in
> session
> scope, while restoring will mean calling setValue() on the value
binding.
> This should work for request scope variables ... for an expression
> "#{foo}":
>
> * Caling getValue() will look up this variable in any scope ... thus
> will find it in session scope if it is there.
>
> * Calling setValue() will cause a new request scope variable to be
> created.
>
> Doing this lets us cover the simple case of entire attributes, but also
> gives the developer the freedom to save and restore properties of an
> existing scoped bean, instead of just scoped beans themselves.
>
> Also separately but related, it seems to me that someone using this
> approach
> would not need the "data" property of DialogContext explicitly. Thus,
we
> could offer a concrete implementation bean that does the save/restore
stuff
> for you, and is configured by setting a list of expressions. The
> DialogContext implementations already notice when the data class is a
> DialogContextListener, so adding the onActivate()/onDeactivate()
methods
to
> the event signature should be all the wiring we need. (This will make
more
> sense when I work out a concrete example ... but I think we can
dispense
> with modifying the configuration DTDs at all.)
1) Yes, the data property of DialogContext would not be needed.
2) I am not sure what you mean by "configured by setting a list
of expressions". The exact details around how the list of beans
to be saved/restored is configued can be detemined later.
Yah, I was kind of hand waving there :-). I've checked in the first steps
of the mechanism, and am working on a concrete class that illustrates
what I
was talking about here in code instead of words ... hopefully that will be
easier to understand.
I look forward to using it.
> o The user should be able to convert from a series of views that use a
>
>> session scoped bean to pass the data between views to a dialog using
>> request scoped bean with the following configuration changes:
>>1) Change the scope of the session bean to request.
>>2) Define the dialog
>>3) Update the actions to reference the dialog
>
>
>
> That makes a lot of sense, but I don't think step 3 is actually
required.
> As part of step 2, you will just need to make sure that you define
> transitions for all of the possible outcomes that the actions can
return,
> and you should not have to modify the actions themselves (or the pages
that
> used value binding expressions to the state data). That's a pretty
elegant
> migration path.
>
The actions will need to
Re: How to use request scoped manage beans in a 1.0.4 dialog?
Craig,
I embedded my comments. They are near the end.
Paul Spencer
Craig McClanahan wrote:
On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Craig,
I added my comments at the end.
Craig McClanahan wrote:
> On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
>>
>> I need to use an existing JSF page in a dialog. How to I tell the
1.0.4
>> Dialog manager which request scoped beans to maintain through out the
>> dialog?
>
>
> That is a really interesting idea. The reuse idea was one of the
original
> motivations for the approach we took in designing the dialog APIs, and
> making this possible without modifying the binding expressions used by
the
> page is a missing link in the current implementation.
>
> Is their a way to do this in the dialog configuration?
>>
>> I was hoping for something like:
>>
>>
>>
>>
>>
>>
>> All of the the views would have access to #{renamedBean} and
>> #{requestScopeBean2}
>
>
> The 1.0.4 mechansim for saving state does not directly support this use
> case. It expects you to store all of the dialog state information via
the
> "data" property of the DialogContext for the active dialog instance,
which
> is made available via the "dialogScope" pseudo-variable (which
partially
> addresses SHALE-184, but a real solution is going to require changes to
the
> JSF specification).
>
> It is feasible to implement adding a list of "please save and restore
this
> stuff for me" configuration, as you describe above, although I would
> want to
> look at whether we can make an SCXML based approach function similarly.
> Another strategy would be to add onActivate() and onDeactivate()
callbacks
> on DialogContextListener, so an application could perform its own
custom
> save and restore logic. For covering the common cases, we could
provide
a
> simple implementation that you configured with a bunch of VB
expressions
> (like your configuration example) and did the save/restore stuff. This
> way,
> we could add the functionality without having to get into the guts of
the
> dialog implementation on applications that do not need this service.
>
> What do you think?
>
o Implementation should work for all dialog implementations, basic and
scmxl.
Agreed.
o In the case of SCXML dialogs, the bean mapped, i.e. requestScopeBean1
is mapped to renamedBean in the my example, should not be part of the
scxmlconfig. This will allow the SCXML configuration to be reused in may
dialogs.
There are actually two configuration files for SCXML ... the one that
conforms to the SCXML definitions (which we cannot change), and the one
that
adds Shale-specific information (such as the name of the class to use for
the "data" object. We'd be able to modify that, if we wanted to pass the
configuration information in.
o For simple dialogs only configuration changes should be required, the
implementation of a interface like DialogContextListener, should not be
required. The default DialogContextListener implemention should do the
"please save and restore this stuff for me" in
onActivate()/onDeactivate().
Isn't the list of what request scope beans you want to save and restore
going to be specific to each dialog definition? I agree that we should
provide a listener implementation that does the work, but it will still
need
to be configured.
Yes, the list of beans is specific to a dialog.
Up to this point the beans have been request scope. What if the user
configures a session or application scope bean? On the face it seems the
save/restore process will be wasted work, but can/should a request a request
scope bean be created? Thus the bean will have a request and
session/appliction set of
properties.
Separately but related, I'm thinking that the configuration information
would be a set of zero or more value binding expressions. Saving the state
information would end up calling getValue() on these, and storing in
session
scope, while restoring will mean calling setValue() on the value binding.
This should work for request scope variables ... for an expression
"#{foo}":
* Caling getValue() will look up this variable in any scope ... thus
will find it in session scope if it is there.
* Calling setValue() will cause a new request scope variable to be
created.
Doing this lets us cover the simple case of entire attributes, but also
gives the developer the freedom to save and restore properties of an
existing scoped bean, instead of just scoped beans themselves.
Also separately but related, it seems to me that someone using this
approach
would not need the "data" property of DialogContext explicitly. Thus, we
could offer a concrete implementation bean th
How to use Dialogs and ?
I would like to start a dialog from a menu. The following does not appear to start the dialog: The following does start the dialog: Can the dialog be started from a ? How? Paul Spencer
Re: How to use request scoped manage beans in a 1.0.4 dialog?
Craig,
I added my comments at the end.
Craig McClanahan wrote:
On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
I need to use an existing JSF page in a dialog. How to I tell the 1.0.4
Dialog manager which request scoped beans to maintain through out the
dialog?
That is a really interesting idea. The reuse idea was one of the original
motivations for the approach we took in designing the dialog APIs, and
making this possible without modifying the binding expressions used by the
page is a missing link in the current implementation.
Is their a way to do this in the dialog configuration?
I was hoping for something like:
All of the the views would have access to #{renamedBean} and
#{requestScopeBean2}
The 1.0.4 mechansim for saving state does not directly support this use
case. It expects you to store all of the dialog state information via the
"data" property of the DialogContext for the active dialog instance, which
is made available via the "dialogScope" pseudo-variable (which partially
addresses SHALE-184, but a real solution is going to require changes to the
JSF specification).
It is feasible to implement adding a list of "please save and restore this
stuff for me" configuration, as you describe above, although I would
want to
look at whether we can make an SCXML based approach function similarly.
Another strategy would be to add onActivate() and onDeactivate() callbacks
on DialogContextListener, so an application could perform its own custom
save and restore logic. For covering the common cases, we could provide a
simple implementation that you configured with a bunch of VB expressions
(like your configuration example) and did the save/restore stuff. This
way,
we could add the functionality without having to get into the guts of the
dialog implementation on applications that do not need this service.
What do you think?
o Implementation should work for all dialog implementations, basic and
scmxl.
o In the case of SCXML dialogs, the bean mapped, i.e. requestScopeBean1
is mapped to renamedBean in the my example, should not be part of the
scxmlconfig. This will allow the SCXML configuration to be reused in may
dialogs.
o For simple dialogs only configuration changes should be required, the
implementation of a interface like DialogContextListener, should not be
required. The default DialogContextListener implemention should do the
"please save and restore this stuff for me" in onActivate()/onDeactivate().
o The user should be able to convert from a series of views that use a
session scoped bean to pass the data between views to a dialog using
request scoped bean with the following configuration changes:
1) Change the scope of the session bean to request.
2) Define the dialog
3) Update the actions to reference the dialog
Craig
Paul Spencer
Shale Application Controller page not updated to 1.0.4
The first sentence paragraph in "(A) Standard Per-Request Processing" has not been updated to 1.0.4. It should be: As described in Configuring Your Application For Shale, you are requested to configure a Servlet Filter (org.apache.shale.applicationfaces.ShaleApplicationFilter) The class name changed! Paul Spencer [1] http://shale.apache.org/shale-application/index.html
How to use request scoped manage beans in a 1.0.4 dialog?
I need to use an existing JSF page in a dialog. How to I tell the 1.0.4
Dialog manager which request scoped beans to maintain through out the
dialog?
Is their a way to do this in the dialog configuration?
I was hoping for something like:
All of the the views would have access to #{renamedBean} and
#{requestScopeBean2}
Related stuff:
o Desirable Requirements item #1 in the Wiki [1]
o SHALE-184 [2] is a similar issue.
[1] http://wiki.apache.org/shale/DialogManagerFeature
[2] https://issues.apache.org/struts/browse/SHALE-184
Paul Spencer
Re: How to load faces-config.xml in the test framework?
Craig, Yes, we are thing along the same lines. As an example, I have a version "hardcoded" to MyFaces renderers in place [1][2]. I suspect configuring a digester type utility that reads faces-config.xml located in the class path like JSF implementation do, but also allows a file to be passed into the utility, would work very well. After I hard coded the MyFaces stuff, I tried to run it using Sun's RI. As you alluded to, it failed since the package and class names are different. Paul Spencer [1] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/AbstractTomahawkJsfTestCase.java?view=markup [2] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup Craig McClanahan wrote: On 1/1/07, Paul Spencer <[EMAIL PROTECTED]> wrote: How do I load faces-config.xml when running a test based on AbstractJsfTestCase? My current testing manually adds the renderers during setUp(). This work, but it has the following drawbacks: 1) The association between a component and it renderer must be maintained in more then one place. 2) Testing with more then one JSF Implementation is a lot of extra work. Ideally I would like to instruct shale-test to load the implementation's jsf configuration file, i.e. faces-config.xml. How do I do this? There is an outstanding Shale RFE for this feature already[1], and seeing what you were doing kind of motivated me to start working on it a bit in between plays in the football games today :-). My thinking is to provide an optional utility helper (based on Commons Digester) with a parse(URL) method that you could call to register things like components, converters, validators, renderkits, and renderers. The parser would typically be called during a setUp() method of a test case. We'll still have an implementation-specific issue for dealing with the registration of the standard components (since MyFaces and the RI use different resource names), but that's probably something that can be abstracted into a "get me the URL(s) of the standard component definitions" method that could isolate the differences into one place. Is this what you had in mind? Paul Spencer Craig [1] https://issues.apache.org/struts/browse/SHALE-262
How to load faces-config.xml in the test framework?
How do I load faces-config.xml when running a test based on AbstractJsfTestCase? My current testing manually adds the renderers during setUp(). This work, but it has the following drawbacks: 1) The association between a component and it renderer must be maintained in more then one place. 2) Testing with more then one JSF Implementation is a lot of extra work. Ideally I would like to instruct shale-test to load the implementation's jsf configuration file, i.e. faces-config.xml. How do I do this? Paul Spencer
Re: Converting from session managed beans to Shale dialog question.
Craig,
Thank you for the explanation. It was very helpful.
1) Would you like me to post it on Shale's WIKI?
2) "SHALE-184 Provide new "Dialog Scope" for managed bean scope"
looks like what the functionality I need. This would allow
for the conversion from session managed beans to dialog managed
beans without changing the JSPs that reference those beans
or any other code changes.
3) I found the "Dialog Manager Feature" wiki page[1] where
the requirements for an updated Dialog Manager are
being discussed. Is this the primary focus of the
next release of Shale?
[1] http://wiki.apache.org/shale/DialogManagerFeature
Paul Spencer
Craig McClanahan wrote:
On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> wrote:
I am converting from a session managed bean to a Shale Dialog using
a request managed bean. The problem I am currently having is the fields
in the managed bean are being restored on subsequent request. The
application worked with a session managed bean, so is suspect I have
not added support to save/restore state to the bean. If this is the
case, what do I need to add to the managed bean?
It worked in the session managed bean case because the server saved it for
you (in the HttpSession). The analogous capability with dialogs is to save
it in the "data" object that the Dialog Manager provides. Internally, this
is kept in the HttpSession as well, but it is thrown away for you when the
dialog ends.
The data storage area that the Dialog Manager provides for you is in a
session scoped bean named "dialog", which has a "data" property in it.
Your
application can store anything it wants there ... typically, you'll either
use a JavaBean that has properties for all the stuff you want to save, or
just a Map if you don't want to bother creating one. Given this, you can
use value binding expressions like "#{dialog.data.foo}" to reference
property "foo" in your data object. Indeed, it's quite convenient to bind
the JSF components in the pages of your dialog directly to this data bean,
so you don't have to be copying stuff back and forth.
All this theory sounds wonderful, but where's the code? A good example of
this is in the Use Cases example application, in the part that handles
logging on and/or creating a new profile. The dialog starts with an action
call to the "setup()" method in EditProfileActions.java, which (among other
things) stores a new object of type EditProfileState into the data
property,
like this:
EditProfileState state = new EditProfileState();
... initialize things ...
setValue("#{dialog.data}", state);
The pages of this dialog (profile1.jsp, profile2.jsp, and profile3.jsp in
the "profile" subdirectory) all have direct bindings to properties of this
state bean, so the app doesn't have to copy anything as the user navigates
between pages. When the application logic needs access, such as in the
finish() method of EditProfileActions that finishes things up, it can grab
the object:
EditProfileState state = (EditProfileState) getValue("#{dialog.data}");
and go do whatever needs to be done. When the dialog completes, the
framework will release its reference to this bean so that it can be garbage
collected.
A word of warning, though ... there's a number of outstanding bugs (see the
JIRA open bug list on Shale for details) related to the dialog feature, and
we're actively reviewing the implementation. It's possible that some
details of how this works will need to change to address those issues,
although we'll strive to be consistent with current practice when we can.
Paul Spencer
Craig
Converting from session managed beans to Shale dialog question.
I am converting from a session managed bean to a Shale Dialog using a request managed bean. The problem I am currently having is the fields in the managed bean are being restored on subsequent request. The application worked with a session managed bean, so is suspect I have not added support to save/restore state to the bean. If this is the case, what do I need to add to the managed bean? Paul Spencer
