date:20030604

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432

Validator returns nulls in JavaScript validation





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 13:30 ---
I get the same behavior on the server-side.  I found that my validator.jsp (used
for javascript) had the following error:

java.lang.NullPointerException
at 
org.apache.commons.validator.ValidatorResources.get(ValidatorResources.java:333)
at
org.apache.struts.taglib.html.JavascriptValidatorTag.doStartTag(JavascriptValidatorTag.java:316)
at 
org.apache.jsp.validator_jsp._jspx_meth_html_javascript_0(validator_jsp.java:74)
at org.apache.jsp.validator_jsp._jspService(validator_jsp.java:53)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

This file's contents is as follows and works fine in the 03026 build:

<%@ page language="java" contentType="javascript/x-javascript" %>
<%@ taglib uri="http://jakarta.apache.org/struts/tags-html"; prefix="html" %>



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

RE: composable RequestProcessor

2003-06-04 Thread Andrew Hill

Just had a look at the updated wiki.
Is it just me lacking sleep or are the contents for the singleInterface page
and the composableRequestprocessor page kindof in the wrong places? (ie the
stuff for composable on the single page and vice versa)

-Original Message-
From: Matthias Bauer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 June 2003 21:11
To: Struts Developers List
Subject: Re: composable RequestProcessor

> I just made some more changes to the Wiki to try to point out the lack
> of consensus on this issue.  (Until this morning it said people felt
> one way, and Ted just wrote a pretty good argument for thinking about
> it another way.)

This is right. Before Ted's mail I was pretty sure, that the idea of a
composable request processor is much too difficult to implement. But Ted
really made a very good point. Unfortunately I did not have the time yet
to think it through in detail and look more thouroughly in the code.

>
> I strongly encourage people who are really thinking about this to
> review the Wiki pages, to make sure I haven't gotten anything wrong,
> and to potentially add your ideas there as well as in the mailing list.

I am afraid that nobody will notice, when someone changes/adds the wiki
content. When I receive a mail with this subject, I am reminded that
someone makes a new point. Therefore, mailing seems more straightforward
to me at this point in time.

> Maybe it's just me, but message-by-message design makes my head spin.
> It needs to be collected somewhere.
>
> http://nagoya.apache.org/apachewiki?RequestProcessor

I think the correct URL is:

http://nagoya.apache.org/wiki/apachewiki.cgi?RequestProcessor

--- Matthias

-
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: composable RequestProcessor

I just made some more changes to the Wiki to try to point out the lack 
of consensus on this issue.  (Until this morning it said people felt 
one way, and Ted just wrote a pretty good argument for thinking about 
it another way.)


This is right. Before Ted's mail I was pretty sure, that the idea of a 
composable request processor is much too difficult to implement. But Ted 
really made a very good point. Unfortunately I did not have the time yet 
to think it through in detail and look more thouroughly in the code.

I strongly encourage people who are really thinking about this to 
review the Wiki pages, to make sure I haven't gotten anything wrong, 
and to potentially add your ideas there as well as in the mailing list.
I am afraid that nobody will notice, when someone changes/adds the wiki 
content. When I receive a mail with this subject, I am reminded that 
someone makes a new point. Therefore, mailing seems more straightforward 
to me at this point in time.

Maybe it's just me, but message-by-message design makes my head spin. 
It needs to be collected somewhere.

http://nagoya.apache.org/apachewiki?RequestProcessor
I think the correct URL is:

http://nagoya.apache.org/wiki/apachewiki.cgi?RequestProcessor

--- Matthias

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

Re: composable RequestProcessor

I knew that was going to happen.  I tried to type the URL from memory 
and got it wrong.

Here's the right one: http://nagoya.apache.org/apachewiki.cgi?RequestProcessor

At 7:53 -0500 6/4/03, Joe Germuska wrote:
I just made some more changes to the Wiki to try to point out the 
lack of consensus on this issue.  (Until this morning it said people 
felt one way, and Ted just wrote a pretty good argument for thinking 
about it another way.)

I strongly encourage people who are really thinking about this to 
review the Wiki pages, to make sure I haven't gotten anything wrong, 
and to potentially add your ideas there as well as in the mailing 
list.

Maybe it's just me, but message-by-message design makes my head 
spin. It needs to be collected somewhere.

http://nagoya.apache.org/apachewiki?RequestProcessor
--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

Re: composable RequestProcessor

I just made some more changes to the Wiki to try to point out the 
lack of consensus on this issue.  (Until this morning it said people 
felt one way, and Ted just wrote a pretty good argument for thinking 
about it another way.)

I strongly encourage people who are really thinking about this to 
review the Wiki pages, to make sure I haven't gotten anything wrong, 
and to potentially add your ideas there as well as in the mailing 
list.

Maybe it's just me, but message-by-message design makes my head spin. 
It needs to be collected somewhere.

http://nagoya.apache.org/apachewiki?RequestProcessor
--
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: composable RequestProcessor

