date:20051201


Gaet wrote:

Thanks Laurie,

It's exactly what I want but in fact I want to this in an ActionForm class.
And from and ActionForm, I can't access to getResources(..) method


 How to achieve that in an ActionForm? is it possible?

Hmm, in that case you may be out of luck; ActionMessage works by storing 
resource keys which then get resolved (looked up in a resource bundle) 
when the message is rendered. I'm not sure there's a way to get a 
resource bundle from an ActionForm instance -- unless you pass in a 
reference to the appropriate bundle in a setup action and store the form 
bean in session scope so the reference is still valid during subsequent 
requests, when you need to reference it.



Moreover, why to you define variable locale because you don't use it 
afterwhile...


Oops, I simplified the example code I posted and that was a left-over.

L.



Thank you very much!


 
  - Original Message - 
  From: Laurie Harper 
  To: user@struts.apache.org 
  Sent: Wednesday, November 30, 2005 11:36 PM

  Subject: Re: Parameter of ActionMessage...


  Gaet, ActionMessage doesn't support doing that lookup for you 
  automatically, but you can achieve what you want fairly easily:


 Locale locale = request.getLocale();
 String arg = getResources(request).getMessage(label.name);
 errors.add(ActionMessages.GLOBAL_MESSAGE,
   new ActionMessage(error.field.mandatory, arg));

  L.

  Gaet wrote:
   Thanks Martin,
   
   But I want to prepare the error message in the action tag because after, in my JSP, I loop over my errors with html:messages tag...
   
   I don't know if I'm clear, but if I write the following code :
   
   errors.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage(error.field.mandatory,label.name));
   
   The result will be The field label.name is mandatory
   
   but I would like 'label.name' replaced by its value defined in the resource propertiesin order to have the result The field Your Name is mandatory
   
   Thanks!

 - Original Message - 
 From: Martin Gainty 
 To: Struts Users Mailing List 
 Sent: Wednesday, November 30, 2005 4:47 PM

 Subject: Re: Parameter of ActionMessage...
   
   
 Bonjour gaet-
   
 the current implementation supports passing in parameters to the 
 bean:message tag at runtime e.g.

 bean:message key=label.welcome arg0=Firstname/
   
 which will produce

 The field 'Firstname' is mandatory
   
 HTH,

 M-
 - Original Message - 
 From: Gaet [EMAIL PROTECTED]

 To: Struts Users Mailing List user@struts.apache.org
 Sent: Wednesday, November 30, 2005 9:29 AM
 Subject: Re: Parameter of ActionMessage...
   
   
  Nobody knows?

 
  Thanks for your time...
 
  - Original Message - 
  From: Gaet

  To: Mailing List Struts
  Sent: Wednesday, November 30, 2005 12:14 PM
  Subject: Parameter of ActionMessage...
 
 
  Hi the list!
 
  Is it possible to give a key of the ressources.properties in parameter of 
  an

  ActionMessage?
 
  Example :
  --
 
  # In Struts Action file
 errors.add(ActionMessages.GLOBAL_MESSAGE, new
  ActionMessage(error.field.mandatory,label.name));
 
  # In ressources.properties  file
 error.field.mandatory = The field '{0}' is mandatory
 label.name = Your Name
 
  I want the following result :  The field 'Your Name' is mandatory
 
 
  Thanks for your help!
 
 
  -
  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]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Repost:- Accessing an array from within a JSP


Mon Cab wrote:

Sorry. The formatting was messed up on my first post.  Hopefully this
is better

I am trying to define a string array as a property of DynaValidatorForm
in my struts config file and then access that array from within a JSP 
but am getting an incompatible types error when trying to do this.   
My frorm bean definition is as follows:


form-bean   
   name=myDynaActionForm 
   type=org.apache.struts.validator.DynaValidatorForm

form-property   
   name=string_array
   type=java.lang.String[]/
/form-bean

In my JSP (MyJSP.jsp) I wrote:

bean:define 
   id=string_array 
   name=myDynaActionForm 
   property=string_array/

%@ include file=Nested.jsp %

And then in my Nested.jsp I tried to access the array as follows:

Object [] stringArray = string_array;

When I try load the page I get the following error (written to
stdout.log):

An error occurred at line: 6 in the jsp file: /Nested.jsp
Generated servlet error:

C:\Tomcat Home\MyJSP_jsp.java:211: incompatible types
found   : java.lang.Object
required: java.lang.Object[]
Object [] stringArray = string_array;
  
Am I doing this wrong? How should I be doing this?


Did you try specifying the 'type' attribute in your bean:define tag? Not 
sure if that's the problem, but it might help. Or, perhaps, an explicit 
cast on the assignment in your scriptlet code.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to prevent URL cached

2005-12-01 Thread info3853 Bush

 I noticed that in many web applications,  after you logout from the 
application, you can still use the browser  back button to view some pages 
you supposely shouldn't. Some web  applications, like gmail, if you logout, and 
click the back, it will  always redirect the page to the login page. Some other 
applications,  even like ameritrade, it will allow you to view some static 
content  just visited.
  
  My question is that if there is any easy way in struts to configure  after 
you logout from application, using browser back button will  always direct 
you to the login page.
  


-
 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

Re: DispatchAction parameter getting dropped by IE

2005-12-01 Thread Nick Heudecker

Now I'm thinking this has something to do with the charset not getting
set in IE.  Users are copying and pasting content from Word into
textareas and getting this error.

Is it possible Tomcat can't parse the incoming form data and nothing
gets passed to the Action?

On 12/1/05, Nick Heudecker [EMAIL PROTECTED] wrote:
 Occasionally, one my my users will receive the following error message:

 javax.servlet.ServletException: Request[/foo] does not contain handler
 parameter named 'p'.  This may be caused by whitespace in the label text.

 There isn't any whitespace in the label text, and this only occurs
 with IE.  It's like none of the form properties are submitted.  Has
 anyone else experienced this and discovered a solution?

 Thanks.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SV: Re: checkbox for nested collection

2005-12-01 Thread Per Jørgen Walstrøm

hello,
you are right, I do have access to the POJO and the properties and I am able to 
pre-populate the form. However, the checkboxes are rendered dynamically in the 
jsp from the getRestrictive() method of my GeSectionComponent. I can't really 
set them all to false beforehand, because then they would not be populated 
right, I guess... Don't know if I'm making myself clear, but I can't see how I 
can reset my checkboxes without resetting the actual properties. Should I try 
to use a multibox with an array of dynamic size (i.e. a size which depends on 
the size of the geSectionComponents-Collection)?

/pj

-Opprinnelig melding-
Fra: Laurie Harper [mailto:[EMAIL PROTECTED] 
Sendt: 1. desember 2005 00:03
Til: user@struts.apache.org
Emne: Re: checkbox for nested collection

Per Jørgen Walstrøm wrote:
 hello,
 I have the following code in my jsp:
 
 nested:iterate id=sectionComponent property=geSectionComponents
   nested:checkbox property=restrictive/ /nested:iterate
 
 my Collection geSectionComponents contains objects of type 
 GeSectionComponent
 
 GeSectionComponent.java (an auto-generated Hibernate POJO), contains the 
 following field (with getter and setter):
 private Boolean restrictive;
 
 How do I go about to make sure Struts detects when I uncheck a checkbox? I am 
 aware of that I should set all corresponding boolean properties to false in 
 the reset()-method, but in this case I do not have any direct access to those 
 properties.
 
 any suggestions?

What do you mean you don't have any direct access to those properties? 
You must be creating a reference to that object (or retrieving one through 
Hibernate) somewhere in your code. Assuming you're storing the POJO in your 
form bean as part of pre-population, you can then access it in your reset() 
method.

L.




-
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: DispatchAction parameter getting dropped by IE

I've seen sporadic problems along these lines over the past two years with
an app I have, and it's an IE-only app.  I've never been able to track it
down, but it's been fairly rare so I haven't gone nuts trying either :)

Same kind of symptoms though... logs seem to indicate request parameters
were not present in the Action, but based on how the app works that should
be an impossibility.

