Refresh a DynaActionFrom
Hi, I am using DynaActionForm, one of the form bean property is a indexed type. I can not specify the size attribute for this property I am keeping this form bean in Session scope. When I submit to an action class, it is working fine, after submitting to the action, if I refresh the JSP it is showing the following error: Error 500: BeanUtils.populate [5/22/06 10:39:16:490 IST] 630ba5af WebGroup E SRVE0026E: [Servlet Error]-[BeanUtils.populate]: java.lang.ArrayIndexOutOfBoundsException at java.lang.reflect.Array.get(Native Method) at org.apache.struts.action.DynaActionForm.get(DynaActionForm.java:250) at org.apache.commons.beanutils.PropertyUtilsBean.getIndexedProperty(Proper tyUtilsBean.java:386) at org.apache.commons.beanutils.PropertyUtilsBean.getIndexedProperty(Proper tyUtilsBean.java:340) at org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(Propert yUtilsBean.java:684) at org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtils Bean.java:715) at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.jav a:884) at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:8 11) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:298) at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493) at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcess or.java:816) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java: 203) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictSe rvletInstance.java:110) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLi fecycleServlet.java:174) at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycle Servlet.java:313) at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLif ecycleServlet.java:116) at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance. java:283) at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(Vali dServletReferenceState.java:42) at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(Servle tInstanceReference.java:40) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispa tch(WebAppRequestDispatcher.java:983) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRe questDispatcher.java:564) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppReq uestDispatcher.java:200) at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:1 19) at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInv oker.java:276) at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocati on(CachedInvocation.java:71) at com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invo ke(CacheableInvocationContext.java:116) at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(Servle tRequestProcessor.java:186) at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSELis tener.java:334) at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection .java:56) at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java: 618) at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672) Any solution how to overcome this problem.. Thanks in advance Best Regards, Srini The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
[jira] Commented: (STR-2388) [taglib] enhance bean:write with optional "timezone" attribute if property data is a Date type
[ http://issues.apache.org/struts/browse/STR-2388?page=comments#action_37385 ] Ralf Hauser commented on STR-2388: -- see also SB-20 for enum support > [taglib] enhance bean:write with optional "timezone" attribute if property > data is a Date type > -- > > Key: STR-2388 > URL: http://issues.apache.org/struts/browse/STR-2388 > Project: Struts Action 1 > Type: Improvement > Components: Taglibs > Versions: 1.2.6 Beta > Environment: Operating System: All > Platform: PC > Reporter: Ralf Hauser > Assignee: Struts Developer Mailing List > Priority: Minor > Attachments: WriteTag.java.patch > > As per > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg54524.html, > with TimeZone.getDefault() the Date.toString() method takes the server > default. > Since java.util.TimeZone.setDefaultZone() takes jvm global property > "user.timezone" or in absence of this "user.country" and "java.home", this > cannot be used to vary the timeZone on a per session basis. > An alternative implementation approach might be to > 1) add a String org.apache.struts.Globals.TIMEZONE_KEY = > "org.apache.struts.action.TIMEZONE" like we do for Locale > 2) extend the bean:write as per the patch attached next > 3) extension of TagUtils in analogy to > org.apache.struts.taglib.TagUtils.getUserLocale() or rather directly > org.apache.struts.util.RequestUtils.getUserLocale() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (STR-2435) [taglib] enhance bean:write with a "decorator" attribute for tailored formatting
[ http://issues.apache.org/struts/browse/STR-2435?page=comments#action_37384 ] Ralf Hauser commented on STR-2435: -- see also SB-20 > [taglib] enhance bean:write with a "decorator" attribute for tailored > formatting > > > Key: STR-2435 > URL: http://issues.apache.org/struts/browse/STR-2435 > Project: Struts Action 1 > Type: Improvement > Components: Taglibs > Versions: Nightly Build > Environment: Operating System: All > Platform: Other > Reporter: Ralf Hauser > Assignee: Struts Developer Mailing List > Priority: Minor > > The decorator approach as used in > http://displaytag.sourceforge.net/tut_decorators.html#Column_Decorators > appears > to be more powerful than the "format" and "formatKey" attribute in > http://struts.apache.org/userGuide/struts-bean.html#write. > Therefore, I suggest "decorator" should have precedence over "format" and > "formatKey". > Sure, one could create one's own taglibs for this, but that is so much more > complicated. > This might make STR-2387 obsolete as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (STR-1892) timezone support for bean:write tag
[
http://issues.apache.org/struts/browse/STR-1892?page=comments#action_37383 ]
Ralf Hauser commented on STR-1892:
--
see also STR-2435 and SB-20
> timezone support for bean:write tag
> ---
>
> Key: STR-1892
> URL: http://issues.apache.org/struts/browse/STR-1892
> Project: Struts Action 1
> Type: Improvement
> Components: Taglibs
> Versions: 1.1 Final
> Environment: Operating System: other
> Platform: All
> Reporter: Dam Cho
> Assignee: Struts Developer Mailing List
> Priority: Minor
>
> currently as of version 1.2 of Struts custom tag library, timezone is not
> configurable for using bean:write tag with Date object. Both JSTL and apache
> date custom tags support converting date value to that of different timezone.
> below is a subclass I created to accomodate timezone configuration. Something
> like this would do..
> public class WriteDateTag extends WriteTag {
> private String timeZoneString;
>
> public void setTimezone(String timeZoneString) {
> this.timeZoneString = timeZoneString;
> }
>
> public String getTimezoneString() {
> return timeZoneString;
> }
>
> /**
>* Format value according to specified format string (as tag attribute
> or
>* as string from message resources) or to current user locale.
>*
>* @param valueToFormat value to process and convert to String
>* @exception JspException if a JSP exception has occurred
>*/
> protected String formatValue(Object valueToFormat) throws JspException {
> Format format = null;
> Object value = valueToFormat;
> Locale locale =
> RequestUtils.retrieveUserLocale(pageContext,
> this.localeKey);
> boolean formatStrFromResources = false;
> String formatString = formatStr;
> // Try to retrieve format string from resources by the key from
> formatKey.
> if( ( formatString==null ) && ( formatKey!=null ) ) {
> formatString = retrieveFormatString( this.formatKey );
> if( formatString!=null )
> formatStrFromResources = true;
> }
> if (formatString == null) {
> if (value instanceof java.sql.Timestamp) {
> formatString =
> retrieveFormatString(SQL_TIMESTAMP_FORMAT_KEY);
> } else if (value instanceof java.sql.Date) {
> formatString =
> retrieveFormatString(SQL_DATE_FORMAT_KEY);
> } else if (value instanceof java.sql.Time) {
> formatString =
> retrieveFormatString(SQL_TIME_FORMAT_KEY);
> } else if (value instanceof java.util.Date) {
> formatString =
> retrieveFormatString(DATE_FORMAT_KEY);
> }
> if (formatString != null)
> formatStrFromResources = true;
> }
>
> TimeZone tz = null;
> if (timeZoneString != null) {
> tz = TimeZone.getTimeZone(timeZoneString);
> } else {
> tz = TimeZone.getDefault();
> }
> if (formatString != null) {
> if (formatStrFromResources) {
> format = new SimpleDateFormat(formatString,
> locale);
> } else {
> format = new SimpleDateFormat(formatString);
> }
> }
>
>
> if (format != null) {
> ((SimpleDateFormat) format).setTimeZone(tz);
> return format.format(value);
> } else {
> return value.toString();
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Of course this is what Craig wanted the whole time. Lord! And, it is what the rest of the world has been trying to avoid. Now, it comes again in the back door. Don't any committers know where the front door is? On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: In the Action 2 approach, you should be able to use any feature of Shale, or any other JSF extension, that doesn't involve a custom NavigationHandler, since that is overridden to defer to Action 2-style navigation, or a custom Lifecycle. By leaving JSF alone otherwise, you should be able to use fancy Ajax components or any other more intrusive extension that relies heavily on PhaseListeners or custom ViewHandlers. For me, Action 2 really makes JSF more palatable by remove two parts of JSF I found unnecessarily complex and tedious - navigation and required managed beans. You can still use navigation JSF components, but instead of all that navigation rule XML, you use Action 2's Results, which are simpler and more extensible. You can also still have managed beans, but since the Action is treated as one from an EL perspective, they are no longer required. Therefore, your JSF-enabled app doesn't need faces-config.xml at all. The downside is the Action 2-style navigation might not be as toolable and you lose some advantage of the tool support overall. However, from this old Struts user's perspective, I think this makes JSF much more attractive and easier to assimilate. Isn't that what you wanted, Craig, the whole time? ;) Don Craig McClanahan wrote: > On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: >> >> Congrats, Don! I'm very encouraged, and I'm anxious to check it out. >> This >> will allow SAF2 developers to work with JSF components (and the >> market is >> growing nicely). >> >> I wonder how well Shale will run in this context... > > > Don and I had a chance to chat about this idea last week at JavaOne > (glad to > see the phase listener strategy worked out so well :-). You'll want > to look > at SAF2+JSF for cases where you've got a primarily action controller > driven > application architecture, but where you want to use some really cool JSF > components here and there on your pages -- without *having* to convert > the > entire page to use components. You'll be able to do that, without > throwing > away all the rest of your architecture (but you won't be leveraging > anything > in JSF other than the components). > > If you're building an app around the JSF controller (perhaps because you > like the JSF approach to navigation, or its lifecycle), on the other > hand, > you'd be better off starting with JSF+Shale. Just to make things a > bit more > interesting, several of the Struts committers got together and talked > about > how we can share common stuff between the two frameworks ... and some > ideas > that are already on the Shale roadmap[1][2] involve support for XWork > interceptors in addition to (and probably ultimately preferred to) using > Commons Chain to decorate the overall request lifecycle. This will > likely > end up being fairly similar to what Don did in terms of being able to > customize each phase individually. I'll have more detailed comments when > I've had a chance to dig in a little deeper. > > Craig > > [1] http://issues.apache.org/struts/browse/SHALE-108 > [2] http://issues.apache.org/struts/browse/SHALE-136 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Since Kito is committed and has been to JSF Central, why pretend that he needs to know about this. These are like those paid 1 hour commercials we have to put up with on Sunday mornings that attempt to distort the truth. Give us a break. On 5/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: > > Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This > will allow SAF2 developers to work with JSF components (and the market is > growing nicely). > > I wonder how well Shale will run in this context... Don and I had a chance to chat about this idea last week at JavaOne (glad to see the phase listener strategy worked out so well :-). You'll want to look at SAF2+JSF for cases where you've got a primarily action controller driven application architecture, but where you want to use some really cool JSF components here and there on your pages -- without *having* to convert the entire page to use components. You'll be able to do that, without throwing away all the rest of your architecture (but you won't be leveraging anything in JSF other than the components). If you're building an app around the JSF controller (perhaps because you like the JSF approach to navigation, or its lifecycle), on the other hand, you'd be better off starting with JSF+Shale. Just to make things a bit more interesting, several of the Struts committers got together and talked about how we can share common stuff between the two frameworks ... and some ideas that are already on the Shale roadmap[1][2] involve support for XWork interceptors in addition to (and probably ultimately preferred to) using Commons Chain to decorate the overall request lifecycle. This will likely end up being fairly similar to what Don did in terms of being able to customize each phase individually. I'll have more detailed comments when I've had a chance to dig in a little deeper. Craig [1] http://issues.apache.org/struts/browse/SHALE-108 [2] http://issues.apache.org/struts/browse/SHALE-136 -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Are there any figures on this market junk? Or is this more Bush-Speak, lies to get someone thinking your way? On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/J2EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > -Original Message- > From: Don Brown [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 21, 2006 3:55 AM > To: Struts Developers List > Subject: [action2] Combining JSF and SAF2 > > After talking with several on this list about the possibility > of combining the best of JSF and Action 2 in a unified > framework from a user perspective, I have completed a first > cut at JSF support in Action > 2 with this loftly goal. > > From a user perspective, you still have one configuration > file, struts-action.xml, which maps urls to actions and > actions to results. > However, you can optionally include the JSF interceptor stack > and use the JSF result, allowing you to use JSF components in > the view. You still define alternative results the same way, > still have an action class per url, and can still use the > normal GET-style navigation. > > From a framework perspective, I split the lifecycle class > into indivudal Action 2 interceptors, one per phase. The > final render phase I turned into a Result. Upon > initialization, I replace the navigation handler with one > that simply records outcomes as if they were result codes > from an Action. Also, the setup inserts a variable resolver > that exposes the action instance to the EL bindings. > Therefore, the flow > goes: determine action/namespace -> run normal interceptors > -> run JSF phases -> invoke JSF action (optional) -> invoke > SAF2 action -> invoke render phase. The purpose of the > Action then becomes as a general setup for the page, much > like the Shale pre-render hook. > > I chose this approach because I find the Action 2 controller > stronger (JSF was always meant as a view tech, as I > understand it), so think it better suited for navigation, > state-less actions, and centralizing page setup code. JSF is > better for complex single pages or page groups where > different stateful components might be needing to submit the > page without affecting others. > > To demonstrate this integration, I added a JSF tab to the > showcase. As a sneak peek, here is the action mapping for a > JSF page that edits an > employee: > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > index > > > Notice the default page is the JSF page, but other navigation > is handled by traditional Action 2 results. Incidently, this > means only POSTs for real form submits and bookmarkable GETS > everywhere else. > > I'm sure there is a lot of refinement to do, but I'm hoping > this general approach will solve the very popular need to > combine the two frameworks in a seamless way for the user. > I'm particularly interested in feedback from the JSF folks, > as I'm pretty new to the framework. > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Sounds like Ted. Let me say that anyone that says web services is a half-baked CICS is really not worth listening to. That is ridiculous. I am really amazed at the nutty things said on this list. If you think that web services is coincident with SOA that is equal madness. Do you guys think these things through or just mix the newest words around the best you can figure it out? SOA is an architecture. You really have to know what you are doing to use CICS right in SOA, which is done with all the major players in this arena, even with web services. So far as I can see, you don't understand much you are talking about. I'm not at all against JSF or other solutions of any kind. What I hate is people who in order to market themselves lie and manipulate people who trust them. That is the only thing I have against JSF, the attempt to market it buy taking space where it does not belong. Anyone who brings JSF to Struts cannot be working on too much voltage. On 5/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Dakota Jack" <[EMAIL PROTECTED]> > > Of course you aren't, Gary, because my panties are not in a bunch. > You are the one with his panties in a bunch because you are here for > JSF and JSF alone anyway and you don't like me having pointed out that > your contributions did not merit your status. You can side with > Kamini if you like, but she is the one of the real trolls on this > list. You just don't like what I say. If you have trouble with me > because of what I say, then you have black and white thinking. If you > like what people like Kamini say, then you are just beyond interest. > No, I don't care about that. I think that Clay is a pretty fun trick and might make folks think about alternatives to using the JSP JSF technology. It's not the best or only solution either. Facelets is another very interesting solution. In many aspects superior to Clay. I had a chance to talk with Howard Lewis Ship last week about new features in Tapestry. I also talked with Jacob Hookem about Facelets. I was honored that they would take the time to share their ideas with me. But, really, there might be something to be learned with Don's proposal. It's really easy to get caught up in the merits of technology but the question is, will people be able to better automate there business? At JavaOne 2006, Sun announces VB that will run under the java VM. Now, that's not my cup-of-tea but I bet that it will be a big hit in the business world. So, is finding ways to use Struts action and Struts Shale really that big of a deal? I also had a chance to attend Scott Ambler's session on Agile Modeling last week. He had a funny comment about how he had seen a lot of reinvention of the wheel in regards to web services. He said something like, it was a half bake retooling of CICS. I've often thought of SOA that way too and kind of thought that at some level the whole JavaSpaces and BEPL was similar to JCL. There was also a session on AJAX/SOA and Web 2.0 that they discussed the re branding of these technologies. I guess that my point is that we will always be looking for better ways to solve our problems in a smaller window of time using spins on the same technology and at the same time, trying to leverage existing investments. This is in a market that doesn't always value the people that have the knowledge of their business or the people that automate the business using technologies. So, what have you done for me lately? Well, not only the Struts and other apache communities but Commercial vendors contribute their time and ideas and are trying to make their products better by using open source as the vehicle. I attended a session on "project tango". Oh my, first class interoperability between java and .Net. This is "Human sacrifice, dogs and cats, living together... mass hysteria!". Yet, it's hard for you to understand why two java web frameworks would want to achieve interoperability. "Which pill would you take, the red or the blue?". "I don't know if we each have a destiny, or if we're all just floatin' around accidental-like on a breeze. I think maybe it's both." But, "That's all I have to say about that." Gary > On 5/21/06, Gary VanMatre wrote: > > >From: "Dakota Jack" > > > > > > You are right, for once. I only speak for myself. Those who are > > > unwilling to listen to others are condemned by their own choice to a > > > life of ignorance. > > > > > > > Sheese, sorry this got your panties in a bunch. > > > > > > > On 5/21/06, Kimani Darisha wrote: > > > > To anyone following these thread, please ignore this fool. He does > > > > not speak for anyone, and is only here to confuse people. > > > > > > > > K. > > > > > > > > On 5/21/06, Dakota Jack wrote: > > > > > I have seen no "very popular need". This is like Bush-Speak. Baloney > > > > > parading as truth. > > > > > > > > > > On 5/21/06, Don Brown wrote: > > > > > > > > > > > > After talking with several on this list about the possibility o
Re: [action2] Combining JSF and SAF2
In the Action 2 approach, you should be able to use any feature of Shale, or any other JSF extension, that doesn't involve a custom NavigationHandler, since that is overridden to defer to Action 2-style navigation, or a custom Lifecycle. By leaving JSF alone otherwise, you should be able to use fancy Ajax components or any other more intrusive extension that relies heavily on PhaseListeners or custom ViewHandlers. For me, Action 2 really makes JSF more palatable by remove two parts of JSF I found unnecessarily complex and tedious - navigation and required managed beans. You can still use navigation JSF components, but instead of all that navigation rule XML, you use Action 2's Results, which are simpler and more extensible. You can also still have managed beans, but since the Action is treated as one from an EL perspective, they are no longer required. Therefore, your JSF-enabled app doesn't need faces-config.xml at all. The downside is the Action 2-style navigation might not be as toolable and you lose some advantage of the tool support overall. However, from this old Struts user's perspective, I think this makes JSF much more attractive and easier to assimilate. Isn't that what you wanted, Craig, the whole time? ;) Don Craig McClanahan wrote: On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... Don and I had a chance to chat about this idea last week at JavaOne (glad to see the phase listener strategy worked out so well :-). You'll want to look at SAF2+JSF for cases where you've got a primarily action controller driven application architecture, but where you want to use some really cool JSF components here and there on your pages -- without *having* to convert the entire page to use components. You'll be able to do that, without throwing away all the rest of your architecture (but you won't be leveraging anything in JSF other than the components). If you're building an app around the JSF controller (perhaps because you like the JSF approach to navigation, or its lifecycle), on the other hand, you'd be better off starting with JSF+Shale. Just to make things a bit more interesting, several of the Struts committers got together and talked about how we can share common stuff between the two frameworks ... and some ideas that are already on the Shale roadmap[1][2] involve support for XWork interceptors in addition to (and probably ultimately preferred to) using Commons Chain to decorate the overall request lifecycle. This will likely end up being fairly similar to what Don did in terms of being able to customize each phase individually. I'll have more detailed comments when I've had a chance to dig in a little deeper. Craig [1] http://issues.apache.org/struts/browse/SHALE-108 [2] http://issues.apache.org/struts/browse/SHALE-136 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Standalone Tiles] Removing taglib attributes
I've opened SB-21 to take a look at the multiple Tiles taglib attributes that seem to mean the same thing. I can't find the original discussion, but I remember at one point talking about consolidating these to a single attribute. Does anyone remember that discussion, or have an opinion either way? * http://issues.apache.org/struts/browse/SB-21 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... Don and I had a chance to chat about this idea last week at JavaOne (glad to see the phase listener strategy worked out so well :-). You'll want to look at SAF2+JSF for cases where you've got a primarily action controller driven application architecture, but where you want to use some really cool JSF components here and there on your pages -- without *having* to convert the entire page to use components. You'll be able to do that, without throwing away all the rest of your architecture (but you won't be leveraging anything in JSF other than the components). If you're building an app around the JSF controller (perhaps because you like the JSF approach to navigation, or its lifecycle), on the other hand, you'd be better off starting with JSF+Shale. Just to make things a bit more interesting, several of the Struts committers got together and talked about how we can share common stuff between the two frameworks ... and some ideas that are already on the Shale roadmap[1][2] involve support for XWork interceptors in addition to (and probably ultimately preferred to) using Commons Chain to decorate the overall request lifecycle. This will likely end up being fairly similar to what Don did in terms of being able to customize each phase individually. I'll have more detailed comments when I've had a chance to dig in a little deeper. Craig [1] http://issues.apache.org/struts/browse/SHALE-108 [2] http://issues.apache.org/struts/browse/SHALE-136
RE: [action2] Combining JSF and SAF2
Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/J2EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > -Original Message- > From: Don Brown [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 21, 2006 3:55 AM > To: Struts Developers List > Subject: [action2] Combining JSF and SAF2 > > After talking with several on this list about the possibility > of combining the best of JSF and Action 2 in a unified > framework from a user perspective, I have completed a first > cut at JSF support in Action > 2 with this loftly goal. > > From a user perspective, you still have one configuration > file, struts-action.xml, which maps urls to actions and > actions to results. > However, you can optionally include the JSF interceptor stack > and use the JSF result, allowing you to use JSF components in > the view. You still define alternative results the same way, > still have an action class per url, and can still use the > normal GET-style navigation. > > From a framework perspective, I split the lifecycle class > into indivudal Action 2 interceptors, one per phase. The > final render phase I turned into a Result. Upon > initialization, I replace the navigation handler with one > that simply records outcomes as if they were result codes > from an Action. Also, the setup inserts a variable resolver > that exposes the action instance to the EL bindings. > Therefore, the flow > goes: determine action/namespace -> run normal interceptors > -> run JSF phases -> invoke JSF action (optional) -> invoke > SAF2 action -> invoke render phase. The purpose of the > Action then becomes as a general setup for the page, much > like the Shale pre-render hook. > > I chose this approach because I find the Action 2 controller > stronger (JSF was always meant as a view tech, as I > understand it), so think it better suited for navigation, > state-less actions, and centralizing page setup code. JSF is > better for complex single pages or page groups where > different stateful components might be needing to submit the > page without affecting others. > > To demonstrate this integration, I added a JSF tab to the > showcase. As a sneak peek, here is the action mapping for a > JSF page that edits an > employee: > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > index > > > Notice the default page is the JSF page, but other navigation > is handled by traditional Action 2 results. Incidently, this > means only POSTs for real form submits and bookmarkable GETS > everywhere else. > > I'm sure there is a lot of refinement to do, but I'm hoping > this general approach will solve the very popular need to > combine the two frameworks in a seamless way for the user. > I'm particularly interested in feedback from the JSF folks, > as I'm pretty new to the framework. > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
>From: "Dakota Jack" <[EMAIL PROTECTED]> > > Of course you aren't, Gary, because my panties are not in a bunch. > You are the one with his panties in a bunch because you are here for > JSF and JSF alone anyway and you don't like me having pointed out that > your contributions did not merit your status. You can side with > Kamini if you like, but she is the one of the real trolls on this > list. You just don't like what I say. If you have trouble with me > because of what I say, then you have black and white thinking. If you > like what people like Kamini say, then you are just beyond interest. > No, I don't care about that. I think that Clay is a pretty fun trick and might make folks think about alternatives to using the JSP JSF technology. It's not the best or only solution either. Facelets is another very interesting solution. In many aspects superior to Clay. I had a chance to talk with Howard Lewis Ship last week about new features in Tapestry. I also talked with Jacob Hookem about Facelets. I was honored that they would take the time to share their ideas with me. But, really, there might be something to be learned with Don's proposal. It's really easy to get caught up in the merits of technology but the question is, will people be able to better automate there business? At JavaOne 2006, Sun announces VB that will run under the java VM. Now, that's not my cup-of-tea but I bet that it will be a big hit in the business world. So, is finding ways to use Struts action and Struts Shale really that big of a deal? I also had a chance to attend Scott Ambler's session on Agile Modeling last week. He had a funny comment about how he had seen a lot of reinvention of the wheel in regards to web services. He said something like, it was a half bake retooling of CICS. I've often thought of SOA that way too and kind of thought that at some level the whole JavaSpaces and BEPL was similar to JCL. There was also a session on AJAX/SOA and Web 2.0 that they discussed the re branding of these technologies. I guess that my point is that we will always be looking for better ways to solve our problems in a smaller window of time using spins on the same technology and at the same time, trying to leverage existing investments. This is in a market that doesn't always value the people that have the knowledge of their business or the people that automate the business using technologies. So, what have you done for me lately? Well, not only the Struts and other apache communities but Commercial vendors contribute their time and ideas and are trying to make their products better by using open source as the vehicle. I attended a session on "project tango". Oh my, first class interoperability between java and .Net. This is "Human sacrifice, dogs and cats, living together... mass hysteria!". Yet, it's hard for you to understand why two java web frameworks would want to achieve interoperability. "Which pill would you take, the red or the blue?". "I don't know if we each have a destiny, or if we're all just floatin' around accidental-like on a breeze. I think maybe it's both." But, "That's all I have to say about that." Gary > On 5/21/06, Gary VanMatre wrote: > > >From: "Dakota Jack" > > > > > > You are right, for once. I only speak for myself. Those who are > > > unwilling to listen to others are condemned by their own choice to a > > > life of ignorance. > > > > > > > Sheese, sorry this got your panties in a bunch. > > > > > > > On 5/21/06, Kimani Darisha wrote: > > > > To anyone following these thread, please ignore this fool. He does > > > > not speak for anyone, and is only here to confuse people. > > > > > > > > K. > > > > > > > > On 5/21/06, Dakota Jack wrote: > > > > > I have seen no "very popular need". This is like Bush-Speak. Baloney > > > > > parading as truth. > > > > > > > > > > On 5/21/06, Don Brown wrote: > > > > > > > > > > > > After talking with several on this list about the possibility of > > > > > > combining the best of JSF and Action 2 in a unified framework from > > > > > > a > > > > > > user perspective, I have completed a first cut at JSF support in > Action > > > > > > 2 with this loftly goal. > > > > > > > > > > > > From a user perspective, you still have one configuration file, > > > > > > struts-action.xml, which maps urls to actions and actions to > > > > > > results. > > > > > > However, you can optionally include the JSF interceptor stack and > > > > > > use > > > > > > the JSF result, allowing you to use JSF components in the view. You > > > > > > still define alternative results the same way, still have an action > > > > > > class per url, and can still use the normal GET-style navigation. > > > > > > > > > > > > From a framework perspective, I split the lifecycle class into > > > > > > indivudal Action 2 interceptors, one per phase. The final render > > > > > > phase > > > > > > I turned into a Res
Re: [action2] Combining JSF and SAF2
Of course you aren't, Gary, because my panties are not in a bunch. You are the one with his panties in a bunch because you are here for JSF and JSF alone anyway and you don't like me having pointed out that your contributions did not merit your status. You can side with Kamini if you like, but she is the one of the real trolls on this list. You just don't like what I say. If you have trouble with me because of what I say, then you have black and white thinking. If you like what people like Kamini say, then you are just beyond interest. On 5/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Dakota Jack" <[EMAIL PROTECTED]> > > You are right, for once. I only speak for myself. Those who are > unwilling to listen to others are condemned by their own choice to a > life of ignorance. > Sheese, sorry this got your panties in a bunch. > On 5/21/06, Kimani Darisha wrote: > > To anyone following these thread, please ignore this fool. He does > > not speak for anyone, and is only here to confuse people. > > > > K. > > > > On 5/21/06, Dakota Jack wrote: > > > I have seen no "very popular need". This is like Bush-Speak. Baloney > > > parading as truth. > > > > > > On 5/21/06, Don Brown wrote: > > > > > > > > After talking with several on this list about the possibility of > > > > combining the best of JSF and Action 2 in a unified framework from a > > > > user perspective, I have completed a first cut at JSF support in Action > > > > 2 with this loftly goal. > > > > > > > > From a user perspective, you still have one configuration file, > > > > struts-action.xml, which maps urls to actions and actions to results. > > > > However, you can optionally include the JSF interceptor stack and use > > > > the JSF result, allowing you to use JSF components in the view. You > > > > still define alternative results the same way, still have an action > > > > class per url, and can still use the normal GET-style navigation. > > > > > > > > From a framework perspective, I split the lifecycle class into > > > > indivudal Action 2 interceptors, one per phase. The final render phase > > > > I turned into a Result. Upon initialization, I replace the navigation > > > > handler with one that simply records outcomes as if they were result > > > > codes from an Action. Also, the setup inserts a variable resolver that > > > > exposes the action instance to the EL bindings. Therefore, the flow > > > > goes: determine action/namespace -> run normal interceptors -> run JSF > > > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > > > render phase. The purpose of the Action then becomes as a general setup > > > > for the page, much like the Shale pre-render hook. > > > > > > > > I chose this approach because I find the Action 2 controller stronger > > > > (JSF was always meant as a view tech, as I understand it), so think it > > > > better suited for navigation, state-less actions, and centralizing page > > > > setup code. JSF is better for complex single pages or page groups where > > > > different stateful components might be needing to submit the page > > > > without affecting others. > > > > > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > > > a sneak peek, here is the action mapping for a JSF page that edits an > > > > employee: > > > > > > > > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > > > > > > > > > index > > > > > > > > > > > > Notice the default page is the JSF page, but other navigation is handled > > > > by traditional Action 2 results. Incidently, this means only POSTs for > > > > real form submits and bookmarkable GETS everywhere else. > > > > > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > > > approach will solve the very popular need to combine the two frameworks > > > > in a seamless way for the user. I'm particularly interested in feedback > > > > from the JSF folks, as I'm pretty new to the framework. > > > > > > > > Don > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > "You can lead a horse to water but you cannot make it float on its back." > > > ~Dakota Jack~ > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ -
Re: [action2] Combining JSF and SAF2
>From: "Dakota Jack" <[EMAIL PROTECTED]> > > You are right, for once. I only speak for myself. Those who are > unwilling to listen to others are condemned by their own choice to a > life of ignorance. > Sheese, sorry this got your panties in a bunch. > On 5/21/06, Kimani Darisha wrote: > > To anyone following these thread, please ignore this fool. He does > > not speak for anyone, and is only here to confuse people. > > > > K. > > > > On 5/21/06, Dakota Jack wrote: > > > I have seen no "very popular need". This is like Bush-Speak. Baloney > > > parading as truth. > > > > > > On 5/21/06, Don Brown wrote: > > > > > > > > After talking with several on this list about the possibility of > > > > combining the best of JSF and Action 2 in a unified framework from a > > > > user perspective, I have completed a first cut at JSF support in Action > > > > 2 with this loftly goal. > > > > > > > > From a user perspective, you still have one configuration file, > > > > struts-action.xml, which maps urls to actions and actions to results. > > > > However, you can optionally include the JSF interceptor stack and use > > > > the JSF result, allowing you to use JSF components in the view. You > > > > still define alternative results the same way, still have an action > > > > class per url, and can still use the normal GET-style navigation. > > > > > > > > From a framework perspective, I split the lifecycle class into > > > > indivudal Action 2 interceptors, one per phase. The final render phase > > > > I turned into a Result. Upon initialization, I replace the navigation > > > > handler with one that simply records outcomes as if they were result > > > > codes from an Action. Also, the setup inserts a variable resolver that > > > > exposes the action instance to the EL bindings. Therefore, the flow > > > > goes: determine action/namespace -> run normal interceptors -> run JSF > > > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > > > render phase. The purpose of the Action then becomes as a general setup > > > > for the page, much like the Shale pre-render hook. > > > > > > > > I chose this approach because I find the Action 2 controller stronger > > > > (JSF was always meant as a view tech, as I understand it), so think it > > > > better suited for navigation, state-less actions, and centralizing page > > > > setup code. JSF is better for complex single pages or page groups where > > > > different stateful components might be needing to submit the page > > > > without affecting others. > > > > > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > > > a sneak peek, here is the action mapping for a JSF page that edits an > > > > employee: > > > > > > > > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > > > > > > > > > index > > > > > > > > > > > > Notice the default page is the JSF page, but other navigation is > > > > handled > > > > by traditional Action 2 results. Incidently, this means only POSTs for > > > > real form submits and bookmarkable GETS everywhere else. > > > > > > > > I'm sure there is a lot of refinement to do, but I'm hoping this > > > > general > > > > approach will solve the very popular need to combine the two frameworks > > > > in a seamless way for the user. I'm particularly interested in feedback > > > > from the JSF folks, as I'm pretty new to the framework. > > > > > > > > Don > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > "You can lead a horse to water but you cannot make it float on its back." > > > ~Dakota Jack~ > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [action2] Combining JSF and SAF2
Like I said before, use Shale to fork from, adding the JSP to it. (or if shale adds JSP tags, no reason for SAF2). .V Jason Carreira wrote: I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Don, does this make SAF a full JSF implementation (minus the bundled components)? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r408459 - in /struts/action2/trunk: action-api/pom.xml apps
On 5/21/06, Jason Carreira <[EMAIL PROTECTED]> wrote: Wendy, will this create the IDEA modules with all dependencies for extras and showcase? Are all of the jars downloading now? I had to fix this by hand on the plane yesterday, so I don't want to blow them away if I have to do it again. If it didn't work before, this is unlikely to have fixed it -- all I did was change the name of the parent pom. It works for me, though. After mvn idea:clean -P extras mvn idea:idea -P extras I see all the dependencies for the modules, and they compile within IDEA. The only thing that doesn't work for me is the IDEA run/debug config for the showcase app, but Patrick explained that QuickStart can't deal with the path variable I have. And I had trouble with it not downloading the xwork snapshot, but deleting $M2_REPO/opensymphony/xwork fixed it, and now it's checking on every build. Try it on a copy of your checked-out source first, and let us know what happens. It _should_ work. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r408459 - in /struts/action2/trunk: action-api/pom.xml apps
Wendy, will this create the IDEA modules with all dependencies for extras and showcase? Are all of the jars downloading now? I had to fix this by hand on the plane yesterday, so I don't want to blow them away if I have to do it again. > Be sure to update and install from the top level of > Action 2 to pick > up the changed artifactId. > svn up > mvn install -P extras > > Also remove the old ide config files and re-generate > them, for example > with IDEA: > rm project.i* > mvn idea:idea -P extras > > -- > Wendy - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31712&messageID=61394#61394 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
On 5/21/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote: Otherwise, I think the showcase webapp can now be included in the default build. Thanks! The snapshots are updated, and now include the showcase: http://people.apache.org/maven-snapshot-repository/org/apache/struts/action2/ To update these at any time, just execute 'mvn deploy -P extras'. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
It is acceptable to distribute CDDL code in binary form, so RIFE isn't a problem. Don Rainer Hermanns wrote: Regardless, showcase should be split up so we can ship a functional app with no LGPL problems. Don, I just removed the deps on JasperReports which were the last real LGPL code dependency. However, there is still an example with continuations based on RIFE. Since RIFE is dual licensed (CDDL and LGPL), these samples shouldn't be a problem. Please correct me, if I'm wrong. Otherwise, I think the showcase webapp can now be included in the default build. regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
On 5/21/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: Once the LGPL-dependent examples are removed from the showcase, it can be part of the normal build, and the 'extras' profile can build both struts-extras.jar and a separate extras example app. ... which would put us right back in the original situation of wanting to build struts-extras.jar without building the showcase app. Oops. Any example app that needs to include jars with incompatible licenses will need to be in a completely separate profile so it will not be included in snapshots and distributions. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
> Regardless, showcase should be split up so we can ship a functional app > with no LGPL problems. Don, I just removed the deps on JasperReports which were the last real LGPL code dependency. However, there is still an example with continuations based on RIFE. Since RIFE is dual licensed (CDDL and LGPL), these samples shouldn't be a problem. Please correct me, if I'm wrong. Otherwise, I think the showcase webapp can now be included in the default build. regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
You are right, for once. I only speak for myself. Those who are unwilling to listen to others are condemned by their own choice to a life of ignorance. On 5/21/06, Kimani Darisha <[EMAIL PROTECTED]> wrote: To anyone following these thread, please ignore this fool. He does not speak for anyone, and is only here to confuse people. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > I have seen no "very popular need". This is like Bush-Speak. Baloney > parading as truth. > > On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > After talking with several on this list about the possibility of > > combining the best of JSF and Action 2 in a unified framework from a > > user perspective, I have completed a first cut at JSF support in Action > > 2 with this loftly goal. > > > > From a user perspective, you still have one configuration file, > > struts-action.xml, which maps urls to actions and actions to results. > > However, you can optionally include the JSF interceptor stack and use > > the JSF result, allowing you to use JSF components in the view. You > > still define alternative results the same way, still have an action > > class per url, and can still use the normal GET-style navigation. > > > > From a framework perspective, I split the lifecycle class into > > indivudal Action 2 interceptors, one per phase. The final render phase > > I turned into a Result. Upon initialization, I replace the navigation > > handler with one that simply records outcomes as if they were result > > codes from an Action. Also, the setup inserts a variable resolver that > > exposes the action instance to the EL bindings. Therefore, the flow > > goes: determine action/namespace -> run normal interceptors -> run JSF > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > render phase. The purpose of the Action then becomes as a general setup > > for the page, much like the Shale pre-render hook. > > > > I chose this approach because I find the Action 2 controller stronger > > (JSF was always meant as a view tech, as I understand it), so think it > > better suited for navigation, state-less actions, and centralizing page > > setup code. JSF is better for complex single pages or page groups where > > different stateful components might be needing to submit the page > > without affecting others. > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > a sneak peek, here is the action mapping for a JSF page that edits an > > employee: > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > index > > > > > > Notice the default page is the JSF page, but other navigation is handled > > by traditional Action 2 results. Incidently, this means only POSTs for > > real form submits and bookmarkable GETS everywhere else. > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > approach will solve the very popular need to combine the two frameworks > > in a seamless way for the user. I'm particularly interested in feedback > > from the JSF folks, as I'm pretty new to the framework. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
This post shows who the limited person is. It is you, Ma'am. On 5/21/06, Kimani Darisha <[EMAIL PROTECTED]> wrote: Oh wonderful, more comments from the list idiot. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > Who wants these frameworks combined? This is what has been killing Struts. > This is anything but a lofty goal. It is architectural suicide. There is > Shale, which could not really do this. Why is that not enough or in fact > way too much? This is ridiculous. I hope people on this list see this > effort for what it is. > > On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > After talking with several on this list about the possibility of > > combining the best of JSF and Action 2 in a unified framework from a > > user perspective, I have completed a first cut at JSF support in Action > > 2 with this loftly goal. > > > > From a user perspective, you still have one configuration file, > > struts-action.xml, which maps urls to actions and actions to results. > > However, you can optionally include the JSF interceptor stack and use > > the JSF result, allowing you to use JSF components in the view. You > > still define alternative results the same way, still have an action > > class per url, and can still use the normal GET-style navigation. > > > > From a framework perspective, I split the lifecycle class into > > indivudal Action 2 interceptors, one per phase. The final render phase > > I turned into a Result. Upon initialization, I replace the navigation > > handler with one that simply records outcomes as if they were result > > codes from an Action. Also, the setup inserts a variable resolver that > > exposes the action instance to the EL bindings. Therefore, the flow > > goes: determine action/namespace -> run normal interceptors -> run JSF > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > render phase. The purpose of the Action then becomes as a general setup > > for the page, much like the Shale pre-render hook. > > > > I chose this approach because I find the Action 2 controller stronger > > (JSF was always meant as a view tech, as I understand it), so think it > > better suited for navigation, state-less actions, and centralizing page > > setup code. JSF is better for complex single pages or page groups where > > different stateful components might be needing to submit the page > > without affecting others. > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > a sneak peek, here is the action mapping for a JSF page that edits an > > employee: > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > index > > > > > > Notice the default page is the JSF page, but other navigation is handled > > by traditional Action 2 results. Incidently, this means only POSTs for > > real form submits and bookmarkable GETS everywhere else. > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > approach will solve the very popular need to combine the two frameworks > > in a seamless way for the user. I'm particularly interested in feedback > > from the JSF folks, as I'm pretty new to the framework. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: This is an interesting question - do we want to include pre-built example webapps that are missing their LGPL deps? Or, would it be better not to build them at all? Regardless, showcase should be split up so we can ship a functional app with no LGPL problems. In r408472 I moved the showcase app to its own profile. To build it locally, enable *both* the extras and showcase profiles: mvn install -P extras,showcase Once the LGPL-dependent examples are removed from the showcase, it can be part of the normal build, and the 'extras' profile can build both struts-extras.jar and a separate extras example app. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Cool! Thanks :) Frank Don Brown wrote: You can inherit packages and their defined defaults. Therefore, in this case, you could define the default interceptor stack and result type for a root package then not have to specify it in any action configs of that package or child packages. Don Frank W. Zammetti wrote: A bit of a tangential question here... does Webwork support inheritance of some sort with regard to Action mappings? Or perhaps some sort of prototype? I think it's great that you can set things on a per-mapping basis, that makes things very flexible and powerful... but one can imagine where that leads to rather complex-looking config files... and I'm not sold on annotations yet, I'm still in the config file camp myself... still, configuring everything per mapping could get messy. If there is a way to have basically a prototype mapping that others can inherit from, that would eliminate that possibility, more or less. Just curious, because I've only done one Webwork project thus far, and it's relatively basic, so I didn't have a need for this capability. Frank Don Brown wrote: Frank W. Zammetti wrote: I've been historically pretty anti-JSF, so I hope this means something in light of that history: this is *very* interesting and I congratulate you on making it happen! I've had the same "I think it can be done" thoughts about mixing the two, just never actually did anything with the idea, so I'm happy that someone has, if for no other reason than to prove it can be done. Kudos! The one concern I have initially is about performance... as you describe, running through all the normal interceptors, and *then* going through the JSF phases, sounds like an awful lot of code to execute per request. I wonder about how well this will scale. Time will tell of course, but that is my one concern. This is why I left the JSF stack with just JSF phase interceptors and not including the whole default stack. This lets you mix and match at the action level, so if the action wanted the full action 2 stack plus JSF, it can, or it can just use the JSF phase interceptors. The full stack, or at least the params interceptor, is useful so that a page can accept an "id" parameter, then look up the data to be available in the JSF page later. In Action 2, nothing is forced an you, making it very easy to override or set other defaults as needed. Don Good work in any case Don, I look forward to seeing this polished! Frank Don Brown wrote: Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Agreed. Are we going to move XWork to Subversion for 2.0 or stick with
CVS for now?
Don
Jason Carreira wrote:
So on the plane home I was able to get some work done. Well, first I had to set
up lots of libraries for the extras and showcase modules, since maven didn't
set them up, but then I got some work done. (BTW, can we get that fixed, along
with the problems downloading libraries?)
So anyway, I did a lot of refactoring to make the ConfigurationManager in XWork
not use statics, and just have a static reference to a ConfigurationManager in
another class that should be easier to refactor later. I also, in the process,
started making XWork and the uses of it use 1.5 features, especially generics
and the enhanced for loop. It all builds and the tests pass in IDEA.
Unfortunately, when building with Maven, I get this (among many errors):
C:\dev\projects\saf\action\..\xwork\src\java\com\opensymphony\xwork\config\ConfigurationManager.java:[127,48]
for-each l
oops are not supported in -source 1.3
(try -source 1.5 to enable for-each loops)
for (ConfigurationProvider provider : configurationProviders) {
I tried to look at the pom.xml files to see where 1.3 is specified, but I
didn't see it right off.
Anyway, I think we should branch XWork now for 2.0, set it to depend on JDK
1.5, and we should make SAF2 use the XWork 2.0 snapshots. If / when we get that
set up I've got a bunch of stuff to check in to start on the new / improved
XWork.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31704&messageID=61341#61341
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
You can inherit packages and their defined defaults. Therefore, in this case, you could define the default interceptor stack and result type for a root package then not have to specify it in any action configs of that package or child packages. Don Frank W. Zammetti wrote: A bit of a tangential question here... does Webwork support inheritance of some sort with regard to Action mappings? Or perhaps some sort of prototype? I think it's great that you can set things on a per-mapping basis, that makes things very flexible and powerful... but one can imagine where that leads to rather complex-looking config files... and I'm not sold on annotations yet, I'm still in the config file camp myself... still, configuring everything per mapping could get messy. If there is a way to have basically a prototype mapping that others can inherit from, that would eliminate that possibility, more or less. Just curious, because I've only done one Webwork project thus far, and it's relatively basic, so I didn't have a need for this capability. Frank Don Brown wrote: Frank W. Zammetti wrote: I've been historically pretty anti-JSF, so I hope this means something in light of that history: this is *very* interesting and I congratulate you on making it happen! I've had the same "I think it can be done" thoughts about mixing the two, just never actually did anything with the idea, so I'm happy that someone has, if for no other reason than to prove it can be done. Kudos! The one concern I have initially is about performance... as you describe, running through all the normal interceptors, and *then* going through the JSF phases, sounds like an awful lot of code to execute per request. I wonder about how well this will scale. Time will tell of course, but that is my one concern. This is why I left the JSF stack with just JSF phase interceptors and not including the whole default stack. This lets you mix and match at the action level, so if the action wanted the full action 2 stack plus JSF, it can, or it can just use the JSF phase interceptors. The full stack, or at least the params interceptor, is useful so that a page can accept an "id" parameter, then look up the data to be available in the JSF page later. In Action 2, nothing is forced an you, making it very easy to override or set other defaults as needed. Don Good work in any case Don, I look forward to seeing this polished! Frank Don Brown wrote: Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Re: Cannot find a Spring Listener
Ted Husted wrote: Struts Action 1 does not utilizes Spring, but SAF2 uses Spring as its internal object factory by default, and, optionally, Shale can use Spring as a factory for managed beans. More precisely, SAF2 *can* use Spring as its internal object factory, and that is indeed the recommended factory (I believe it's even the default as of WW 2.2.2, not certain of this)... but it doesn't *have* to use it. It still, as of this moment, has its own object factory implementation that can be used instead... maybe that will be dropped by the time the first SAF2 release hits, I don't know. -Ted. Frank On 5/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Struts does not have Spring as a dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
A bit of a tangential question here... does Webwork support inheritance of some sort with regard to Action mappings? Or perhaps some sort of prototype? I think it's great that you can set things on a per-mapping basis, that makes things very flexible and powerful... but one can imagine where that leads to rather complex-looking config files... and I'm not sold on annotations yet, I'm still in the config file camp myself... still, configuring everything per mapping could get messy. If there is a way to have basically a prototype mapping that others can inherit from, that would eliminate that possibility, more or less. Just curious, because I've only done one Webwork project thus far, and it's relatively basic, so I didn't have a need for this capability. Frank Don Brown wrote: Frank W. Zammetti wrote: I've been historically pretty anti-JSF, so I hope this means something in light of that history: this is *very* interesting and I congratulate you on making it happen! I've had the same "I think it can be done" thoughts about mixing the two, just never actually did anything with the idea, so I'm happy that someone has, if for no other reason than to prove it can be done. Kudos! The one concern I have initially is about performance... as you describe, running through all the normal interceptors, and *then* going through the JSF phases, sounds like an awful lot of code to execute per request. I wonder about how well this will scale. Time will tell of course, but that is my one concern. This is why I left the JSF stack with just JSF phase interceptors and not including the whole default stack. This lets you mix and match at the action level, so if the action wanted the full action 2 stack plus JSF, it can, or it can just use the JSF phase interceptors. The full stack, or at least the params interceptor, is useful so that a page can accept an "id" parameter, then look up the data to be available in the JSF page later. In Action 2, nothing is forced an you, making it very easy to override or set other defaults as needed. Don Good work in any case Don, I look forward to seeing this polished! Frank Don Brown wrote: Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Re: Cannot find a Spring Listener
Struts Action 1 does not utilizes Spring, but SAF2 uses Spring as its internal object factory by default, and, optionally, Shale can use Spring as a factory for managed beans. -Ted. On 5/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Struts does not have Spring as a dependency. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
I am not opposed to having JSF and Action2 work together. If they can play together, and you can find a business case to parts of each in a project, I think that's a big win. As long as they can still be used separately, then I am +1. --- Bob Lee <[EMAIL PROTECTED]> wrote: > Don, this is *very* interesting. Nice work. I've been wondering for a > while if we could reuse off-the-shelf JSF components. It looks like > you may have figured out how! > > It also proves that you can think of the JSF lifecycle as a more > complex, higher level of abstraction of our interceptor lifecycle. > From my experience, it's a *lot* easier to reason about and maintain > the simpler interceptor lifecycle. > > Bob > > On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > After talking with several on this list about the possibility of > > combining the best of JSF and Action 2 in a unified framework from a > > user perspective, I have completed a first cut at JSF support in Action > > 2 with this loftly goal. > > > > From a user perspective, you still have one configuration file, > > struts-action.xml, which maps urls to actions and actions to results. > > However, you can optionally include the JSF interceptor stack and use > > the JSF result, allowing you to use JSF components in the view. You > > still define alternative results the same way, still have an action > > class per url, and can still use the normal GET-style navigation. > > > > From a framework perspective, I split the lifecycle class into > > indivudal Action 2 interceptors, one per phase. The final render phase > > I turned into a Result. Upon initialization, I replace the navigation > > handler with one that simply records outcomes as if they were result > > codes from an Action. Also, the setup inserts a variable resolver that > > exposes the action instance to the EL bindings. Therefore, the flow > > goes: determine action/namespace -> run normal interceptors -> run JSF > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > render phase. The purpose of the Action then becomes as a general setup > > for the page, much like the Shale pre-render hook. > > > > I chose this approach because I find the Action 2 controller stronger > > (JSF was always meant as a view tech, as I understand it), so think it > > better suited for navigation, state-less actions, and centralizing page > > setup code. JSF is better for complex single pages or page groups where > > different stateful components might be needing to submit the page > > without affecting others. > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > a sneak peek, here is the action mapping for a JSF page that edits an > > employee: > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > index > > > > > > Notice the default page is the JSF page, but other navigation is handled > > by traditional Action 2 results. Incidently, this means only POSTs for > > real form submits and bookmarkable GETS everywhere else. > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > approach will solve the very popular need to combine the two frameworks > > in a seamless way for the user. I'm particularly interested in feedback > > from the JSF folks, as I'm pretty new to the framework. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Frank W. Zammetti wrote: I've been historically pretty anti-JSF, so I hope this means something in light of that history: this is *very* interesting and I congratulate you on making it happen! I've had the same "I think it can be done" thoughts about mixing the two, just never actually did anything with the idea, so I'm happy that someone has, if for no other reason than to prove it can be done. Kudos! The one concern I have initially is about performance... as you describe, running through all the normal interceptors, and *then* going through the JSF phases, sounds like an awful lot of code to execute per request. I wonder about how well this will scale. Time will tell of course, but that is my one concern. This is why I left the JSF stack with just JSF phase interceptors and not including the whole default stack. This lets you mix and match at the action level, so if the action wanted the full action 2 stack plus JSF, it can, or it can just use the JSF phase interceptors. The full stack, or at least the params interceptor, is useful so that a page can accept an "id" parameter, then look up the data to be available in the JSF page later. In Action 2, nothing is forced an you, making it very easy to override or set other defaults as needed. Don Good work in any case Don, I look forward to seeing this polished! Frank Don Brown wrote: Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Maven Snapshots
Wendy Smoak wrote: I published snapshots with 'mvn deploy': http://people.apache.org/maven-snapshot-repository/org/apache/struts/action2/ What about 'extras'? It seems like the profile needs to be split up. Right now if I do 'mvn deploy -P extras' it's going to upload the both struts-extras.jar and the showcase .war. The former is fine (I think) but I assume the war would include dependencies with incompatible licenses in WEB-INF/lib. This is an interesting question - do we want to include pre-built example webapps that are missing their LGPL deps? Or, would it be better not to build them at all? Regardless, showcase should be split up so we can ship a functional app with no LGPL problems. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Maven Snapshots
I published snapshots with 'mvn deploy': http://people.apache.org/maven-snapshot-repository/org/apache/struts/action2/ What about 'extras'? It seems like the profile needs to be split up. Right now if I do 'mvn deploy -P extras' it's going to upload the both struts-extras.jar and the showcase .war. The former is fine (I think) but I assume the war would include dependencies with incompatible licenses in WEB-INF/lib. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
I've been historically pretty anti-JSF, so I hope this means something in light of that history: this is *very* interesting and I congratulate you on making it happen! I've had the same "I think it can be done" thoughts about mixing the two, just never actually did anything with the idea, so I'm happy that someone has, if for no other reason than to prove it can be done. Kudos! The one concern I have initially is about performance... as you describe, running through all the normal interceptors, and *then* going through the JSF phases, sounds like an awful lot of code to execute per request. I wonder about how well this will scale. Time will tell of course, but that is my one concern. Good work in any case Don, I look forward to seeing this polished! Frank Don Brown wrote: Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Jason Carreira wrote: Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) Heh, I know. After bragging about it after many beers at JavaOne, I figured it was time to put up or shut up :) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Exactly. SAF2 makes a great controller. Don, does this make SAF a full JSF implementation (minus the bundled components)? No, this requires a JSF implementation. For the example in showcase, I used MyFaces. The integration code, however, doesn't require any particular JSF implementation. If we were a full implementation, there would be a ton more code; not something I think we'd be interested in maintaining :) Don - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
> Don, this is *very* interesting. Nice work. I've been > wondering for a > while if we could reuse off-the-shelf JSF components. > It looks like > you may have figured out how! > > It also proves that you can think of the JSF > lifecycle as a more > complex, higher level of abstraction of our > interceptor lifecycle. > From my experience, it's a *lot* easier to reason > about and maintain > the simpler interceptor lifecycle. > > Bob > Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-) I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile. Don, does this make SAF a full JSF implementation (minus the bundled components)? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r408459 - in /struts/action2/trunk: action-api/pom.xml apps/pom.xml core/pom.xml extras/pom.xml pom.xml uber/pom.xml
Be sure to update and install from the top level of Action 2 to pick up the changed artifactId. svn up mvn install -P extras Also remove the old ide config files and re-generate them, for example with IDEA: rm project.i* mvn idea:idea -P extras -- Wendy On 5/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: wsmoak Date: Sun May 21 11:22:43 2006 New Revision: 408459 URL: http://svn.apache.org/viewvc?rev=408459&view=rev Log: Changed artifact id: 'project' -> 'struts-action2-parent'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
On 5/21/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
So on the plane home I was able to get some work done. Well, first I had
to set up lots of libraries for the extras and showcase modules, since maven
didn't set them up, but then I got some work done. (BTW, can we get that
fixed, along with the problems downloading libraries?)
So anyway, I did a lot of refactoring to make the ConfigurationManager in
XWork not use statics, and just have a static reference to a
ConfigurationManager in another class that should be easier to refactor
later. I also, in the process, started making XWork and the uses of it use
1.5 features, especially generics and the enhanced for loop. It all builds
and the tests pass in IDEA.
Unfortunately, when building with Maven, I get this (among many errors):
C:\dev\projects\saf\action\..\xwork\src\java\com\opensymphony\xwork\config\ConfigurationManager.java:[127,48]
for-each l
oops are not supported in -source 1.3
(try -source 1.5 to enable for-each loops)
for (ConfigurationProvider provider : configurationProviders)
{
I tried to look at the pom.xml files to see where 1.3 is specified, but I
didn't see it right off.
The compiler plugin defaults to JDK 1.3, so you need to add this in the
build/plugins section of the POM:
org.apache.maven.plugins
maven-compiler-plugin
1.5
1.5
--
Martin Cooper
Anyway, I think we should branch XWork now for 2.0, set it to depend on JDK
1.5, and we should make SAF2 use the XWork 2.0 snapshots. If / when we get
that set up I've got a bunch of stuff to check in to start on the new /
improved XWork.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31704&messageID=61341#61341
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot find a Spring Listener
Hmmm, I added the Spring dependency to the POMs used by the aplications on May 9 (r405529). I'm getting a general build failure on my own checkout right now, so I can't verify whether it's bundling the Spring JARs in the WARs, as it should. If it doesn't, for now, you may need to drop the Spring JARs in yourself. I've updated the wiki to stress that SAF2 is a "work in progress" right now. Not everything is going to work, and the documentation is both inconsistent and incomplete. If someone is just getting started with Action2/WebWork2, a better starting point might be WebWork 2.1, which is stable and production-ready. * http://www.opensymphony.com/webwork/ -Ted. On 5/21/06, Jason Lenhart <[EMAIL PROTECTED]> wrote: Thank you for your help. Sorry ... but I just want it to work ... and after 3 hours it gets a bit daunting and makes me just give up. I am just wondering why the spring web jar is not listed as a dependency on the wiki? My guess is that the jar that houses this class is packaged in Jetty already and this is why it works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Don, this is *very* interesting. Nice work. I've been wondering for a while if we could reuse off-the-shelf JSF components. It looks like you may have figured out how! It also proves that you can think of the JSF lifecycle as a more complex, higher level of abstraction of our interceptor lifecycle. From my experience, it's a *lot* easier to reason about and maintain the simpler interceptor lifecycle. Bob On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot find a Spring Listener
Struts does not have Spring as a dependency. --- Jason Lenhart <[EMAIL PROTECTED]> wrote: > Thank you for your help. Sorry ... but I just want it to work ... > and after 3 hours it gets a bit daunting and makes me just give up. > > I am just wondering why the spring web jar is not listed as a > dependency on the wiki? > > My guess is that the jar that houses this class is packaged in Jetty > already and this is why it works. > > > > On May 21, 2006, at 12:13 AM, Paul Benedict wrote: > > > This isn't a struts question. You will find it in > > www.springframework.org > > > > --- Jason Lenhart <[EMAIL PROTECTED]> wrote: > > > >> I am losing my mind ... where is this class located, in what jar: > >> > >>> org.springframework.web.context.ContextLoaderListener > >> > >> I cannot deploy the hello world app because Tomcat cannot find the > >> class. > >> > >> Any help is much appreciated, > >> > >> Jason > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
To anyone following these thread, please ignore this fool. He does not speak for anyone, and is only here to confuse people. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: I have seen no "very popular need". This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > After talking with several on this list about the possibility of > combining the best of JSF and Action 2 in a unified framework from a > user perspective, I have completed a first cut at JSF support in Action > 2 with this loftly goal. > > From a user perspective, you still have one configuration file, > struts-action.xml, which maps urls to actions and actions to results. > However, you can optionally include the JSF interceptor stack and use > the JSF result, allowing you to use JSF components in the view. You > still define alternative results the same way, still have an action > class per url, and can still use the normal GET-style navigation. > > From a framework perspective, I split the lifecycle class into > indivudal Action 2 interceptors, one per phase. The final render phase > I turned into a Result. Upon initialization, I replace the navigation > handler with one that simply records outcomes as if they were result > codes from an Action. Also, the setup inserts a variable resolver that > exposes the action instance to the EL bindings. Therefore, the flow > goes: determine action/namespace -> run normal interceptors -> run JSF > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > render phase. The purpose of the Action then becomes as a general setup > for the page, much like the Shale pre-render hook. > > I chose this approach because I find the Action 2 controller stronger > (JSF was always meant as a view tech, as I understand it), so think it > better suited for navigation, state-less actions, and centralizing page > setup code. JSF is better for complex single pages or page groups where > different stateful components might be needing to submit the page > without affecting others. > > To demonstrate this integration, I added a JSF tab to the showcase. As > a sneak peek, here is the action mapping for a JSF page that edits an > employee: > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > index > > > Notice the default page is the JSF page, but other navigation is handled > by traditional Action 2 results. Incidently, this means only POSTs for > real form submits and bookmarkable GETS everywhere else. > > I'm sure there is a lot of refinement to do, but I'm hoping this general > approach will solve the very popular need to combine the two frameworks > in a seamless way for the user. I'm particularly interested in feedback > from the JSF folks, as I'm pretty new to the framework. > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Oh wonderful, more comments from the list idiot. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: Who wants these frameworks combined? This is what has been killing Struts. This is anything but a lofty goal. It is architectural suicide. There is Shale, which could not really do this. Why is that not enough or in fact way too much? This is ridiculous. I hope people on this list see this effort for what it is. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > After talking with several on this list about the possibility of > combining the best of JSF and Action 2 in a unified framework from a > user perspective, I have completed a first cut at JSF support in Action > 2 with this loftly goal. > > From a user perspective, you still have one configuration file, > struts-action.xml, which maps urls to actions and actions to results. > However, you can optionally include the JSF interceptor stack and use > the JSF result, allowing you to use JSF components in the view. You > still define alternative results the same way, still have an action > class per url, and can still use the normal GET-style navigation. > > From a framework perspective, I split the lifecycle class into > indivudal Action 2 interceptors, one per phase. The final render phase > I turned into a Result. Upon initialization, I replace the navigation > handler with one that simply records outcomes as if they were result > codes from an Action. Also, the setup inserts a variable resolver that > exposes the action instance to the EL bindings. Therefore, the flow > goes: determine action/namespace -> run normal interceptors -> run JSF > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > render phase. The purpose of the Action then becomes as a general setup > for the page, much like the Shale pre-render hook. > > I chose this approach because I find the Action 2 controller stronger > (JSF was always meant as a view tech, as I understand it), so think it > better suited for navigation, state-less actions, and centralizing page > setup code. JSF is better for complex single pages or page groups where > different stateful components might be needing to submit the page > without affecting others. > > To demonstrate this integration, I added a JSF tab to the showcase. As > a sneak peek, here is the action mapping for a JSF page that edits an > employee: > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > index > > > Notice the default page is the JSF page, but other navigation is handled > by traditional Action 2 results. Incidently, this means only POSTs for > real form submits and bookmarkable GETS everywhere else. > > I'm sure there is a lot of refinement to do, but I'm hoping this general > approach will solve the very popular need to combine the two frameworks > in a seamless way for the user. I'm particularly interested in feedback > from the JSF folks, as I'm pretty new to the framework. > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XWork 2, JDK 1.5
So on the plane home I was able to get some work done. Well, first I had to set
up lots of libraries for the extras and showcase modules, since maven didn't
set them up, but then I got some work done. (BTW, can we get that fixed, along
with the problems downloading libraries?)
So anyway, I did a lot of refactoring to make the ConfigurationManager in XWork
not use statics, and just have a static reference to a ConfigurationManager in
another class that should be easier to refactor later. I also, in the process,
started making XWork and the uses of it use 1.5 features, especially generics
and the enhanced for loop. It all builds and the tests pass in IDEA.
Unfortunately, when building with Maven, I get this (among many errors):
C:\dev\projects\saf\action\..\xwork\src\java\com\opensymphony\xwork\config\ConfigurationManager.java:[127,48]
for-each l
oops are not supported in -source 1.3
(try -source 1.5 to enable for-each loops)
for (ConfigurationProvider provider : configurationProviders) {
I tried to look at the pom.xml files to see where 1.3 is specified, but I
didn't see it right off.
Anyway, I think we should branch XWork now for 2.0, set it to depend on JDK
1.5, and we should make SAF2 use the XWork 2.0 snapshots. If / when we get that
set up I've got a bunch of stuff to check in to start on the new / improved
XWork.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31704&messageID=61341#61341
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot find a Spring Listener
Thank you for your help. Sorry ... but I just want it to work ... and after 3 hours it gets a bit daunting and makes me just give up. I am just wondering why the spring web jar is not listed as a dependency on the wiki? My guess is that the jar that houses this class is packaged in Jetty already and this is why it works. On May 21, 2006, at 12:13 AM, Paul Benedict wrote: This isn't a struts question. You will find it in www.springframework.org --- Jason Lenhart <[EMAIL PROTECTED]> wrote: I am losing my mind ... where is this class located, in what jar: org.springframework.web.context.ContextLoaderListener I cannot deploy the hello world app because Tomcat cannot find the class. Any help is much appreciated, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
I have seen no "very popular need". This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Who wants these frameworks combined? This is what has been killing Struts. This is anything but a lofty goal. It is architectural suicide. There is Shale, which could not really do this. Why is that not enough or in fact way too much? This is ridiculous. I hope people on this list see this effort for what it is. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
[action2] Combining JSF and SAF2
After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