Jeff Robertson wrote:
As I just said in a message that probably hasn't made it to you yet, I did
need something *sorta* like this enough to actually do it on ActionServlet.
At the time nobody paid much attention because
a) I didn't put up the code
b) It was for Struts 1.0
Now that other people seem to be independently arriving at this need, I am
willing to correct both of the above shortcomings.
If anyone is looking for a quick and easy place to post some working 
code, the Struts site at SourceForge is at your disposal.

http://sourceforge.net/projects/struts

-Ted.



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

Re: composable RequestProcessor

I still don't see why processing an "action" request is any different
than processing a "validation" request.

Formed like the validation, the default request chain looks like this:

process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionForm,processPopulate,processValidate,processForward,processInclude,processActionCreate,processActionPerform,processForwardConfig"

where each of these have been defined as a Subprocessor (e.g. Validator).

As it stands, many of the process methods take different signatures and
return different objects. But that could be changed so that they pass
around a single data transfer object with a place for all the usual
objects (request,response,mapping,form,action,forward).

Whether each component in this sequence is systemically compatible or
whether the order of the processes makes sense, would be the developer's
responsibility, just as it is for defining a chain of Validators.

Right now, the framework describes a lockstep lifecycle. But that really
isn't the framework's job. The framework should provide a pre configured
default lifecycle, but the developer should as much freedom as possible
to define whatever lifecycle works best for a given application.

The distribution could ship with a library of Subprocessors (just as we
ship with a library of Validators). To use Tiles, you would make the
appropriate changes to the "process" property to load the Tiles
Subprocessors. If someone wanted to handle a different extension point
differently (or insert a new one), they could add a Subprocessor to the
library (as we can with validators), and amend the "process" property.

So there would be no pre-ordained processABC and processXYZ methods or
call sequence. The processor would call each process in turn until
someone cried stop or the sequence was complete. You could put as many
or as few Subprocessors into the sequence as you liked, same as we can
do with Validators.

A radical extension, like Tiles, may also need to subclass the main
"Processor" (aka the "RequestProcessor") that would call the individual
Subprocessors, but hopefully the methods that it overrides (like
internalModuleRelativeForward) won't matter to the other Subprocessors.

Or, maybe if Tiles does not have to live within a lockstep lifecycle,
there might be a better way of interpolating the "processTiles" step, so
that it doesn't need override "internal" methods.

So, anyway, the idea is that there would be a Subprocessor interface and
concrete implementations for each of the existing process methods (as
individual classes). The existing RequestProcessor(s) could implement a
Processor interface. The new ProcessManager could also implement the
Processor interface but call individual Subprocessors from within the
process method. (You might be even be able to do a concept test with a
RequestProcessor subclass that called inner classes based on the
existing processes.) Which Subprocessors the ProcessManager calls in
what order would be configurable.

While not as simple as what we have now, it would be more extensible,
and has the virtue of using the same implementation pattern as another
Struts component, the Validator. Which also means that ProcessManager
would not be any more difficult for developers to configure and use than
the Validator.

-Ted.

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

Re: Status check?

Martin Cooper wrote:
If you're still having trouble, you could put the zip and tar.gz bundles
in your home directory on cvs and give me access, and I can create the
sigs and upload them, if you want.
I might do that. It's turning into a tough week, and I still have a lot 
do before catching a plane on Monday, which isn't always the best time 
to try something new =:0)

-Ted.



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

Re: composable RequestProcessor

Seems like the GIF I attached to my previous mail did not come through. 
Therefore, the UML diagram can be accessed via the following URL: 
http://www.livinglogic.de/Struts/requestProcessor.gif

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

Re: composable RequestProcessor

This is a multi-part message in MIME format.

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

Re: composable RequestProcessor

During this whole discussion I feel torn back and forth whether to solve 
this challenge with configuration or in code. One thing we are trying to 
achieve when going in the configuration direction is the following: 
Different extensions don't need to know anything of each other and we 
can (if we are finding the right granularity) selectively choose to use 
processXXX from extension 1 and processYYY from extension 2 just by 
configuring this.

I am afraid this will only work in very few cases. First there is the 
issue, David raises: The following code snippet cannot be configured in XML:

public processActionCreate() {
 super();  //do parent behavior
 tilesRP.processActionCreate();  // do tiles
 // do some  custom stuff
 someotherRP.processActionCreate();
} 
The second issue is: Will processXXX and processYYY always work together 
without conflicting? I don't think so. But allowing a developer to 
configure arbitrary request processor methods together implies that they 
will be compatible among each other.

My third point is: If we decide to only let the methods processXXX be 
reconfigured, this might not be sufficient, because (look at Tiles) an 
extension might want to redefine an internal method that is used from 
several processXXX methods.

The more we are discussing, the more it looks to me that we don't want 
to give up the flexibility of composition by coding. Therefore, here is 
a different proposal that requires only a minimum of changes to the 
request processor and looks very much like the approach I took for the 
workflow extension:

Look at the UML diagram I attached to this mail (I hope it comes through 
to the list). It shows the TilesRequestProcessor and the 
WorkflowRequestProcessor directly being derived from RequestProcessor. 
If I want to implement a TilesWorkflowRequestProcessor, I have to 
subclass TilesWorkflowRequestProcessor and add the workflow 
functionality (in our example processYYY). This is painful if processYYY 
contains some complex logic, because it would normally require to have a 
copy of the code in both WorkflowRequestProcessor and 
TilesWorkflowRequestProcessor.  In order to prevent this code 
duplication, the method processYYY is extracted into a separate class 
WorkflowRequestProcessorLogic.

Now the method processYYY in WorkflowRequestProcessor and 
TilesWorkflowRequestProcessor becomes trivial:

public Some_Type processYYY()
{
   return this.getWfLogic().processYYY();
}
The method getWfLogic must look like this:

private WorkflowRequestProcessorLogic getWfLogic()
{
  if (null == this.wfLogic)
  {
   this.wfLogic = new WorkflowRequestProcessorLogic(this);
   }
}
As the instance of WorkflowRequestProcessorLogic receives a reference to 
the RequestProcessor, its method processYYY can look this way:

public Some_Type processYYY()
{
   ...
   reqProc.processXXX();
   ...
   reqProc.doSomething();
   ...
}
This only works, if all methods in RequestProcessor become public and 
all members of RequestProcessor become accessible with public setters 
and getters. But this is the only change needed to enable extension 
developers to implement this pattern.

What are the consequences?

1. Drawback: For each combination of different extensions, a new 
subclass needs to be created. But if every extension follows this 
pattern proposed here, this is a trivial task for all the cases that 
could also be covered by configuration and does not necessarily need to 
be done by the creator of an extension but can as well be done by the 
struts developer who wants to use the extensions A, B and C together. In 
more sophisticated cases (e. g. when methods need to be chained), the 
configuration approach does not work anyway, but the coding approach can 
at least be taken by the people who are knowing what they do.

2. The one who assembles valid combinations of request processors is the 
one in charge to test whether the extension play well together. 
Therefore the danger of configuring arbitrary parts of different request 
processors is banned.

3. One of the extensions (in our diagram TilesRequestProcessor) does not 
even need to stick to the pattern, i. e. can have the logic embedded in 
its request processor.

4. Maximum flexibility, because any method can be overwritten by an 
extension.

Comments?

--- Matthias

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

DO NOT REPLY [Bug 20468] New: - MessageResources always uses the default Locale for MessageFormats

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20468

MessageResources always uses the default Locale for MessageFormats

   Summary: MessageResources always uses the default Locale for
MessageFormats
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Problem:
The following code fragment in an Action
  Locale myLocale = getLocale(myHttpServletRequest);
  MessageResources myResources = getResources();
  Date myDate = new Date();
  String myString = myResources.getMessage(myLocale, "format.date", myDate);
should result in a String of the form "04.06.2003" or "04 Jun 2003" depending 
on the Locale (german or english) when format.date={0,date,medium} but the 
default Locale is used in both cases. The reason for this is the codeline:
  format = new MessageFormat(escape(formatString));
in the method:
  public String getMessage(Locale locale, String key, Object args[])
No Locale is provided in the constructor, therefore the default Locale is used.

Solution:
Replace the above codeline by:
  MessageFormat myMessageFormat = new MessageFormat("");
  myMessageFormat.setLocale(myLocale);
  myMessageFormat.applyPattern(escape(myStringFormat));

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

DO NOT REPLY [Bug 20466] New: - bean:message should accept Object args instead of String args

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20466

bean:message should accept Object args instead of String args

   Summary: bean:message should accept Object args instead of String
args
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Problem:

with format.date={0,date,medium} should result in a message of the form
04.06.2003 in german locale but it results in an error.
To use the full capabilities of MessageFormat you must be able to provide 
Object arguments.
Solution:
Change the type of arg0 - arg3 from String to Object 
in ../taglib/bean/MessageTag.java. This will have no consequences on the 
interface or documentation of the message tag.
Remark:
A bug in ../util/MessageResources.java results in the usage of the default 
Locale.

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

Re: composable RequestProcessor

Ted Husted wrote:

Gary D Ashley Jr. wrote:
> First,
> If the TilesRequestProcessor were to be integrated into
> RequestProcessor, and made to play nice when not using Tiles, that
> would at least remove one obstacle when trying to extend the request
> processor.  Since Tiles seems tobe a core struts component now, would
> that make since?  Or should Tiles still considered an extension?
Both Tiles and the Validator should be considered "standard extensions".

Keeping them as exensions means that we have a "case in point" proving 
the extensibility of Struts.

In other words, if the model works for Tiles as an extension, it 
should work for anything =:0)

ha, ha, good joke ;-)

This whole discussion proves, that even though Tiles can be integrated 
as an extension,  no other extension can with reasonable effort.

--- Matthias

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