If you figure it out, let me know, I'd be very thankful! :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]

On Thu, December 1, 2005 12:45 pm, Nick Heudecker said:
 Now I'm thinking this has something to do with the charset not getting
 set in IE.  Users are copying and pasting content from Word into
 textareas and getting this error.

 Is it possible Tomcat can't parse the incoming form data and nothing
 gets passed to the Action?

 On 12/1/05, Nick Heudecker [EMAIL PROTECTED] wrote:
 Occasionally, one my my users will receive the following error message:

 javax.servlet.ServletException: Request[/foo] does not contain handler
 parameter named 'p'.  This may be caused by whitespace in the label
 text.

 There isn't any whitespace in the label text, and this only occurs
 with IE.  It's like none of the form properties are submitted.  Has
 anyone else experienced this and discovered a solution?

 Thanks.


 -
 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: How to prevent URL cached

2005-12-01 Thread info3853 Bush

That's true. This topic belongs to web application security.
   
  The thing is that all static content are shown when you used the back 
button. Of course, you can't click any link since the session is already 
invalidated.
   
  Normally, you do all access control through the BaseAction class since all 
actions are dispached somehow from there. If you have a struts application, you 
can send a request something like:
  http://yourapplication/XXX.do and XXX is configured in your 
struts-config.xml, then you will see what happened. There will have some
  kind of exceptions throw out , but not a proper message like page not 
existed, etc. 

Laurie Harper [EMAIL PROTECTED] wrote:
  info3853 Bush wrote:
 I noticed that in many web applications, after you logout from the 
 application, you can still use the browser back button to view some pages 
 you supposely shouldn't. Some web applications, like gmail, if you logout, 
 and click the back, it will always redirect the page to the login page. Some 
 other applications, even like ameritrade, it will allow you to view some 
 static content just visited.
 
 My question is that if there is any easy way in struts to configure after you 
 logout from application, using browser back button will always direct you 
 to the login page.

As with any web application, Struts-based or otherwise, you need to 
secure the content you don't want to be re-visitable after logout, and 
make sure that as part of your logout processing you invalidate the 
current session and any authentication credentials you have stored 
elsewhere.

For example, you could have a check on each request for an 
'authenticated' token or flag in the session and if it's not present, 
redirect to a login page.

Unfortunately, there's too many ways to approach this kind of thing to 
list here. Which are appropriate depend on your requirements. Try 
googling for 'web application security', you'll find *lots* of further 
reading on the topic.

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  



-
 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

[struts-faces] weird JSPException converting Tiles layout

Having successfully converted a couple of tile JSPs to JSF, I just tried 
converting a layout. I'm getting a really weird behaviour which I can't 
explain... It *looks* like Tiles is closing the response stream in spite 
of flush=false, but if that were the case I'd expect the following 
exception to occur sooner in the generated servlet.


Here's the relevant snippet of the layout JSP:

  ...
  f:subview id=foo
!--t:get name=content flush=false/--
t:insert name=content flush=false/
  /f:subview

  jsp:scriptletSystem.out.println(layout 4);/jsp:scriptlet

  br /br /br /br /br /br /

  /body
/s:html
  jsp:scriptletSystem.out.println(layout 5);/jsp:scriptlet
  /f:view
  /jsp:root

The exception is thrown from s:view's doEndTag but, looking at the 
servlet, I see this:


...
if (_jspx_meth_f_subview_0(_jspx_th_s_html_0, 
_jspx_page_context))

  return;
System.out.println(layout 4);
out.write(br/);
out.write(br/);
out.write(br/);
out.write(br/);
out.write(br/);
out.write(br/);
out.write(/body);
  }
  if (_jspx_th_s_html_0.doEndTag() == 
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)

return;
  ...

I do see 'layout 4' traced to stdout, so the series of calls to 
out.write() must be getting executed and doesn't result in an exception, 
as I would expect if the response had been closed at that point. But 
there's nothing between them and the call to s:view's doEndTag so, 
unless it's the s:view tag that's closing the stream, why do I end up 
with an exception?


And if it is Tiles that's closing the response, how do I make it *not* 
do that?


Oh, just for completeness, here's the relevant snips of tiles-defs.xml:

definition name=.core.layout path=/pages/core/layout.faces
put name=title value=PAGE TITLE/
put name=stylesheet value=PAGE STYLE/
put name=section value=SITE SECTION/
put name=content value=PAGE CONTENT/
/definition

definition name=.projects.layout extends=.core.layout
put name=section value=projects/
put name=stylesheet value=/pages/projects/project-style.css/
/definition

definition name=.projects.list extends=.projects.layout
put name=content value=/pages/projects/Projects.jsp/
/definition

And here's the exception:

layout 4
ERROR [http-8080-Processor24] 
ContainerBase.[Catalina].[localhost].[/].[jsp] - Servlet.service() for 
servlet jsp threw exception

java.io.IOException: Stream closed
	at 
org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:203)

at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:311)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
	at 
org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl.endElement(HtmlResponseWriterImpl.java:243)
	at 
org.apache.struts.faces.renderer.HtmlRenderer.encodeEnd(HtmlRenderer.java:110)
	at 
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331)

at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253)
	at 
org.apache.jsp.pages.core.layout_jsp._jspService(org.apache.jsp.pages.core.layout_jsp:337)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)

at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
	at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
	at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
	at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
	at 
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
	at 
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
	at 
org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:130)
	at 
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
	at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at

Re: SV: Re: checkbox for nested collection

The trick is understanding the request processing life-cycle. The
following is the sequence of events:

- Struts either instantiates the action form or, if you use session
scoped forms and one already exists, retrieves it from the session

- Struts calls reset() on the form (I *think* in all cases, but it
may only do this when retrieving a form from session scope)

- if this request is a form submit, the form data is stored into
the form bean

- Struts calls your action, passing in the form bean

- In your pre-populate action, you would set the boolean properties
in the form ready for display; in your form processing action, you
would read their state reflecting the request data

- You return a forward mapping that Struts uses to render the next
view

So, you set everything to false in reset(); *after* that, your setup
action gets the opportunity to set the properties as appropriate for
display. On the next request, when the form is submitted, reset() is
called which clears the boolean properties and then they're updated
based on the form data.

Per Jørgen Walstrøm wrote:

hello,
you are right, I do have access to the POJO and the properties and I am able to
pre-populate the form. However, the checkboxes are rendered dynamically in the
jsp from the getRestrictive() method of my GeSectionComponent. I can't really
set them all to false beforehand, because then they would not be populated
right, I guess... Don't know if I'm making myself clear, but I can't see how I
can reset my checkboxes without resetting the actual properties. Should I try
to use a multibox with an array of dynamic size (i.e. a size which depends on
the size of the geSectionComponents-Collection)?

/pj

