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: snip 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
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: 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!
span
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
t:dataTable
value=[EMAIL PROTECTED]
var=call
styleClass=call
...
t:column
f:facet name=header
h:outputFormat escape=false
value=#{messages['myaccount$callhistory.moneycostcol.header']}
f:param
value=[EMAIL PROTECTED] /
/h:outputFormat
/f:facet
h:outputText value=#{call.cost}
f:converter converterId=com.scn.Currency /
/h:outputText
/t:column
/t:dataTable
/span
The value of @managed-bean-name.currencySymbol is pound;, but it gets
escaped to amp;pound; by the formatter despite the escape=false.
Any ideas anyone? (Am cross-posting this to the myfaces list too).
Cheers,
Ian.
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: h:commandLink id=logon action=dialog:Dienststellensuche h:outputText value=start/ /h:commandLink dialog-config.xml: dialogs dialog name=Dienststellensuche start=Suchparameter Form view name=Suchparameter Form viewId=Dienststellensuche.jsp transition outcome=suchen target=Dienststellenliste / /view view name=Dienststellenliste viewId=Dienststellenliste.jsp transition outcome=ok target=Ende / /view end name=Ende / /dialog /dialogs Jan K.
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,
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
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition cond=${dialogData.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.lease}
target=page2 /
transition event=faces.outcome cond=${outcome eq 'next'}
if cond=${dialog.data.leased eq 'true'}
target next=page2 /
else
target next=review /
/else
/if
/transition
transition target=menu event=faces.outcome
cond=${outcome eq 'cancel'} /
/state
***
* 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?
transition ... cond= ? /
snip/
${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
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
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition cond=${dialogData.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.lease}
target=page2 /
transition event=faces.outcome cond=${outcome eq 'next'}
if cond=${dialog.data.leased eq 'true'}
target next=page2 /
else
target next=review /
/else
/if
/transition
snip/
The target of a transition 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
history (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 transition above whose target
we're trying to determine using conditionals (if) is conceptually
equivalent to the two transitions below (untested):
transition event=faces.outcome
cond=${outcome eq 'next' and dialog.data.leased}
target=page2/
transition event=faces.outcome
cond=${outcome eq 'next' and not dialog.data.leased}
target=review/
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
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition event=faces.outcome
cond=${outcome eq 'next' and dialog.data.leased} target=page2 /
transition event=faces.outcome
cond=${outcome eq 'next' and not dialog.data.leased} target=review /
transition target=menu event=faces.outcome
cond=${outcome eq 'cancel'} /
/state
***
* 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 target element
(though the 0.x line of Commons SCXML supports it for backwards
compatibility). It is recommended to use the target attribute of
transition 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 target 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
snip
Paul Spencer
Re: Need help with SCXML transition cond syntax.
Rahul, Rahul Akolkar wrote: snip 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 snip -Rahul Thank you for you help on this. Paul Spencer
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
snip/
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?
transition ... cond= ? /
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.
snip/
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 h:form snippet, both verbatim
from below (snippet placed at the bottom of wizardpage1.jsp in the
test app above)
2) faces-config additions:
managed-bean
managed-bean-namesessionManager/managed-bean-name
managed-bean-classorg.apache.shale.examples.test.dialog.scxml.SessionManagerBean/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
navigation-rule
from-view-id/*/from-view-id
navigation-case
from-action#{sessionManager.gotoHome}/from-action
from-outcomehome/from-outcome
to-view-id/menu.jsp/to-view-id
/navigation-case
/navigation-rule
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
***
h:form id=logoutForm
h:commandLink action=#{sessionManager.gotoHome}
h:outputText value=Home /
/h:commandLink
/h:form
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 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
dialogs
dialog name=addVendor scxmlconfig=dialogs/addVendor.xml
dataclassname=com.foo.Vendor /
/dialogs
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 ?
snip/
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:
code
DialogContext dcontext = (DialogContext)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
dcontext.stop();
/code
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 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:
dialog ...
beans
bean name=renamedBean value=#{requestScopeBean1}/
bean name=requestScopeBean2/
/beans
/dialog
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
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
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:
snip
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 change. They may be addPage1, addPage2..
and
will
change to dialog:add, next,
I agree that the link that starts the dialog would need to change, but is
there any reason you *have* to change the rest of them? It's certainly
possible to do so, but I don't think it would be a requirement for
migration.
I agree, you only have to change the action that starts the dialog
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: 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
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