DO NOT REPLY [Bug 20432] - Validator returns nulls in JavaScript validation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432

Validator returns nulls in JavaScript validation





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 04:54 ---
Does the server side validation render the messages properly?

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

Re: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

2003-06-04 Thread Martin Cooper


"David Graham" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm fairly certain I voted +1 on this.

Yup.

http://marc.theaimsgroup.com/?l=struts-dev&m=105421605003516&w=2

--
Martin Cooper


>
> David
>
>
> >From: "James Turner" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
> >Date: Tue, 3 Jun 2003 23:47:12 -0400
> >
> >+1
> >James Holmes [EMAIL PROTECTED]
> >James Turner [EMAIL PROTECTED]
> >James Mitchell [EMAIL PROTECTED]
> >Arron Bates [EMAIL PROTECTED]
> >
> >No other votes (unless Ted and David Graham want to +1 retroactively,
> >since they seemed to be supportive but didn't explicitly +1)
> >
> >Therefore, the vote passes.
> >
> >James Turner
> >Director of Software Development
> >Benefit Systems, Inc.
> >[EMAIL PROTECTED]
> >
> >Track Chair, Strategic Open Source
> >2003 Fall COMDEX
> >
> >Author:
> > MySQL & JSP Web Applications
> > Struts Kick Start
> > JavaServer Faces Kick Start
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> _
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail




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

RE: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

2003-06-04 Thread James Turner

I went back and checked, you did indeed.  So the final list is:
James Holmes [EMAIL PROTECTED]
James Turner [EMAIL PROTECTED]
James Mitchell [EMAIL PROTECTED]
Arron Bates [EMAIL PROTECTED]
David Graham [EMAIL PROTECTED] 

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 04, 2003 12:25 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
> 
> 
> I'm fairly certain I voted +1 on this.
> 
> David
> 
> 
> >From: "James Turner" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
> >Date: Tue, 3 Jun 2003 23:47:12 -0400
> >
> >+1
> >James Holmes [EMAIL PROTECTED]
> >James Turner [EMAIL PROTECTED]
> >James Mitchell [EMAIL PROTECTED]
> >Arron Bates [EMAIL PROTECTED]
> >
> >No other votes (unless Ted and David Graham want to +1 
> retroactively, 
> >since they seemed to be supportive but didn't explicitly +1)
> >
> >Therefore, the vote passes.
> >
> >James Turner
> >Director of Software Development
> >Benefit Systems, Inc.
> >[EMAIL PROTECTED]
> >
> >Track Chair, Strategic Open Source
> >2003 Fall COMDEX
> >
> >Author:
> > MySQL & JSP Web Applications
> > Struts Kick Start
> > JavaServer Faces Kick Start
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> _
> The new MSN 8: smart spam protection and 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
> 
> 
> -
> 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: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

I'm fairly certain I voted +1 on this.

David


From: "James Turner" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
Date: Tue, 3 Jun 2003 23:47:12 -0400
+1
James Holmes [EMAIL PROTECTED]
James Turner [EMAIL PROTECTED]
James Mitchell [EMAIL PROTECTED]
Arron Bates [EMAIL PROTECTED]
No other votes (unless Ted and David Graham want to +1 retroactively,
since they seemed to be supportive but didn't explicitly +1)
Therefore, the vote passes.

James Turner
Director of Software Development
Benefit Systems, Inc.
[EMAIL PROTECTED]
Track Chair, Strategic Open Source
2003 Fall COMDEX
Author:
MySQL & JSP Web Applications
Struts Kick Start
JavaServer Faces Kick Start


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

RE: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

2003-06-04 Thread Andrew Hill

Hip hip hoooray!

-Original Message-
From: James Turner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 June 2003 11:47
To: [EMAIL PROTECTED]
Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2


+1
James Holmes [EMAIL PROTECTED]
James Turner [EMAIL PROTECTED]
James Mitchell [EMAIL PROTECTED]
Arron Bates [EMAIL PROTECTED]

No other votes (unless Ted and David Graham want to +1 retroactively,
since they seemed to be supportive but didn't explicitly +1)

Therefore, the vote passes.

James Turner
Director of Software Development
Benefit Systems, Inc.
[EMAIL PROTECTED]

Track Chair, Strategic Open Source
2003 Fall COMDEX

Author: 
MySQL & JSP Web Applications
Struts Kick Start
JavaServer Faces Kick Start 



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

[RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

2003-06-04 Thread James Turner

+1
James Holmes [EMAIL PROTECTED]
James Turner [EMAIL PROTECTED]
James Mitchell [EMAIL PROTECTED]
Arron Bates [EMAIL PROTECTED]

No other votes (unless Ted and David Graham want to +1 retroactively,
since they seemed to be supportive but didn't explicitly +1)

Therefore, the vote passes.

James Turner
Director of Software Development
Benefit Systems, Inc.
[EMAIL PROTECTED]

Track Chair, Strategic Open Source
2003 Fall COMDEX

Author: 
MySQL & JSP Web Applications
Struts Kick Start
JavaServer Faces Kick Start 



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

DO NOT REPLY [Bug 20455] - Bug in FieldChecks.validateRequiredIf(...)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20455

Bug in FieldChecks.validateRequiredIf(...)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 02:54 ---
validateRequiredIf() now fails for strings of whitespace.

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

cvs commit: jakarta-struts/src/share/org/apache/struts/validator FieldChecks.java

2003-06-04 Thread dgraham

dgraham 2003/06/03 19:50:58

  Modified:src/share/org/apache/struts/validator FieldChecks.java
  Log:
  Fixed validateRequiredIf() so it would fail on Strings of whitespace
  for PR# 20455.
  
  Revision  ChangesPath
  1.9   +14 -10
jakarta-struts/src/share/org/apache/struts/validator/FieldChecks.java
  
  Index: FieldChecks.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/validator/FieldChecks.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- FieldChecks.java  22 May 2003 01:05:44 -  1.8
  +++ FieldChecks.java  4 Jun 2003 02:50:58 -   1.9
  @@ -226,14 +226,18 @@
   i++;
   }
   
  -if (required) {
  -if ((value != null) && (value.length() > 0)) {
  -return true;
  -} else {
  -errors.add(field.getKey(), Resources.getActionError(request, va, 
field));
  + if (required) {
  + if (GenericValidator.isBlankOrNull(value)) {
  + errors.add(
  + field.getKey(),
  + Resources.getActionError(request, va, field));
  + 
   return false;
  -}
  -}
  +
  + } else {
  + return true;
  + }
  + }
   return true;
   }
   
  
  
  

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

RE: composable RequestProcessor

2003-06-04 Thread Andrew Freeman

Have any of you explored how XWork/WebWork2 handle any of these situations?

Just curious.

Andy


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

DO NOT REPLY [Bug 20459] - html:form focus and focusIndex problem

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20459

html:form focus and focusIndex problem

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 02:21 ---
So are you using radio buttons or checkboxes?  If it's radio buttons and there's
only one, once the user clicks on the button they won't be able to deselect it
which is an unfriendly UI.

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

Re: Status check?

2003-06-04 Thread Martin Cooper

On Tue, 3 Jun 2003, Ted Husted wrote:

> If anyone had a mind to, it would be really great to have the Struts
> News and Resources pages updated this week, before the next RC. There's
> been a bunch of stuff announced on the list lately. (If not, I'll try to
> do it before we go to final release.)
>
> I'm still getting my head around the release procedures [never signed a
> JAR before, except with a marker =:)], but do hope to have it sorted out
> by Friday or Saturday.

You shouldn't have to sign any jars - we haven't done that for Struts
before. The only things I sign for the releases are the zip and tar.gz
bundles. There's a page on the Wiki that might help you with that:

http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases

I added the section on PGP 8.0 Freeware, since that's what I use, but you
can also use GPG, which I think is installed on daedalus. The MD5 tool is
definitely installed on daedalus, since that's where I create the digests
for Struts releases.

If you're still having trouble, you could put the zip and tar.gz bundles
in your home directory on cvs and give me access, and I can create the
sigs and upload them, if you want.

--
Martin Cooper

>
> -Ted.
>
>
>
>
>
> -
> 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: Status check?

If anyone had a mind to, it would be really great to have the Struts 
News and Resources pages updated this week, before the next RC. There's 
been a bunch of stuff announced on the list lately. (If not, I'll try to 
do it before we go to final release.)

I'm still getting my head around the release procedures [never signed a 
JAR before, except with a marker =:)], but do hope to have it sorted out 
by Friday or Saturday.