-Opprinnelig melding-
Fra: Laurie Harper [mailto:[EMAIL PROTECTED]
Sendt: 1. desember 2005 00:03

Til: user@struts.apache.org
Emne: Re: checkbox for nested collection

Per Jørgen Walstrøm wrote:

hello,
I have the following code in my jsp:

nested:iterate id=sectionComponent property=geSectionComponents
nested:checkbox property=restrictive/ /nested:iterate

my Collection geSectionComponents contains objects of type
GeSectionComponent

GeSectionComponent.java (an auto-generated Hibernate POJO), contains the
following field (with getter and setter):
private Boolean restrictive;

How do I go about to make sure Struts detects when I uncheck a checkbox? I am
aware of that I should set all corresponding boolean properties to false in the
reset()-method, but in this case I do not have any direct access to those
properties.

any suggestions?

What do you mean you don't have any direct access to those properties?
You must be creating a reference to that object (or retrieving one through Hibernate) somewhere in your code. Assuming you're storing the POJO in your form bean as part of pre-population, you can then access it in your reset() method.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Somewhat OT] JSTL problem in Websphere

I'm trying to deploy a Struts-based app to Websphere (5.1 I believe) that
is now using JSTL in most places.  I have jstl.jar and standard.jar in
WEB-INF/LIB (both versions 1.1.2).  On my page I have:

%@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %

This matches the URI in the fmt.tld in standard.jar.  I previously had:

%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %

Now, BOTH of those worked under Tomcat, but under Websphere I'm seeing:

Error 500: File http://java.sun.com/jsp/jstl/fmt; not found

Same thing for both, with the applicable URI of course.  What bit of
stupidity am I committing here?  Thanks!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DispatchAction parameter getting dropped by IE

2005-12-01 Thread Nick Heudecker

I found this link
(http://www.crazysquirrel.com/computing/general/form-encoding.jspx)
and, after adding the accept-charset and the hidden field, it fixed
it.


On 12/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
 I've seen sporadic problems along these lines over the past two years with
 an app I have, and it's an IE-only app.  I've never been able to track it
 down, but it's been fairly rare so I haven't gone nuts trying either :)

 Same kind of symptoms though... logs seem to indicate request parameters
 were not present in the Action, but based on how the app works that should
 be an impossibility.

 If you figure it out, let me know, I'd be very thankful! :)

 --
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 AIM: fzammetti
 Yahoo: fzammetti
 MSN: [EMAIL PROTECTED]

 On Thu, December 1, 2005 12:45 pm, Nick Heudecker said:
  Now I'm thinking this has something to do with the charset not getting
  set in IE.  Users are copying and pasting content from Word into
  textareas and getting this error.
 
  Is it possible Tomcat can't parse the incoming form data and nothing
  gets passed to the Action?
 
  On 12/1/05, Nick Heudecker [EMAIL PROTECTED] wrote:
  Occasionally, one my my users will receive the following error message:
 
  javax.servlet.ServletException: Request[/foo] does not contain handler
  parameter named 'p'.  This may be caused by whitespace in the label
  text.
 
  There isn't any whitespace in the label text, and this only occurs
  with IE.  It's like none of the form properties are submitted.  Has
  anyone else experienced this and discovered a solution?
 
  Thanks.
 
 
  -
  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: How to prevent URL cached

On 12/1/05, info3853 Bush [EMAIL PROTECTED] wrote:
 That's true. This topic belongs to web application security.

   The thing is that all static content are shown when you used the back 
 button. Of course, you can't click any link since the session is already 
 invalidated.

Mark page as non-cachable with no-cache, no-store cache-control
header. You may want to add some other headers too, like
must-revalidate. When you hit Back, the browser would try to reload a
page, here you would show the error.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Somewhat OT] JSTL problem in Websphere

2005-12-01 Thread Nick Sophinos

We had a similar problem with Jetty and had to resort to referencing the taglib
via a file path to the tld file. These files come with the download of JSTL.

- Nick


On 12/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
 I'm trying to deploy a Struts-based app to Websphere (5.1 I believe) that
 is now using JSTL in most places.  I have jstl.jar and standard.jar in
 WEB-INF/LIB (both versions 1.1.2).  On my page I have:

 %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %

 This matches the URI in the fmt.tld in standard.jar.  I previously had:

 %@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %

 Now, BOTH of those worked under Tomcat, but under Websphere I'm seeing:

 Error 500: File http://java.sun.com/jsp/jstl/fmt; not found

 Same thing for both, with the applicable URI of course.  What bit of
 stupidity am I committing here?  Thanks!

 --
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 AIM: fzammetti
 Yahoo: fzammetti
 MSN: [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: [Somewhat OT] JSTL problem in Websphere

Wendy, there's no other way to say this, so I'll just say it... You kick
all manner of a**!

That was exactly it, thanks for saving me an hours' worth of banging my
head on the desk!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]

On Thu, December 1, 2005 2:00 pm, Wendy Smoak said:
 On 12/1/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
 I'm trying to deploy a Struts-based app to Websphere (5.1 I believe)
 that
 is now using JSTL in most places.  I have jstl.jar and standard.jar in
 WEB-INF/LIB (both versions 1.1.2).  On my page I have:

 Is WebSphere 5.1 a Servlet 2.4 container?  (A quick looks seems to
 indicate it's J2EE 1.3 - Servlet 2.3.)  So you'd need JSTL 1.0 and
 the URI's without the 'jsp' in them.

 --
 Wendy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Somewhat OT] JSTL problem in Websphere

2005-12-01 Thread Karr, David

I believe that Websphere 5 is not a JSP 2.0 container (Websphere 6 is).
Assuming that's true, you have to use the 1.0.x versions of the JSTL.
Version 1.1.x is used in JSP 2.0 containers.  You'll also have to make
sure the taglib uri matches the one in the TLD file in the taglib jar
(it's different between 1.0.x and 1.1.x).

 -Original Message-
 From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, December 01, 2005 10:53 AM
 To: user@struts.apache.org
 Subject: [Somewhat OT] JSTL problem in Websphere

 I'm trying to deploy a Struts-based app to Websphere (5.1 I 
 believe) that is now using JSTL in most places.  I have 
 jstl.jar and standard.jar in WEB-INF/LIB (both versions 
 1.1.2).  On my page I have:

 %@ taglib prefix=fmt uri=http://java.sun.com/jsp/jstl/fmt; %

 This matches the URI in the fmt.tld in standard.jar.  I 
 previously had:

 %@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %

 Now, BOTH of those worked under Tomcat, but under Websphere 
 I'm seeing:

 Error 500: File http://java.sun.com/jsp/jstl/fmt; not found

 Same thing for both, with the applicable URI of course.  What 
 bit of stupidity am I committing here?  Thanks!

 -- 
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 AIM: fzammetti
 Yahoo: fzammetti
 MSN: [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: [Definitely OT] JSTL problem in Websphere

2005-12-01 Thread Dave Newton


Frank W. Zammetti wrote:


What bit of stupidity am I committing here?


Using Websphere.

But seriously, folks...

We didn't see that error, but we were on a different version, and the 
configuration they were using was twisted anyway. No help here. Really I 
just wanted to say the jokey bit.


Dave



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to prevent URL cached

2005-12-01 Thread info3853 Bush

Yes, I did that. Now all pages are blank. What I really wish is that after 
logout, when user hit back button, the page goes back to login page, never 
visit all pages visited before even just blank page now.

Michael Jouravlev [EMAIL PROTECTED] wrote:  On 12/1/05, info3853 Bush wrote:
 That's true. This topic belongs to web application security.

 The thing is that all static content are shown when you used the back 
 button. Of course, you can't click any link since the session is already 
 invalidated.

Mark page as non-cachable with no-cache, no-store cache-control
header. You may want to add some other headers too, like
must-revalidate. When you hit Back, the browser would try to reload a
page, here you would show the error.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
 Yahoo! Personals
 Single? There's someone we'd like you to meet.
 Lots of someones, actually. Try Yahoo! Personals

Re: [Definitely OT] JSTL problem in Websphere


Dave Newton wrote:

Frank W. Zammetti wrote:


What bit of stupidity am I committing here?


Using Websphere.


You won't get any disagreement from me :)  I wish I had any kind of 
choice in the matter, but you know how it goes in big business when 
deals are made.


Now it looks like ActionServlet isn't initializing, even though it works 
perfectly on Tomcat... probably some stupid problem with the resource 
bundle (hey, it's in WEB-INF/classes, but I'm deploying an EAR... that 
sounds like the recipe for a disaster to me with Websphere involved). 
But that's a problem for tomorrow :)


Frank

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to prevent URL cached

2005-12-01 Thread Simons Kevin

just an opinion...perhaps you can check whether the user has hit the back 
button. When he hits the button you might run the code that check's whether 
a user was logged in or not. If not...load the login page.


I do know that you can use javascript to replace the history goback(). I 
don't know whether this is possible with struts.
- Original Message - 
From: info3853 Bush [EMAIL PROTECTED]

To: Struts Users Mailing List user@struts.apache.org
Sent: Thursday, December 01, 2005 8:32 PM
Subject: Re: How to prevent URL cached


Yes, I did that. Now all pages are blank. What I really wish is that after 
logout, when user hit back button, the page goes back to login page, 
never visit all pages visited before even just blank page now.


Michael Jouravlev [EMAIL PROTECTED] wrote:  On 12/1/05, info3853 Bush 
wrote:

That's true. This topic belongs to web application security.

The thing is that all static content are shown when you used the back 
button. Of course, you can't click any link since the session is already 
invalidated.


Mark page as non-cachable with no-cache, no-store cache-control
header. You may want to add some other headers too, like
must-revalidate. When you hit Back, the browser would try to reload a
page, here you would show the error.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
Yahoo! Personals
Single? There's someone we'd like you to meet.
Lots of someones, actually. Try Yahoo! Personals






No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 30/11/2005



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 30/11/2005


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Proper way of doing internationalization

2005-12-01 Thread Aladin Alaily

Hello,

In internationalizing a struts-tiles application, in your opinion, is it
better to internationalize the properties file or the tiles configuration
file? and why?

Thanks for you thoughts.

Aladin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to prevent URL cached

Did you say pages are static (HTML)? Or they are JSPs? Or does request
pass through Struts action? If they are not plain HTML, then in your
action or in JSP page check if user is logged in. If not, redirect to
login page.

Here is the simple scriptlet, that you should stick in the beginning
of every session-related page:

%
   if (session.getAttribute(USER) == null) {
   response.sendRedirect(Login.do);
   }
%

Or you may want to write a guard tag, see Ted Husted's MailReader
sample application for details. Or you may want to write a servlet
filter.

Michael.

On 12/1/05, info3853 Bush [EMAIL PROTECTED] wrote:
 Yes, I did that. Now all pages are blank. What I really wish is that after 
 logout, when user hit back button, the page goes back to login page, never 
 visit all pages visited before even just blank page now.

 Michael Jouravlev [EMAIL PROTECTED] wrote:  On 12/1/05, info3853 Bush wrote:
  That's true. This topic belongs to web application security.
 
  The thing is that all static content are shown when you used the back 
  button. Of course, you can't click any link since the session is already 
  invalidated.

 Mark page as non-cachable with no-cache, no-store cache-control
 header. You may want to add some other headers too, like
 must-revalidate. When you hit Back, the browser would try to reload a
 page, here you would show the error.

 Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proper way of doing internationalization

2005-12-01 Thread Martin Gainty

Have you looked at cedric dumoulin's SelectLocaleAction class switching on 
request.getParameter(language) initialised by

putList...
 add value=lang.do?language=FR/
 add value=lang.do?language=VI/
which then sets the User Locale Attribute
at
http://www.lifl.fr/~dumoulin/tiles/doc/tutorialBody.html#_Toc521292392

Note the use of WEB-INF/componentDefinitions_language.xml instead of 
ApplicationResources_language.properties

HTH,
Martin-
- Original Message - 
From: Aladin Alaily [EMAIL PROTECTED]

To: user@struts.apache.org
Sent: Thursday, December 01, 2005 3:24 PM
Subject: Proper way of doing internationalization



Hello,

In internationalizing a struts-tiles application, in your opinion, is it
better to internationalize the properties file or the tiles configuration
file? and why?

Thanks for you thoughts.

Aladin

-
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: How to prevent URL cached

Or use container managed security (which, I think, can be used for 
static as well as dynamic content?)... Like I said, there are a lot of 
options... ;-)


