AW: Where dose JSP works in JSF request lifecycle?

> So, how do you make sure that the right dynamic data gets > loaded so that the > page displays the right stuff? That's where Shale comes in > handy. If your > backing bean implements the ViewController interface, then > prerender() will > get called just before the JSP page is invoked. This

AW: Shale vs. Action framework Statistics

le to change that? Bernhard > -Ursprüngliche Nachricht- > Von: Ted Husted [mailto:[EMAIL PROTECTED] > Gesendet: Samstag, 4. März 2006 17:08 > An: Struts Users Mailing List > Betreff: Re: Shale vs. Action framework Statistics > > > On 3/4/06, Bernhard Slomin

Shale vs. Action framework Statistics

Hi, are there any download statistics availabe for Shale + the action framework? Could give a rough estimated about the popularity of both framworks. Thanks Bernhard Slominski - To unsubscribe, e-mail: [EMAIL PROTECTED] For

AW: AW: Disabling Back Button in IE

This problem is as old as the web browsers are, at the beginning browsers and http were just there to display static pages, not for building applications with it, so the back button was not a problem. But you get serious problems with that when building applications. But as Frank and Josh pointed,

AW: [Shale] API Stability vs. V1.0

> -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Craig > > Of course right now it's not possible to tell which release > it is or when > > this is. > > Not really at this point ... but feedback on that topic, as > well as general > usage comm

AW: [Shale] API Stability vs. V1.0

> -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Craig > McClanahan > > Shale follows the same version branding policy that the rest > of Struts does > (along with Tomcat and some other projects). An "x.y.z" > release is first > issued with

[Shale] API Stability vs. V1.0

Hi all, I am a bit confused about the versioning and the API stability. So the current Version of Shale is 1.0.1 (according to the API documentation), so a 1.0 version. However the API stability (http://struts.apache.org/struts-shale/api-stability.html) tell a different story, from the 32 package

AW: Forcing URL Rewriting over Cookies in an existing application .

riting, you might want to do that for security reason, because when using URL Rewriting the Session ID is in the address line and the cache, so a pssoble security risk. I think this should be contollable in a standard way and not container-specific. Bernhard > > -Original Message-

AW: Forcing URL Rewriting over Cookies in an existing application .

"cookies" > attribute in the below url(s): > > http://tomcat.apache.org/tomcat-4.0-doc/config/context.html > http://tomcat.apache.org/tomcat-5.0-doc/config/context.html > http://tomcat.apache.org/tomcat-5.5-doc/config/context.html > > Regards, > David > > -O

AW: Forcing URL Rewriting over Cookies in an existing application .

OT, but I'm interested, is this available im Tomcat too? Thanks Bernhard > -Ursprüngliche Nachricht- > Von: David G. Friedman [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 23. Januar 2006 17:08 > An: Struts Users Mailing List > Betreff: RE: Forcing URL Rewriting over Cookies in an existi

AW: Manipulating reques object ???? - urgent please

As Far as I know you can't manipulate the Request object. But what you can do is move the parameters into your own object and of course you can manilpulate that and set it as atrribute in the request. Bernhard > -Ursprüngliche Nachricht- > Von: Sony Thomas [mailto:[EMAIL PROTECTED] > Gese

AW: [OT] jsessionid

Hi, this comes up every so often, that people don't want the session id in the URL, so I put it in as request to change the spec, in order to be able to switch off URL rewriting: https://jsp-spec-public.dev.java.net/issues/show_bug.cgi?id=155, (BTW: I just realized that it belongs in the Servlet o

AW: How does Shale affect my Struts development

Hi Jim, don't make the following mistake: "I use Struts but I want to move on, so I have to use Shale!" Shale is build ON TOP of JSF, so to understand the benefit of Shale you have to know JSF. So the first question to ask yourself: "Do I want to move to JSF or is Struts just fine for me?" When

AW: validation error messages in JSF

You can use the Shale validation featrue. This supports client-side validation via javascript, it's also possible to switch off the server-side validation. Look at: http://struts.apache.org/struts-shale/features-commons-validator.html Cheers Bernhard > -Ursprüngliche Nachricht- > Von: JE

AW: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF

> -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Craig > > I'd be happy to answer any specific questions on points that > are in the > slides. > I realized that all features are documented except for the "Remoting" one http://struts.apache.or

AW: [OT] Re: Is JSF ready?

> -Ursprüngliche Nachricht- > Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > > On Wed, December 14, 2005 9:37 am, Bill Schneider said: > > On the other hand, JSF does make doing some simple things hard. > > I think this is actually an excellent point, and I was > thinking of it the >

AW: Strategy for javascript validation with i18n

If you want to try something new you can use AJAX in that way that your validation is done on the server but you still can have (more or less) instant javascript feedback without resubmitting the form. So you only have a thin javascript interface but your validation code is in Java on the server.

AW: [OT] JSF Interface Design - Is it Truly Limited?

> Have a look at the clay component from shale, as this supports this > type of development process more fully as you could then use the > generated HTML from the graphic artists directly, just add some ids > much like Tapestry does. > Did you take a look at Facelets? It's something like Tapestry

AW: [shale] Advantages of Shale over JSF alone

> > I read the features the details there but being new to JSF > too they just kind of blend in with JSF features. > > Shawn D. Garner > I think before looking at Shale closer start to work with JSF standalone, you will only see the benfeits of Shale if you know (the shortcomings) of JSF. E.g

AW: Shale timeline

Thanks, Ted that's really good! I quote that when someone asks me. I forward that to my boss too :-) Bernhard > -Ursprüngliche Nachricht- > Von: Ted Husted [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 8. November 2005 12:08 > An: Struts Users Mailing List > Betreff: Re: Shale timeline

AW: [Help] how to erase jsessionid in URL

I saw this question in the Tomcat mailing list every once in a while. The control of the session tracking machanism can't be controlled right now by the configuration. The spec should be changed to allow the user (in this case the "deployer") to control the mechanism of session tracking. If I don't

AW: Shale timeline

> -Ursprüngliche Nachricht- > Von: Rahul Akolkar [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 4. November 2005 17:55 > > > > > As far as I'm concerned, the feature work I wanted to see for a > > > 1.0.0release is complete > > > > In a nutshell, there are no dates (the process is driven b

AW: Shale timeline

Hi Craig, thanks a lot for the answer, that's really helpful! > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 3. November 2005 17:57 > As far as I'm concerned, the feature work I wanted to see for a > 1.0.0release is complete You don't want to come up with a specific

Shale timeline

Hi, does anyone know when the first release 1.0 of struts shale is expected? Are there any other milestone dates like alpha, beta versions? Thanks Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e