-Ted.





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

DO NOT REPLY [Bug 20459] New: - html:form focus and focusIndex problem

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20459

html:form focus and focusIndex problem

   Summary: html:form focus and focusIndex problem
   Product: Struts
   Version: 1.1 RC1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The javascript generated when using focus and focusIndex does not account for the
following prolblem:

We have a radio button group that is dynamically created based on a database
query. There may be 1 or more items in the group. In the case where a single
item exists, the radio button does NOT have any sub-elements, so in that case we
need to use *JUST* the focus attribute of the form tag. However, if the radio
button has more than one element we need to use both the focus and the
focusIndex attributes. It would be highly desirable to be able to always specify
the focus attribute to the name of the radio button and if the focusIndex is NOT
specified but sub-elements do exist, the focus is set to the "0" element for the
control.

EX:

My form is "referralsToPvdReport"
The field "selectedIndices" is a checkbox group (checkboxes with the same name)
The checkboxes are created by iterating over a collection of database records
and therefore the index will conditionally be present if more than one record
needs to be rendered.

var focusControl =
  document.forms["referralsToPvdReport"].elements["selectedIndices"];

  if (focusControl.type != "hidden") {
if (focusControl[0]) {
  focusControl[0].focus();
} else {
  focusControl.focus();
}
  }

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