Michael Jouravlev wrote:

Did you say pages are static (HTML)? Or they are JSPs? Or does request
pass through Struts action? If they are not plain HTML, then in your
action or in JSP page check if user is logged in. If not, redirect to
login page.

Here is the simple scriptlet, that you should stick in the beginning
of every session-related page:

%
   if (session.getAttribute(USER) == null) {
   response.sendRedirect(Login.do);
   }
%

Or you may want to write a guard tag, see Ted Husted's MailReader
sample application for details. Or you may want to write a servlet
filter.

Michael.

On 12/1/05, info3853 Bush [EMAIL PROTECTED] wrote:

Yes, I did that. Now all pages are blank. What I really wish is that after logout, when 
user hit back button, the page goes back to login page, never visit all pages 
visited before even just blank page now.

Michael Jouravlev [EMAIL PROTECTED] wrote:  On 12/1/05, info3853 Bush wrote:

That's true. This topic belongs to web application security.

The thing is that all static content are shown when you used the back button. 
Of course, you can't click any link since the session is already invalidated.



Mark page as non-cachable with no-cache, no-store cache-control
header. You may want to add some other headers too, like
must-revalidate. When you hit Back, the browser would try to reload a
page, here you would show the error.

Michael.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proper way of doing internationalization


Aladin Alaily wrote:

Hello,

In internationalizing a struts-tiles application, in your opinion, is it
better to internationalize the properties file or the tiles configuration
file? and why?


You'll need to do both, as each serves a different purpose. Depending on 
your precise needs you may not need much localization of tiles 
configuration -- you'd do that if you wanted to vary the actual layout 
according to locale, or include specific 'chunks' of markup only for 
certain locales, for example.


For just displaying different translations of natural text (labels, 
messages, etc.) you would usually use just one view (JSP) with separate 
properties files (resource bundles) for each supported locale.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[FRIDAY] Struts 1.x is Struts Classic after all

Maybe I do not know how to do business. Heck, I do not have MBA. But
for some reason I have a sour taste in the mouth. If
StrutsTi/Struts2.0 is so heavily based on WebWork code that one did
put an equal sign between the two, then Struts2.0 is not Struts
anymore. It would be honest just to say that Struts ran out of steam,
it is crusty, it sucks, its development is concluded and everyone is
welcomed to switch to shiny WebWork. I would get that. I would accept
that. At least I won't feel being fooled.

In case of DaimlerChrysler one has an option to go and buy an original
product. There is no such an option in Struts/WebWork case. How do you
think you will explain to those who know that Struts sucks that
Struts 2.0 is not Struts 1.x they knew (or actually did not know)
before? Will you be telling them that this is actually WebWork, which
is so much better? Now that would be fun.

I have nothing against WebWork, I had looked into it once or twice, it
is surely a nice framework, but I will not buy WebWork skinned as
Struts.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread bsimonin


I think Struts is pretty cool.  But JSF seems to be the future so I am now 
learning it.  But I am getting really confused about Shale versus pure JSF 
versus Struts.  Maybe Craig McClanahan can give me some more insite into what I 
should be learning for my next Java based web project. Is JSF the future? And 
if it is which JSF should I be learning?  

--Brad 

