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 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~ > > --------------------------------------------------------------------- > 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~