Re: composable RequestProcessor

Gary D Ashley Jr. wrote:
> First,
> If the TilesRequestProcessor were to be integrated into
> RequestProcessor, and made to play nice when not using Tiles, that
> would at least remove one obstacle when trying to extend the request
> processor.  Since Tiles seems tobe a core struts component now, would
> that make since?  Or should Tiles still considered an extension?
Both Tiles and the Validator should be considered "standard extensions".

Keeping them as exensions means that we have a "case in point" proving 
the extensibility of Struts.

In other words, if the model works for Tiles as an extension, it should 
work for anything =:0)

-Ted.





--
Ted Husted,
Struts in Action 


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

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155

The strutsel-exercise-taglib application can not be compiled with jspc





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 17:11 ---
This really is an invalid bug. If anything, it's a Tomcat bug. The "preferred
way" to do this sort of thing is outlined in:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html

under the "Web Application Compilation" section. It doesn't use the jspc
scripts, it uses Ant and a custom task. The given build.xml file still appears
to be wrong, however. It should probably include the web app's WEB-INF/classes
and WEB-INF/lib/*.jars in the classpath of the taskdef task.

By the way, I believe the jspc scripts will ignore the current shell's classpath
and set its own.

Another "by the way", I *did* try this with a modified build.xml file and it
worked. At least to the extent that the task completed and stuff was generated.
I did *not* go through the bother of rebuilding and deploying the app.

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

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155

The strutsel-exercise-taglib application can not be compiled with jspc





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 16:49 ---
Just to confirm the last step, you added the path to the "struts.jar" to your
CLASSPATH environment variable, and you ran your "jspc" test, and you still get
the ClassNotFoundException?

Could you try this same test with the other applications that come with Struts,
like "struts-blank" and others?

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

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155

The strutsel-exercise-taglib application can not be compiled with jspc





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 16:08 ---
I tried setting CLASSPATH as you suggested, and got the same result. But still -
 I don't understand why I should do that. The application should compile 
without the user having to set up classpath.

BTW, I just tried on Tomcat 4.1.24, and I got the same failure there.

I have to ask again: did you try to reproduce the bug ? Does this fail for you 
too, or does it work well ?

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

DO NOT REPLY [Bug 20455] New: - Bug in FieldChecks.validateRequiredIf(...)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20455

Bug in FieldChecks.validateRequiredIf(...)

   Summary: Bug in FieldChecks.validateRequiredIf(...)
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a validation that should be failing (under certain conditions),
but is not.  I've double checked and triple checked to make sure the
setup is correct, and it's still not working correctly.

So, I took a look at the code for "validateRequiredIf" in 
the "org.apache.struts.validator.FieldChecks" class.  At the end of
the method I found this segment of code:

if (required) {
if ((value != null) && (value.length() > 0)) {
return true;
} else {
errors.add(field.getKey(), Resources.getActionError(request, va, 
field));
return false;
}
}

Am I correct in assuming that the following condition "((value != null) && 
(value.length() > 0))" should be "(!GenericValidator.isBlankOrNull(value))".  
The reason my check is failing is due to the fact the value I'm checking is 
all white space (at certain times), and is selected from a select box.

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

RE: composable RequestProcessor

First,
If the TilesRequestProcessor were to be integrated into RequestProcessor,
and made to play nice when not using Tiles, that would at least remove one
obstacle when trying to extend the request processor.  Since Tiles seems to
be a core struts component now, would that make since?  Or should Tiles
still considered an extension?
That's not a bad idea now that Tiles is integrated with Struts.

I am with David that this starts to get very complicated.  Maybe instead, a
RPHelper class could be created that has a bunch of static methods to 
handle
all the default processing rules.  so:
Static methods are evil.  Most times you need a static method, you can 
replace it with a Singleton class with the same methods.

David

public class RequestProcessor implements ActionServletRequestProcessor {

  public void process(HttpServletRequest request, HttpServletResponse
response) {
request = RequestHandler.processMultipart(request);
	...
RequestHandler.processLocale(request, response);
  ...
ActionMapping mapping = RequestHandler.processMapping(request, 
response,
path);
  ...
  }

  ...
}
Thanks.

Gary Ashley







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

RE: composable RequestProcessor

2003-06-04 Thread Gary D Ashley Jr.

First,
If the TilesRequestProcessor were to be integrated into RequestProcessor,
and made to play nice when not using Tiles, that would at least remove one
obstacle when trying to extend the request processor.  Since Tiles seems to
be a core struts component now, would that make since?  Or should Tiles
still considered an extension?

Otherwise, if the TilesRequestProcessor was kept as a seperate class, and
you follow the composing model David spoke of, would it be desireable for
TilesRequestProcessor to implement this new interface, and then have a
RequestProcessor member?  Or does it stay a subclass of the coreRP?

in tilesRP:
public processXXX() {
  coreRP.processXXX();
}

public init() {
  coreRP.init();
}



Second,
What is a RequestProcessor

public interface ActionServletRequestProcessor {//might one day want
ServletRP, ComposableRP or other including non Http processing?

  void init(ActionServlet servlet,
ModuleConfig moduleConfig);

  void process(HttpServletRequest request,
HttpServletResponse response);

  void destroy();
}


Wouldn't that be it?  Or am I missing something.  It seems that if you are
going to the trouble of making this an interface, the only things you should
really care about is that you have lifecycle methods, and that you can
process a request and presumable provide a response.  Everything else with
creating Actions, etc may not be desireable in all cases.

Maybe from there you create:

ActionFormRP
ActionRP
ActionMappingRP  //or ActionConfigRP
ForwardConfigRP

I am with David that this starts to get very complicated.  Maybe instead, a
RPHelper class could be created that has a bunch of static methods to handle
all the default processing rules.  so:

public class RequestProcessor implements ActionServletRequestProcessor {

  public void process(HttpServletRequest request, HttpServletResponse
response) {

request = RequestHandler.processMultipart(request);
...
RequestHandler.processLocale(request, response);
  ...
ActionMapping mapping = RequestHandler.processMapping(request, response,
path);
  ...
  }

  ...
}

Thanks.

Gary Ashley







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

DO NOT REPLY [Bug 20155] - The strutsel-exercise-taglib application can not be compiled with jspc

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155

The strutsel-exercise-taglib application can not be compiled with jspc





--- Additional Comments From [EMAIL PROTECTED]  2003-06-03 15:08 ---
Well, from this it's pretty clear this is not a bug in Struts, or in the
struts-el exercise taglib.  However, it's still worth gathering a little more
information, as this might be seen as a bug in Tomcat.

Have you tried setting your CLASSPATH env var to include the "struts.jar" file,
and then running your jspc task?

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

RE: Validator Javascript being displayed on the jsp page

Well there was Struts 1.1b1, b2, b3, RC1, and nightly builds...which one did 
you download?  It looks like you have an old version of commons-validator.  
Try downloading comons-validator-1.0.2.

David


I am not sure how to find the version of 1.1...

I have the Mainfest.mf for struts:
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1
Extension-Name: Struts Framework
Specification-Title: Struts Framework
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.1
Implementation-Title: Struts Framework
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 1.1
Class-Path: commons-beanutils.jar
Class-Path: commons-collections.jar
Class-Path: commons-dbcp.jar
Class-Path: commons-digester.jar
Class-Path: commons-logging.jar
Class-Path: commons-pool.jar
Class-Path: commons-services.jar
Class-Path: commons-validator.jar
Class-Path: jakarta-oro.jar
and mainfest file for commons-validator:
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1
Extension-Name: org.apache.commons.validator
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 1.0
Let me know if this helps...

Thanx,
Manisha
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 10:56 PM
To: [EMAIL PROTECTED]
Subject: RE: Validator Javascript being displayed on the jsp page
That doesn't really help us.  1.1 has been around for over a year.  What
version of 1.1 are you using?
David

>
>I am using Struts 1.1.
>
>Thanx,
>Manisha
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Monday, June 02, 2003 10:23 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Validator Javascript being displayed on the jsp page
>
>
>This sounds like a bug that was fixed some time ago.  What version are 
you
>using?
>
>David
>
>
> >From: "Manisha.Datye" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >Subject: Validator Javascript being displayed on the jsp page
> >Date: Mon, 2 Jun 2003 22:18:07 -0500
> >
> >My application is using the struts validator (struts 1.1). It has some
> >pages
> >that don't use the validator.
> >Illustration:
> >Page 1 - InitialSearch.jsp (validator)
> >Page 2 - SearchResults.jsp (no validator)
> >When the InitialSearch.jsp page is displayed the first time it displays
> >correctly. But if I navigate to the page 2 and return to page 1, the 
page

>1
> >now displays the validator javascript along with the generated jsp 
page.
> >The
> >html source is missing the script tag and the function
> >validateInitialSearchForm. As there is no start and end tag for script,
>the
> >script is displayed on the page. This happens only in the production
> >environment.
> >Any help is appreciated. Any clue on why the javascript generated by 
the
> >validator is be displayed on the jsp page ?
> >Thanx,
> >Manisha
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>_
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>-
>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]
>

_
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
-
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]
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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

Re: composable RequestProcessor

I don't want to put words in your mouth, but from the discussion, I get the 
sense that you are focused on deploying a single application.
I am focused on meeting your needs in an appropriate way (and playing a bit 
of devil's advocate).

The people who are speaking up here are all those who are trying to write 
libraries that could be used in any Struts application -- the Workflow 
extension, for example, or internally here, a "survey" application.  What 
if you wanted to include my survey library in an application which also 
used the Workflow, and you need to use Tiles but neither of us designed 
using the TilesRequestProcessor?
So, how does configuring the methods in struts-config solve that problem?  
If there are RP conflicts it seems better suited to deal with them in code.

My current belief is that xml is not flexible enough to allow good RP 
composition.  It works in the simplest of cases but I doubt it will help 
solve RP conflicts.

David

Speaking of the TilesRequestProcessor, this little chunk of code is going 
to be problematic:

protected void initRequestProcessorClass(ModuleConfig config) throws 
ServletException
{

 [--snip--]
  // Check if specified request processor is compatible with Tiles.
Class tilesProcessorClass = TilesRequestProcessor.class;
if(!tilesProcessorClass.isAssignableFrom(configProcessorClass))
  { // Not compatible
  String msg = "TilesPlugin : Specified RequestProcessor not 
compatible with TilesRequestProcessor";
  if (log.isFatalEnabled())
{
log.fatal(msg);
}
  throw new ServletException(msg);
  } // end if
}

(See TilesPlugIn, line 351).

Joe
--
--
Joe Germuska[EMAIL PROTECTED]  http://blog.germuska.com"If 
nature worked that way, the universe would crash all the time." 	--Jaron 
Lanier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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

RE: Validator Javascript being displayed on the jsp page

2003-06-04 Thread Manisha.Datye

I am not sure how to find the version of 1.1...

I have the Mainfest.mf for struts:
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1
Extension-Name: Struts Framework
Specification-Title: Struts Framework
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.1
Implementation-Title: Struts Framework
Implementation-Vendor: Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 1.1
Class-Path: commons-beanutils.jar
Class-Path: commons-collections.jar
Class-Path: commons-dbcp.jar
Class-Path: commons-digester.jar
Class-Path: commons-logging.jar
Class-Path: commons-pool.jar
Class-Path: commons-services.jar
Class-Path: commons-validator.jar
Class-Path: jakarta-oro.jar

and mainfest file for commons-validator:
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1
Extension-Name: org.apache.commons.validator
Specification-Vendor: Apache Software Foundation
Specification-Version: 1.0
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 1.0

Let me know if this helps...

Thanx,
Manisha

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 10:56 PM
To: [EMAIL PROTECTED]
Subject: RE: Validator Javascript being displayed on the jsp page


That doesn't really help us.  1.1 has been around for over a year.  What 
version of 1.1 are you using?

David


>
>I am using Struts 1.1.
>
>Thanx,
>Manisha
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Monday, June 02, 2003 10:23 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Validator Javascript being displayed on the jsp page
>
>
>This sounds like a bug that was fixed some time ago.  What version are you
>using?
>
>David
>
>
> >From: "Manisha.Datye" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >Subject: Validator Javascript being displayed on the jsp page
> >Date: Mon, 2 Jun 2003 22:18:07 -0500
> >
> >My application is using the struts validator (struts 1.1). It has some
> >pages
> >that don't use the validator.
> >Illustration:
> >Page 1 - InitialSearch.jsp (validator)
> >Page 2 - SearchResults.jsp (no validator)
> >When the InitialSearch.jsp page is displayed the first time it displays
> >correctly. But if I navigate to the page 2 and return to page 1, the page

>1
> >now displays the validator javascript along with the generated jsp page.
> >The
> >html source is missing the script tag and the function
> >validateInitialSearchForm. As there is no start and end tag for script, 
>the
> >script is displayed on the page. This happens only in the production
> >environment.
> >Any help is appreciated. Any clue on why the javascript generated by the
> >validator is be displayed on the jsp page ?
> >Thanx,
> >Manisha
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>_
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>-
>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]
>

_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


-
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: composable RequestProcessor

At 14:03 +0200 6/3/03, Matthias Bauer wrote:
One thing I am still not clear about is how granular to define which 
methods can be overwritten and how they are grouped together. I am 
saying this, because when looking at TilesRequestProcessor you see 
that it overwrites three methods: processForwardConfig, 
internalModuleRelativeForward, internalModuleRelativeInclude

Thus, it is not only the the processXXX methods that must be 
redefineable. But what is the consequence? Will we need to end up in 
something like this?


 




...
 


I guess the final consequence would be to allow each single method 
of the request processor to be replaced by configuration. Do we 
really want to do this? I am tempted to say no, but I don't see an 
alternative right now.
In this specific case, those "internal*" methods are called by 
"processForward" and "processInclude", each of which have only about 
four lines of code in the base RequestProcessor.  Those four lines of 
code (basically, "should I even process this Forward (or include)") 
could be factored out into protected methods that can be called by 
subclass implementations, or, probably better, the checks could just 
be implemented in the "process()" template method which manages the 
overall lifecycle.  Then the "internal*" methods would be pushed up 
into processForward and processInclude and the responsibilities would 
be clearer -- "process()" has the responsibility for deciding which 
lifecycle methods to call and in what order, and the methods 
themselves can be a bit simpler.

I would say that based on what we have now, only "process*" methods 
should be part of a general interface, or perhaps it makes sense two 
make two larger interfaces (for Action and Dispatch processing, along 
the lines suggested by Peter Pilgrim 


Joe

--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

Re: composable RequestProcessor