-Original Message-
From: Michael Jouravlev [mailto:[EMAIL PROTECTED]
Sent: Thu 12/1/2005 6:47 PM
To: Struts Users Mailing List
Subject: [FRIDAY] Struts 1.x is Struts Classic after all
 
Maybe I do not know how to do business. Heck, I do not have MBA. But
for some reason I have a sour taste in the mouth. If
StrutsTi/Struts2.0 is so heavily based on WebWork code that one did
put an equal sign between the two, then Struts2.0 is not Struts
anymore. It would be honest just to say that Struts ran out of steam,
it is crusty, it sucks, its development is concluded and everyone is
welcomed to switch to shiny WebWork. I would get that. I would accept
that. At least I won't feel being fooled.

In case of DaimlerChrysler one has an option to go and buy an original
product. There is no such an option in Struts/WebWork case. How do you
think you will explain to those who know that Struts sucks that
Struts 2.0 is not Struts 1.x they knew (or actually did not know)
before? Will you be telling them that this is actually WebWork, which
is so much better? Now that would be fun.

I have nothing against WebWork, I had looked into it once or twice, it
is surely a nice framework, but I will not buy WebWork skinned as
Struts.

Michael.

-
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: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Don Brown

While you are certainly entitled to your opinion, I'd ask that you reserve
judgement until at least the first Struts Ti release.  Yes, we plan to seed
Struts Ti with WebWork 2.2, but that doesn't mean it will stay that way or
that Struts Action 1.x users and even code aren't important.  I just started
working on the Struts Action 1.x compatibility layer tonight so its too
early to say, but my goal is to be able to run most Struts Action
1.xapplications unchanged on Struts Ti.  Struts Ti was born with the
idea of
filling the gap between a new development frame of mind with JSF and Struts
Action 1.x, providing Struts developers a powerful new framework that
leverages their Struts knowledge, not negates it.

Furthermore, it has been said before and I'll say it again - Struts Action
1.x isn't going anywhere.  Just as development continued when Shale was
born, development will continue today.  I have at least one major Struts
Action 1.x application myself that will never see a rewrite, so if for some
reason Struts Ti doesn't have full Struts Action 1.x compatibility, it'll
stay on the stable, supported Struts Action 1.x.

This is open source - if you are convinced Struts Action 1.x is the one true
way, feel free to jump in and contribute.  Just because Struts Ti may be
right for me, it may not be for you.

Don

On 12/1/05, Michael Jouravlev [EMAIL PROTECTED] wrote:

 Maybe I do not know how to do business. Heck, I do not have MBA. But
 for some reason I have a sour taste in the mouth. If
 StrutsTi/Struts2.0 is so heavily based on WebWork code that one did
 put an equal sign between the two, then Struts2.0 is not Struts
 anymore. It would be honest just to say that Struts ran out of steam,
 it is crusty, it sucks, its development is concluded and everyone is
 welcomed to switch to shiny WebWork. I would get that. I would accept
 that. At least I won't feel being fooled.

 In case of DaimlerChrysler one has an option to go and buy an original
 product. There is no such an option in Struts/WebWork case. How do you
 think you will explain to those who know that Struts sucks that
 Struts 2.0 is not Struts 1.x they knew (or actually did not know)
 before? Will you be telling them that this is actually WebWork, which
 is so much better? Now that would be fun.

 I have nothing against WebWork, I had looked into it once or twice, it
 is surely a nice framework, but I will not buy WebWork skinned as
 Struts.

 Michael.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

+1 on Don's serious message below (API compatibility is the key), but in a
somewhat more whimsical way in light of the [FRIDAY] prefix.

On 12/1/05, Don Brown [EMAIL PROTECTED] wrote:

 While you are certainly entitled to your opinion, I'd ask that you reserve
 judgement until at least the first Struts Ti release.  Yes, we plan to
 seed
 Struts Ti with WebWork 2.2, but that doesn't mean it will stay that way or
 that Struts Action 1.x users and even code aren't important.  I just
 started
 working on the Struts Action 1.x compatibility layer tonight so its too
 early to say, but my goal is to be able to run most Struts Action
 1.xapplications unchanged on Struts Ti.  Struts Ti was born with the
 idea of
 filling the gap between a new development frame of mind with JSF and
 Struts
 Action 1.x, providing Struts developers a powerful new framework that
 leverages their Struts knowledge, not negates it.

 Furthermore, it has been said before and I'll say it again - Struts Action
 1.x isn't going anywhere.  Just as development continued when Shale was
 born, development will continue today.  I have at least one major Struts
 Action 1.x application myself that will never see a rewrite, so if for
 some
 reason Struts Ti doesn't have full Struts Action 1.x compatibility, it'll
 stay on the stable, supported Struts Action 1.x.

 This is open source - if you are convinced Struts Action 1.x is the one
 true
 way, feel free to jump in and contribute.  Just because Struts Ti may be
 right for me, it may not be for you.

 Don

 On 12/1/05, Michael Jouravlev [EMAIL PROTECTED] wrote:
 
  Maybe I do not know how to do business. Heck, I do not have MBA. But
  for some reason I have a sour taste in the mouth. If
  StrutsTi/Struts2.0 is so heavily based on WebWork code that one did
  put an equal sign between the two, then Struts2.0 is not Struts
  anymore. It would be honest just to say that Struts ran out of steam,
  it is crusty, it sucks, its development is concluded and everyone is
  welcomed to switch to shiny WebWork. I would get that. I would accept
  that. At least I won't feel being fooled.
 
  In case of DaimlerChrysler one has an option to go and buy an original
  product. There is no such an option in Struts/WebWork case. How do you
  think you will explain to those who know that Struts sucks that
  Struts 2.0 is not Struts 1.x they knew (or actually did not know)
  before? Will you be telling them that this is actually WebWork, which
  is so much better? Now that would be fun.
 
  I have nothing against WebWork, I had looked into it once or twice, it
  is surely a nice framework, but I will not buy WebWork skinned as
  Struts.
 
  Michael.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


If I am a user of an API, my dependency on that API is primarily in terms of
the interfaces and classes that I import, and the semantics of the methods I
use.  (Side note -- this is one of the issues that motivated me to call out
which Shale APIs are *intended* to be used by application developers, versus
those used only if you're planning on extending the functionality of the
framework itself).  For Struts 1.x, the vast majority of an application's
dependencies are wrapped up in ActionForm and Action APIs.

When Struts 1.0 came out, the logic of the request processor was embedded
inside ActionServlet.  In 1.1, we factored that out into a separate
RequestProcessor class (so you could specialize it more easily, and to
support the new feature of application submodues).  But we didn't break the
Action or ActionForm APIs (yes, we went from perform() to execute(),
but 1.1still supported perform()).  Was
1.1 still Struts?  You bet it was.

In 1.2, the internal changes were less dramatic, but still real.  Is
1.2still Struts?  Yep, for the same reason.

In 1.3, the internal architecture is getting changed yet again, and even
more radically, to allow very fine grained customizations of the request
processing lifecycle.  But, and this is critically important, Action and
ActionForm *still* work.  Yes, in each of these transitions, there has been
a very small number of required changes (usually lagged by a release to give
everyone time), but the fundamental code of a Struts 1.0 app that has been
ported to 1.1/1.2/1.3 is still recognizable as a Struts application.

So, what's going to happen with Struts Applicaton Framework 2.0?  As Don
points out, it's too early to tell ... but I have a very high degree of
confidence in the folks working on this that a robust compatibility layer
can be created.  That won't be the *only* way to build a SAF
2.0application, but again ... if a
1.0 Struts appication is still recognizable, and can still work with
zero-to-minimal changes, then I'd say you are wasting your time looking
under the covers to see if it's implemented the same as it used to be.  Of
course it's not!  That's

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


 I think Struts is pretty cool.  But JSF seems to be the future so I am now
 learning it.  But I am getting really confused about Shale versus pure JSF
 versus Struts.  Maybe Craig McClanahan can give me some more insite into
 what I should be learning for my next Java based web project. Is JSF the
 future? And if it is which JSF should I be learning?


One of the most important lessons that newcomers to the software realm need
to understand is this:  there is no one size fits all answer to any
significant engineering problem.

Fundamentally, in the Java-based web application architecture space, two
schools of thought are emerging as very popular ... an action framework
based approach (Struts 1.x, WebWork, Spring MVC, ...) and a component
based approach (JavaServer Faces, Tapestry, ASP.Net, ...).  Both approaches
have their adherents, and the programming styles involved will tend to
attract developers with different tastes for things like object
orientedness and where the responsibility for creating the actual view tier
markup should be placed (put way too simplistically, templates versus
components).  But both architectural styles are viable, and neither one is
going to go away any time soon -- although I will contend that both
architectural styles will need to pay attention to what AJAX means to the
craft of creating web applications.

So, which should you learn?  Depends on what you are planning to do.  If you
are tasked to maintain and enhance an existing Struts-based (or WebWork
based, or whatever-based) application, it would certainly behoove you to
become an expert in that underlying technology :-).  If, on the other hand,
you are facing a new project, you need to evaluate issues like:

* How long do I have to complete it?

* What's the expertise level of my team with the various technologies?

* Do I have a budget (time and/or $$) to acquire expertise and/or tools
  that support the various technologies?

My personal belief is that component oriented development is more accessible
to a wider array of developers than action oriented frameworks.  Therefore,
I spend my time (disclaimer:  I'm paid to do this too, but that doesn't
cover much of my open source effort :-) working on technologies that are
designed to increase the overall number of developers in the world that are
using Java based technologies.  Does that mean JSF is better than action
oriented frameworks?  Depends on your goals -- for my goal, it is, but
remember  this is not a good versus bad dichotomy ... its better
(for this particular goal) versus good.

One other potential confusion around JSF, in particular, is that it can be
viewed as having a couple of different personalities:

* JSF is an API for user interface components that happens
  to support a view-tier oriented controller tier.

* JSF is an extensible controller tier that also has a robust
  view tier API for components.

Nearly every existing web framework can claim we integrate with JSF based
on viewing it as the first personality.  What you end up with is the ability
to use the emerging set of JSF components that are available, but you're not
leveraging the fact that JSF knows how to do things like navigation between
pages as well.

Shale was (until Seam came along) the only framework I know of that took the
second viewpoint -- Shale is all about leveraging existing JSF capabilities
as the front controller, and utilizing its extensibility APIs to add
functionality and/or ease of use, *without* reimplementing fundamental
things (like validation and navigation) that JSF already supports.  Starting
from this viewpoint lets Shale be a *lot* smaller (read, less for me to
have to learn).  Indeed, the core of Shale is currently around 112kb
(versus nearly five times that for Struts 1.2).  Yes, you need a JSF
implementation as well, but that's not a long term problem ... any app
server that implements Java EE 5 is going to be required to support JSF,
just like it's required to support the servlet and JSP APIs, so it's going
to be built in to your servers already -- and, if you use a standalone
container like Tomcat, you can accomplish the same result by putting either
the JSF RI or MyFaces into the shared library directories available to all
webapps installed on that server instance.

So, to answer your original question, it is in your economic best interest
to understand both kinds of technologies, and to learn which ones to apply
in which circumstances.  Buf if you find that JSF fits your needs for a
particular project, you'll also want to investigate Shale, because it
smooths off a bunch of the edges of component based development -- to say
nothing of providing functional equivalence with Struts 1.x support for
things like client side validation and support for Tiles.

--Brad


Craig

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Preston CRAWFORD

And this is about where I start ramping up my Ruby studying. 

I mean, I'm all for competing frameworks, but when the Struts umbrella
covers 3 different frameworks (which in term utilize how many
technologies?) it begins to get a little silly. Which one should I be
learning/using? I know, whichever is appropriate to your project.
Problem is that companies out there often recruit talent based on
business decisions, not necessarily the absolute precise technical
decision. So having some confusion in this space isn't a good thing.
It's possibly going to be a detriment to Struts and a boost to JSF and
maybe even a boost to Ruby on Rails or .Net or some other platform where
the framework of choice is a little more evident.

Preston

 [EMAIL PROTECTED] 12/1/2005 5:47:44 PM 
Maybe I do not know how to do business. Heck, I do not have MBA. But
for some reason I have a sour taste in the mouth. If
StrutsTi/Struts2.0 is so heavily based on WebWork code that one did
put an equal sign between the two, then Struts2.0 is not Struts
anymore. It would be honest just to say that Struts ran out of steam,
it is crusty, it sucks, its development is concluded and everyone is
welcomed to switch to shiny WebWork. I would get that. I would accept
that. At least I won't feel being fooled.

In case of DaimlerChrysler one has an option to go and buy an original
product. There is no such an option in Struts/WebWork case. How do you
think you will explain to those who know that Struts sucks that
Struts 2.0 is not Struts 1.x they knew (or actually did not know)
before? Will you be telling them that this is actually WebWork, which
is so much better? Now that would be fun.

I have nothing against WebWork, I had looked into it once or twice, it
is surely a nice framework, but I will not buy WebWork skinned as
Struts.

Michael.

-
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: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Preston CRAWFORD

 [EMAIL PROTECTED] 12/1/2005 7:30:16 PM 
My personal belief is that component oriented development is more
accessible
to a wider array of developers than action oriented frameworks. 
Therefore,
I spend my time (disclaimer:  I'm paid to do this too, but that
doesn't
cover much of my open source effort :-) working on technologies that
are
designed to increase the overall number of developers in the world that
are
using Java based technologies.  Does that mean JSF is better than
action
**

I would agree sincerely with the above. And if that is the overall
intent of why Struts is moving in the direction it is then to some
extent I get it. I mean, on one level I don't get it. That being that if
JSF already exists, why not just improve JSF instead of creating JSF++?
I don't necessarily see the benefit in that sense. It might make more
sense to keep a good, action oriented framework, pushing it forward and
improving it, and let JSF take its course.

That is, unless you believe that action oriented frameworks are
inaccessible enough to newbies, that in terms of sheer productivity it
doesn't make sense to push that model forward. I can see that point of
view. I think what many of us are seeking either way, is a clarification
on where Struts is headed and why so we can make an informed decision.
Right now backwards compatibility is being stressed so much (and I
understand why, but bear with me) that it's possible that those making
decisions won't really know what Struts is about at a certain point and
will choose something more rigid like Tapestry or JSF. Or, like I said
in another email, start taking a look at something like Ruby on Rails. I
don't know. I just know that Struts has been a standard-bearer for some
time. And change isn't bad, as long as you know where that change is
headed. Your overall explaination helps, but it's sitting on a mailing
list. 

Something more robust and visible might not be a bad idea. Because I
can speak from experience (having had to justify Struts 3 years ago when
I was working at a company choosing a framework, and again this year
when an organization I was with was testing out Tapestry) that Struts is
the standard, by and large. Confusing the powers that be, or making it
hard for people like myself to explain even what Struts is and why we
should choose it, is going to make life more difficult and perhaps have
people turning elsewhere.

Preston

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Don Brown [EMAIL PROTECTED] wrote:
 This is open source - if you are convinced Struts Action 1.x is the one true
 way, feel free to jump in and contribute.  Just because Struts Ti may be
 right for me, it may not be for you.

That is not what I meant. I meant that I will not buy facelifted
Impreza only because it has Saab emblem. If I needed a small fun AWD
wagon I go directly to Subaru.

If WebWork is better and Struts committers agreed upon that and
decided to move to the better codebase, this is all good and I can
understand that, and I can move along. I'd just prefer things to be
called what they really are.

On 12/1/05, Craig McClanahan [EMAIL PROTECTED] wrote:
 Put another way, my application depends on a Duck API, with methods like
 drumstick() and bill() and foot() that do things for me.  Am I going to care
 if the internal implementation morphs into a Goose instead of a Duck?  Naw
 ... I might appreciate the fact that I have some additional choices now, but
 as long as the framework has modes that walk like a duck and talk like a
 duck, I'm going to be satisfied.

I will probably be satisfied too. I just don't want Goose to pretend
*being* Duck.

Michael.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Preston CRAWFORD [EMAIL PROTECTED] wrote:

  [EMAIL PROTECTED] 12/1/2005 7:30:16 PM 
 My personal belief is that component oriented development is more
 accessible
 to a wider array of developers than action oriented frameworks.
 Therefore,
 I spend my time (disclaimer:  I'm paid to do this too, but that
 doesn't
 cover much of my open source effort :-) working on technologies that
 are
 designed to increase the overall number of developers in the world that
 are
 using Java based technologies.  Does that mean JSF is better than
 action
 **

 I would agree sincerely with the above. And if that is the overall
 intent of why Struts is moving in the direction it is then to some
 extent I get it. I mean, on one level I don't get it. That being that if
 JSF already exists, why not just improve JSF instead of creating JSF++?
 I don't necessarily see the benefit in that sense. It might make more
 sense to keep a good, action oriented framework, pushing it forward and
 improving it, and let JSF take its course.


Is there some compelling reason you can think of why Struts, as an open
source project, cannot address *both* universes of users?  After all (as Ted
says) we are not constrained by the typical economics of closed source
software development.  WIthin the Struts community, there seem to be
developers willing to work on both kinds of frameworks -- and that's just as
legitimate (at the project level) as having Java and C and PERL and Python
projects at the Apache Software Foundation level.

There is more than one right answer.

That is, unless you believe that action oriented frameworks are
 inaccessible enough to newbies, that in terms of sheer productivity it
 doesn't make sense to push that model forward. I can see that point of
 view. I think what many of us are seeking either way, is a clarification
 on where Struts is headed and why so we can make an informed decision.
 Right now backwards compatibility is being stressed so much (and I
 understand why, but bear with me) that it's possible that those making
 decisions won't really know what Struts is about at a certain point and
 will choose something more rigid like Tapestry or JSF. Or, like I said
 in another email, start taking a look at something like Ruby on Rails. I
 don't know. I just know that Struts has been a standard-bearer for some
 time. And change isn't bad, as long as you know where that change is
 headed. Your overall explaination helps, but it's sitting on a mailing
 list.


A *huge* number of newbies (to the Java platform) came in via Struts.  A
significant percentage of them found it more difficult that they would have
liked, and more than I would like fell off the bandwagon and gave up.
There's plenty of room for making action frameworks more accessible -- but
the quality of accessibility can not be persisted in a boolean variable
:-).

Something more robust and visible might not be a bad idea. Because I
 can speak from experience (having had to justify Struts 3 years ago when
 I was working at a company choosing a framework, and again this year
 when an organization I was with was testing out Tapestry) that Struts is
 the standard, by and large. Confusing the powers that be, or making it
 hard for people like myself to explain even what Struts is and why we
 should choose it, is going to make life more difficult and perhaps have
 people turning elsewhere.


ducks
Well, if you really want to live in a world where there is one and only one
choice, ASP.Net beckons :-)
/ducks

Actually, that's not even true either ... if you peruse the Struts sandbox,
you'll find a couple of packages called Agility and Nexus which, together,
provide a C# based front controller framework that looks a *lot* like Struts
1.3 looks to Java developers.

Preston


Craig

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Larry Meadors

On 12/1/05, Michael Jouravlev [EMAIL PROTECTED] wrote:
 On 12/1/05, Craig McClanahan [EMAIL PROTECTED] wrote:
  Put another way, my application depends on a Duck API, with methods like
  drumstick() and bill() and foot() that do things for me.  Am I going to care
  if the internal implementation morphs into a Goose instead of a Duck?  Naw
  ... I might appreciate the fact that I have some additional choices now, but
  as long as the framework has modes that walk like a duck and talk like a
  duck, I'm going to be satisfied.

 I will probably be satisfied too. I just don't want Goose to pretend
 *being* Duck.

 Michael.

Uhm, what kind of eggs does the goose lay? As long as they are
golden...I don't care if it's a duck, goose, or ostrich.

Heck, I might prefer the ostrich...those eggs are HUGE.

Larry

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Preston CRAWFORD [EMAIL PROTECTED] wrote:

 Your overall explaination helps, but it's sitting on a mailing
 list.


Point well taken (although it still gets to ~3000 direct subscribers and
unknown numbers of people who look in the mail archives) ... seems like a
blogworthy subject as well.  Will spend some time crafting some words to
post there too.

Craig

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Michael Jouravlev [EMAIL PROTECTED] wrote:
 I have nothing against WebWork, I had looked into it once or twice, it
 is surely a nice framework, but I will not buy WebWork skinned as
 Struts.

I think what people sometimes forget is that we're not selling anything.

If we were tring to market Struts, we wouldn't bother merging with
WebWork. Under the Open Symphony license, we can use whatever WebWork
code we want anytime we want.

But, we're not trying to market Struts. We're trying to build a
community of developers who care about collaborating. We're trying to
get people like Patrick Lightbody and Jason Carreira to spend their
volunteer hours with us. Patrick and Jason are excellent open source
developers, and I'm flattered that they want to join us.

The very simple answer about the merger is this: If you look at the
Struts roadmap and the WebWork feature set, you'll see they've already
done most of what we wanted to do, pretty much the way we would have
done it ourselves. A good engineer doesn't reinvent the wheel.

The Struts Action committers want to use WebWork for the same reason
anyone wants to use a framework: It already does what we need a
framework to do.

What's left is getting there from here. Don's begun work on the
compatibility layer. Meanwhile, I'm working on a set of rosetta
applications that show how well-known Struts applications look as
best-practice WebWork applications. I'm working on a MailReader port
now, and a iBATIS JPetShop port would be next. Film at 11. :)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Preston CRAWFORD [EMAIL PROTECTED] wrote:
 Your overall explaination helps, but it's sitting on a mailing list.

Hey, you heard it here first :)

All of these explanations start on the user  or dev list and work
their way into the website.

We don't have a marketing staff to run around and do such things for
us proactively. People ask questions,  we answer them, and try to get
them into the website when we can.

We do need to announce more of the website updates somehow. Much of
this is already covered on the site, people just don't know that. The
problem is that we always need to decide between spending our time
doing the work or talking about the work. We're not a company, we're
just a gaggle of engineers, just like you. Some people have started to
help out with such things on the wiki, which is much appreciated.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Preston CRAWFORD [EMAIL PROTECTED] wrote:
 I mean, I'm all for competing frameworks, but when the Struts umbrella
 covers 3 different frameworks (which in term utilize how many
 technologies?) it begins to get a little silly.

Hmmm, there won't be three, only two. Ti is a codename for a Struts
Action 2.x candidate. If code pans out, and we accept the proposal, Ti
will disappear and become Struts Action 2.x. There will be a 1.x
Action framework and a 2.x Action framework, but that often happens in
our industry.

We have two because JSF is fundamentally incompatible with
action-orientated frameworks. (As stated on the Struts home page.)
But, that will not be the case for Ti. We plan to create a clear and
relatively painless migration path, so that investments in skill sets
and working code will be retained. (Including our own.)

People like to say WebWork is a different framework, but really it
isn't. Struts and WebWork are already close cousins. Rather than clone
WebWork, Patrick and Jason have been kind enough to join with us, so
that we can collaborate rather than compete.

 Which one should I be learning/using?

That's up to you, dude. Unlike commercial companies with stockholders
to please, we're not trying to do your thinking for you. We're just
trying to build the frameworks that we want to use in our own
applications. If other people want to use them too, that's great. If
they want to help build them, even better. But, we're not on a mission
of world domination. We're just trying to create and maintain our own
applications, just like you.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tabbed panes in struts

2005-12-01 Thread Agnisys

Hi,
  I have seen tiles used for implementing Tabbed panes, however, they are 
static, that is, what
tabs are displayed is known ahead of time.
  In my application a tabbed pane is created at run-time. Is there a way to do 
this under Struts
framework or using some tags?

Thanks,
Anupam.




__ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

On 12/1/05, Craig McClanahan [EMAIL PROTECTED] wrote:
 But the fact that Struts has always stressed backwards
 compatibility of the key APIs as a fundamental principle is one of they key
 reasons that it has been successful.

Hmmm, perhaps, but not for the obvious reason. I'd guess that 70% of
the 70% marketshare that Struts is suppose to have is still using 1.1.
In practice, what we've done with 1.2 or 1.3 only matters to a small
fraction of Struts users. Of course, backward compatability is very
important to the *committers*, since we are more likely to upgrade
existing applications, or start new projects with the latest versions,
and, being only human, we want that process to go smoothly for
ourselves.

While backward compatibility has played a role, I think it has been
more of a feel good factor than something that made a practical
difference to the user base. I think we can make Ti very compatible
with 1.3.0, but, more importantly, we need to show people how
compatible existing skill sets and design paradigms are with
TI/WebWork. It's not a bad thing to do things a little bit differently
if different is a lot better. Witness JSTL.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tabbed panes in struts

2005-12-01 Thread Lintang JP

U should try struts-menu, cool

On 12/2/05, Agnisys [EMAIL PROTECTED] wrote:

 Hi,
   I have seen tiles used for implementing Tabbed panes, however, they are
 static, that is, what
 tabs are displayed is known ahead of time.
   In my application a tabbed pane is created at run-time. Is there a way
 to do this under Struts
 framework or using some tags?

 Thanks,
 Anupam.




 __
 Start your day with Yahoo! - Make it your home page!
 http://www.yahoo.com/r/hs

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
---
html version :
http://www.psychotazkia.or.id
wml version :
http://wap.psychotazkia.or.id

#365364 Registered Linux User

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Rahul Akolkar

On 12/1/05, Don Brown [EMAIL PROTECTED] wrote:
snip/
 I just started working
 on the Struts Action 1.x compatibility layer tonight so its too
 early to say,
snap/

On 12/1/05, Ted Husted [EMAIL PROTECTED] wrote:
snip/
 Meanwhile, I'm working on a set of rosetta
 applications that show how well-known Struts applications look
 as best-practice WebWork applications.
snap/

Don, Ted -

Any of this in sandbox yet? Where should I be looking? Trying to line
up some weekend reading ...

-Rahul

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tabbed panes in struts

2005-12-01 Thread Zsolt

Try http://ditchnet.org/taglibs/.

Zsolt

-Original Message-
From: Lintang JP [mailto:[EMAIL PROTECTED]
Sent: Friday, December 02, 2005 5:36 AM
To: Struts Users Mailing List
Subject: Re: Tabbed panes in struts

U should try struts-menu, cool

On 12/2/05, Agnisys [EMAIL PROTECTED] wrote:

 Hi,
   I have seen tiles used for implementing Tabbed panes, however, they are
 static, that is, what
 tabs are displayed is known ahead of time.
   In my application a tabbed pane is created at run-time. Is there a way
 to do this under Struts
 framework or using some tags?

 Thanks,
 Anupam.

 __
 Start your day with Yahoo! - Make it your home page!
 http://www.yahoo.com/r/hs

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

--
---
html version :
http://www.psychotazkia.or.id
wml version :
http://wap.psychotazkia.or.id

#365364 Registered Linux User

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Don Brown

Well, considering I started work a couple of hours ago, no, nothing yet :)
I can tell you my approach I thought of today - replace the WebWork
ServletDispatcher with a Common-Chain RequestProcessor then weave in a
command or two that detects what type of action is being called, and
delegates to the appropriate chain.  I'm hoping to even use Struts Action
1.3 as a dependency at first, so you have 100% Struts 1.x functionality, yet
you can start migrating sections to Struts Ti (WebWork) as you have time.

The Struts Ti repository is here:
http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/ti/  I'll be adding a
phase1 directory with the code.

If you are interested in Struts Ti, I'd highly recommend pulling down
WebWork and giving it a spin.  You could also swing by your local bookstore
and thumb through the excellent WebWork in Action book from Manning :)

Don

On 12/1/05, Rahul Akolkar [EMAIL PROTECTED] wrote:

 Don, Ted -

 Any of this in sandbox yet? Where should I be looking? Trying to line
 up some weekend reading ...

 -Rahul

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tabbed panes in struts

2005-12-01 Thread Yujun Liang

I designed a collection based view layer, tab is one of the components.
Unfortunately I am working for a commercial software house so I can't share
the code with you, but it is doable.

http://www.theserverside.com/news/thread.tss?thread_id=37365#189768

Ideally, one JSP is enough to display any domain object.

Regards

On 12/2/05, Zsolt [EMAIL PROTECTED] wrote:

 Try http://ditchnet.org/taglibs/.

 Zsolt

 -Original Message-
 From: Lintang JP [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 02, 2005 5:36 AM
 To: Struts Users Mailing List
 Subject: Re: Tabbed panes in struts
 
 U should try struts-menu, cool
 
 On 12/2/05, Agnisys [EMAIL PROTECTED] wrote:
 
  Hi,
I have seen tiles used for implementing Tabbed panes, however, they
 are
  static, that is, what
  tabs are displayed is known ahead of time.
In my application a tabbed pane is created at run-time. Is there a
 way
  to do this under Struts
  framework or using some tags?
 
  Thanks,
  Anupam.
 
 
 
 
  __
  Start your day with Yahoo! - Make it your home page!
  http://www.yahoo.com/r/hs
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 --
 ---
 html version :
 http://www.psychotazkia.or.id
 wml version :
 http://wap.psychotazkia.or.id
 
 #365364 Registered Linux User


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Yujun Liang
[EMAIL PROTECTED]

Re: [Definitely OT] JSTL problem in Websphere

2005-12-01 Thread Yujun Liang

Can you put fmt.tld into
/WEB-INF folder and using the following reference instead?
%@ taglib uri=/WEB-INF/fmt.tld prefix=fmt %

Regards
On 12/2/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:

 Dave Newton wrote:
  Frank W. Zammetti wrote:
 
  What bit of stupidity am I committing here?
 
  Using Websphere.

 You won't get any disagreement from me :)  I wish I had any kind of
 choice in the matter, but you know how it goes in big business when
 deals are made.

 Now it looks like ActionServlet isn't initializing, even though it works
 perfectly on Tomcat... probably some stupid problem with the resource
 bundle (hey, it's in WEB-INF/classes, but I'm deploying an EAR... that
 sounds like the recipe for a disaster to me with Websphere involved).
 But that's a problem for tomorrow :)

 Frank

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Yujun Liang
[EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Rahul Akolkar

On 12/1/05, Don Brown [EMAIL PROTECTED] wrote:
 Well, considering I started work a couple of hours ago, no, nothing yet :)
snip/

You mean its going to take you more than two hours? ;-)

But seriously, thanks for sharing the paragraph below, thats exactly
what I was looking for, a sneak preview of your thoughts about the
compatibility layer.

One other question - ti/phase2 is already there, and ti/phase1 comes
next? Are we counting down, whats the insight into the nomenclature?

-Rahul


 I can tell you my approach I thought of today - replace the WebWork
 ServletDispatcher with a Common-Chain RequestProcessor then weave in a
 command or two that detects what type of action is being called, and
 delegates to the appropriate chain.  I'm hoping to even use Struts Action
 1.3 as a dependency at first, so you have 100% Struts 1.x functionality, yet
 you can start migrating sections to Struts Ti (WebWork) as you have time.

 The Struts Ti repository is here:
 http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/ti/  I'll be adding a
 phase1 directory with the code.

 If you are interested in Struts Ti, I'd highly recommend pulling down
 WebWork and giving it a spin.  You could also swing by your local bookstore
 and thumb through the excellent WebWork in Action book from Manning :)

 Don


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all

2005-12-01 Thread Don Brown

On 12/1/05, Rahul Akolkar [EMAIL PROTECTED] wrote:

 One other question - ti/phase2 is already there, and ti/phase1 comes
 next? Are we counting down, whats the insight into the nomenclature?


Dessert first? :)  When we started Struts Ti, it was conceived as a new
framework that aimed to simplify the developers life requiring no
configuration, supporting workflow through Beehive's page flow, and allowing
developers to write code then refresh (with compiles automatically handled
by the framework).  It was decided this would be written on WebWork and so
we proceeded.  Just recently, we decided to merge with WebWork through
Struts Ti.  In an effort to a release of Struts Ti out ASAP, we decided to
move the original lofty goals of Struts Ti to phase 2, with phase 1 being
the WebWork merger.

HTH,

Don


-Rahul


  I can tell you my approach I thought of today - replace the WebWork
  ServletDispatcher with a Common-Chain RequestProcessor then weave in a
  command or two that detects what type of action is being called, and
  delegates to the appropriate chain.  I'm hoping to even use Struts
 Action
  1.3 as a dependency at first, so you have 100% Struts 1.x functionality,
 yet
  you can start migrating sections to Struts Ti (WebWork) as you have
 time.
 
  The Struts Ti repository is here:
  http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/ti/  I'll be
 adding a
  phase1 directory with the code.
 
  If you are interested in Struts Ti, I'd highly recommend pulling down
  WebWork and giving it a spin.  You could also swing by your local
 bookstore
  and thumb through the excellent WebWork in Action book from Manning :)
 
  Don
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: [FRIDAY] Struts 1.x is Struts Classic after all