Re: Struts Jericho DTD

2004-03-14 Thread Ted Husted 
On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
> 
>   exception="com.mckesson.smo.AuthorizationException" />  /> 

This reminds me of the Maverick approach, which is both simple and effective.

> Just some ideas... I've been working on developing a mock version
> of this between projects at work.

What I would like to do is develop Struts 2.0 test-first. The idea being we cold start 
with a simple application and write just enough of 2.0 to develop the first page (or 
story). Then just enough to develop the second page, and so forth. Each component 
developed would have to be fully testable outside of a servlet/portlet/soap 
environment.

Of  course, no one application can represent all of the use cases a framework like 
Struts must support, so after an initial sample application,we could start on the 
Struts Cookbook application Steve Raeburn suggested. A very important point being that 
no feature would be added without conventional unit tests and a working example use 
case.

In doing this, I wouldn't feel constrained to anything we put on the whiteboard, so we 
could try this or that in the context of working examples.

Right now, I'm refactoring the MailReader application in hope of using it as the 
test-first foundation for Struts 2.0, and also exploring how other frameworks are 
solving similar problems.

-Ted.



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

DO NOT REPLY [Bug 5739] - Struts fails silently in too many places

2004-03-14 Thread bugzilla 
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://issues.apache.org/bugzilla/show_bug.cgi?id=5739

Struts fails silently in too many places





--- Additional Comments From [EMAIL PROTECTED]  2004-03-15 02:26 ---
Created an attachment (id=10778)
Schema based on struts_1_1.dtd

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

DO NOT REPLY [Bug 5739] - Struts fails silently in too many places

2004-03-14 Thread bugzilla 
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://issues.apache.org/bugzilla/show_bug.cgi?id=5739

Struts fails silently in too many places





--- Additional Comments From [EMAIL PROTECTED]  2004-03-15 02:23 ---

I'm attaching in the next post, an XML schema whose type structure is based on
the struts-1_1.dtd.  

In addition to doing uniqueness checks
(i.e. validating that form bean name's
and action paths are unique), this schema
also does a referential integrity check to
validate the reference to a form bean name
within an action definition.

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

Re: Reviving Struts-Chain (was ... PageController ...)

2004-03-14 Thread Ted Husted 
On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote:
> At 11:59 AM -0500 3/14/04, Ted Husted wrote:
>> On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote:
> No one is more gung-ho about Struts Chain than I am, but people
> should be aware that we're still just into beta with functionality.
> Using it on my latest project, I've definitely found a few pieces
> that hadn't yet been implemented.  I've put in what I found missing
> -- tiles and file upload -- but there are probably some other less
> mainstream pieces that will turn out to be buggy or not even
> implemented.  We would probably want to make a branching CVS tag
> for this if we do it.  I don't have a lot of experience working on
> branched codebases with a distributed team, so it should be an
> interesting ride, but I think Struts Chain is far enough from ready
> that we don't have a choice.

I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3.

IMHO, the quickest way to sort out what we need to do with the Struts-Chain 
RequestProcessor is to get it out there as the nightly build. [Many hands make light 
work ;)]

So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do 
anything resembling new development against the HEAD (1.3).


> Plus, we need to push commons-chain to a full release.  And what
> about commons-resources?  That sounded like it was pretty close.
> Looking at http://jakarta.apache.org/struts/status.html , I think
> that roadmap may be still be a good strategy -- get the resources
> transition done for 1.3, then the new request processor for 1.4.
> Can anyone summarize what's standing between here and moving to
> commons-resources?

I think Commons Chain can move up any time we wanted. It's just a matter of floating a 
vote.

The Resources thing has been a longtime coming and should be stable. I wouldn't 
hesitate to do both Resources and Struts Chain in the HEAD now.


> In general, I'm satisfied with targeting the "page prep" as a chain-
> dependent feature.  If we introduce a StrutsContext as the chain
> implementation of o.a.c.chain.Context  then we'll have to come up
> with a Context factory process so that the
> ComposableRequestProcessor can be given a Context instead of
> instantiating one itself.  My first hunch is that it should be an
> early chain command which creates a sub-context of a specific type
> and uses it to do most of the chain processing.
>
> Joe



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

Re: Reviving Struts-Chain (was ... PageController ...)

2004-03-14 Thread Joe Germuska 
At 11:59 AM -0500 3/14/04, Ted Husted wrote:
On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote:
 

 Is now a good time to coin a "StrutsContext" class that
 encapsulates the various arguments to "execute"?  I've always kind
 of wanted this for Action too.  I've frequently thought it would be
 a nice thing. This seems to get a little blurry when looking
 forward to a more chain-oriented Struts, where there's already a
 Context object floating through, but it seems worth discussing if
 we're making a new interface.
 I'd say that this is a good time to introduce a StrutsContext -AND- 
make Struts Chain the default request processor.
No one is more gung-ho about Struts Chain than I am, but people 
should be aware that we're still just into beta with functionality. 
Using it on my latest project, I've definitely found a few pieces 
that hadn't yet been implemented.  I've put in what I found missing 
-- tiles and file upload -- but there are probably some other less 
mainstream pieces that will turn out to be buggy or not even 
implemented.  We would probably want to make a branching CVS tag for 
this if we do it.  I don't have a lot of experience working on 
branched codebases with a distributed team, so it should be an 
interesting ride, but I think Struts Chain is far enough from ready 
that we don't have a choice.

Plus, we need to push commons-chain to a full release.  And what 
about commons-resources?  That sounded like it was pretty close. 
Looking at http://jakarta.apache.org/struts/status.html , I think 
that roadmap may be still be a good strategy -- get the resources 
transition done for 1.3, then the new request processor for 1.4.  Can 
anyone summarize what's standing between here and moving to 
commons-resources?

In general, I'm satisfied with targeting the "page prep" as a 
chain-dependent feature.  If we introduce a StrutsContext as the 
chain implementation of o.a.c.chain.Context  then we'll have to come 
up with a Context factory process so that the 
ComposableRequestProcessor can be given a Context instead of 
instantiating one itself.  My first hunch is that it should be an 
early chain command which creates a sub-context of a specific type 
and uses it to do most of the chain processing.

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
  "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
-- Jef Raskin

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

Re: Reviving Struts-Chain (was ... PageController ...)

2004-03-14 Thread Ted Husted 
On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote:
> 
>
> Is now a good time to coin a "StrutsContext" class that
> encapsulates the various arguments to "execute"?  I've always kind
> of wanted this for Action too.  I've frequently thought it would be
> a nice thing. This seems to get a little blurry when looking
> forward to a more chain-oriented Struts, where there's already a
> Context object floating through, but it seems worth discussing if
> we're making a new interface.

 I'd say that this is a good time to introduce a StrutsContext -AND- make Struts Chain 
the default request processor.

My guess is that these components would affect how a PageController is realized, so 
let's go ahead and do that now. I believe it's been "hovering over the airport" longer 
than PageController anyway. :)

As for the PageController, based on the need I've seen for it in my own applications, 
I'm starting to think of it as a "Page Initialization" block: A place where we can 
fold, spindle, or mutilate the data we need to use with the controls on a page.

-Ted.



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

Bug report for Struts [2004/03/14]

2004-03-14 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward|
| 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag -> calls method to populate se|
| 5395|Opn|Enh|2001-12-12|ActionContext class   |
| 5566|New|Enh|2001-12-21|html:link bug |
| 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places  |
| 5937|New|Enh|2002-01-21|html:form trims all extensions|
| 6686|New|Enh|2002-02-26|make "action" attribute of html:form tag optional |
| 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart|
| 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application|
| 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does|
| 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma|
| 9616|New|Enh|2002-06-05|Some more Struts docs |
| 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag|
|10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards|
|10551|Opn|Enh|2002-07-08|Allow a struts-config element to extend another   |
|10552|New|Enh|2002-07-08|create helper objects in struts-config|
|10867|Opn|Enh|2002-07-16|Add indexedProperty attribute in html taglibs |
|11154|Opn|Enh|2002-07-25|html:link tag extension for multiple parameters   |
|11733|Opn|Enh|2002-08-15|Make error keys more specific |
|12170|Opn|Enh|2002-08-29|Added functionality when extending another definit|
|12301|Opn|Enh|2002-09-04|nested:messages Tag does not work as expected |
|12313|Opn|Enh|2002-09-04|Chaining of RequestProcessors--contribution   |
|12342|Ass|Enh|2002-09-05|Add default exception handler attribute to  ta|
|13521|New|Enh|2002-10-11|CombinedDispatchAction|
|13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths |
|13565|Opn|Enh|2002-10-12|To "errors", add prefix, suffix, header, footer at|
|13638|Opn|Enh|2002-10-15|add Config Factory|
|14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i|
|14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce|
|14183|New|Enh|2002-11-01|html:img does not support forward attribute   |
|14749|Opn|Enh|2002-11-21|Action "input" not starting with '/' and not a val|
|15023|Opn|Enh|2002-12-03|Use attribute 'id' instead of 'name' in html:form-|
|15188|Opn|Enh|2002-12-09|roles attribute of tags and definitions only allow|
|15422|Opn|Enh|2002-12-17|Form Tag exportFormName  attribute|
|15604|Opn|Enh|2002-12-22|Struts framework should use getInstance Method for|
|15670|Opn|Enh|2002-12-26|Doc for "exception" element needs to mention "page|
|15673|Opn|Enh|2002-12-26|Default Action in ActionMapping   |
|15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E|
|15816|Opn|Enh|2003-01-06|html:form focus in pages with several forms   |
|15849|Opn|Enh|2003-01-07|Incorrect documentation for "Developing Your Own M|
|15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field|
|15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml   |
|15935|Opn|Enh|2003-01-09|WSAD 5.0 Instructions for Struts Example  |
|15969|Opn|Enh|2003-01-10|Ability to use TilesRequestProcessor even if it no|
|16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp|
|16104|Opn|Enh|2003-01-15|default handler parameter value for LookupDispatch|
|16107|Opn|Enh|2003-01-15|Configure if you want to call ActionForm.reset() i|
|16207|Opn|Enh|2003-01-17|Add ability to import tile attributes into a java.|
|16249|Opn|Enh|2003-01-20|localized float validation|
|16388|Opn|Enh|2003-01-24|documentation of the currentPlugInConfigObject|
|16401|New|Enh|2003-01-24|ActionValidatorUtil   |
|16480|Opn|

cvs commit: jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold BaseAction.java BaseForm.java BaseHelperAction.java BaseMapForm.java BizAction.java ProcessAction.java ProcessDispatchAction.java ProcessFormAction.java

2004-03-14 Thread husted 
husted  2004/03/14 06:32:20

  Modified:contrib/scaffold NOTICE.txt
   contrib/scaffold/src/java/org/apache/struts/scaffold
BaseAction.java BaseForm.java BaseHelperAction.java
BaseMapForm.java BizAction.java ProcessAction.java
ProcessDispatchAction.java ProcessFormAction.java
  Log:
  Move copyrights to NOTICE.txt to conform with new format.
  
  Revision  ChangesPath
  1.2   +5 -3  jakarta-struts/contrib/scaffold/NOTICE.txt
  
  Index: NOTICE.txt
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/scaffold/NOTICE.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- NOTICE.txt14 Mar 2004 07:15:06 -  1.1
  +++ NOTICE.txt14 Mar 2004 14:32:19 -  1.2
  @@ -3,6 +3,9 @@
   
   
   
  +Regarding: BaseAction, BaseForm, BaseHelperAction, BaseMapForm, BizAction,
  +ProcessAction, ProdcessDispatchAction and ProcessFormAction
  +
   Copyright (c) 2002 Synthis Corporation.
   430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A.
   All rights reserved.
  @@ -10,8 +13,7 @@
   This software is licensed to you free of charge under
   the Apache Software License, so long as this copyright
   statement, list of conditions, and comments,  remains
  -in the source code.  See bottom of file for more
  -license information.
  +in the source code.
   
   This software was written to support code generation
   for the Apache Struts J2EE architecture by Synthis'
  @@ -22,7 +24,7 @@
   
   
   
  -Contains code derived from the Jetty SnoopServlet
  +"SnoopAction.java" contains code derived from the Jetty SnoopServlet
   http://www.thecortex.net/clover/eg/jetty/report/default-pkg/SnoopServlet.html>
   and distributed under its open source license
   http://jetty.mortbay.org/jetty/LICENSE.html>.
  
  
  
  1.11  +4 -23 
jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseAction.java
  
  Index: BaseAction.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseAction.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- BaseAction.java   14 Mar 2004 07:15:03 -  1.10
  +++ BaseAction.java   14 Mar 2004 14:32:19 -  1.11
  @@ -17,25 +17,6 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
  - 
  - 
  -//Copyright (c) 2002 Synthis Corporation.
  -//430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A.
  -//All rights reserved.
  -//
  -//This software is licensed to you free of charge under
  -//the Apache Software License, so long as this copyright
  -//statement, list of conditions, and comments,  remains
  -//in the source code.  See bottom of file for more
  -//license information.
  -//
  -//This software was written to support code generation
  -//for the Apache Struts J2EE architecture by Synthis'
  -//visual application modeling tool Adalon.
  -//
  -//For more information on Adalon and Struts code
  -//generation please visit http://www.synthis.com 
  - 
   package org.apache.struts.scaffold;
   
   
  
  
  
  1.15  +4 -27 
jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java
  
  Index: BaseForm.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- BaseForm.java 14 Mar 2004 07:15:03 -  1.14
  +++ BaseForm.java 14 Mar 2004 14:32:19 -  1.15
  @@ -17,29 +17,6 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
  -
  -/*
  - *
  - *Copyright (c) 2002 Synthis Corporation.
  - *430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A.
  - *All rights reserved.
  - *
  - *This software is licensed to you free of charge under
  - *the Apache Software License, so long as this copyright
  - *statement, list of conditions, and comments,  remains
  - *in the source code.  See bottom of file for more
  - *license information.
  - *
  - *This software was written to support code generation
  - *for the Apache Struts J2EE architecture by Synthis'
  - *visual application modeling tool Adalon.
  - *
  - *For more information on Adalon and Struts code
  - *generation please visit http://www.synthis.com
  - *
  - */
  - 
  -   
   package org.a

Re: Apache License 2.0

2004-03-14 Thread Ted Husted 
On Sat, 13 Mar 2004 23:51:52 -0800, Steve Raeburn wrote:
> 3. Scaffold additional copyright notices:
>
> There are some additional copyright notices in some of the Scaffold
> files. I don't know if this is acceptable any longer under the new
> license.
>
> -- o.a.s.scaffold.Base Action -->
> Copyright (c) 2002 Synthis Corporation.
> 430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A. All
> rights reserved.
>
> This software is licensed to you free of charge under the Apache
> Software License, so long as this copyright statement, list of
> conditions, and comments,  remains in the source code.  See bottom
> of file for more license information.
>
> This software was written to support code generation for the Apache
> Struts J2EE architecture by Synthis' visual application modeling
> tool Adalon.
>
> For more information on Adalon and Struts code
> generation please visit http://www.synthis.com
>
>
> -- o.a.s.scaffold.SnoopServlet Action -->
> Derived from the Jetty SnoopServlet
>  pkg/SnoopServle t.html> and distributed under its open source
> license .
>
>
> I have added the licenses to the Scaffold notice file, which I
> think is where attributions should go. For now, I've also left them
> in the source files as well. What should we do with these?

Brian did say they don't want us redistributing other's people's distributions. 
However, this is a situation where our unique software product is derived from a 
compatible license or outright donation. This is code created and/or maintained by the 
ASF, which we can distribute under our own license and joint copyright.

In other words, we are doing with others, what we expect others to do with us :)

The Notices file seems sufficient.


> 4. I've only updated the Java source files. What other files need
> to have an ASL 2.0 license? XML docs? Struts DTD?

These could be done, but I don't know if we need to do it proactively or just as we 
touch things. I don't think it's the board's intention to turn this into a make-work 
project.

-Ted.




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

Re: Reviving PageController (ViewController?) discussion?

2004-03-14 Thread Hubert Rabago 
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> However, I can see using the contents of the forward element as a way 
> to provide more than one form bean to the renderer.  I'll think about 
> this some more.  How would you actually make them available to the 
> renderer?  Via a map?  Expect the renderer to fish them out of 
> request or session scope?

I was thinking we could have one renderer per form.  This way, if a form gets
reused by different views, the renderer can be reused as well.  With this, a
slightly modified version of your initial draft for the renderer's method
signature could be used:

public void render(ForwardConfig config, ActionForm form, 
HttpServletRequest request, HttpServletResponse response) 
throws Exception;

I would also suggest giving the method access to the ServletContext and/or
ModuleConfig.  Somehow.  It could be argued that even if the
one-ForwardConfig-instance implementation is preserved, a ForwardConfig
instance only applies to one module, so it could carry the ServletContext and
ModuleConfig into the render method.

> >Either way, it's looking like it might make sense to move the scope
> setting
> >to the form definition, or at least allow a default setting there which
> will
> >be honored if an action mapping doesn't specify a form scope.  (Could be a
> >topic for another thread)
> 
> I don't think I agree with this, or at least, I think you have to 
> preserve the possibility that different actions would want to use the 
> same form definition in different scopes.  I don't think that would 
> be a very good design, because of the risk of confusion, but I'm not 
> ready to say we should block it.
> 
> Obviously we can't move the scope setting without sacrificing 
> backwards compatibility -- that is, we can't move it at all, since we 
> won't sacrifice compatibility -- although we could have a default 
> scope on the form bean if that were helpful.  I'm not sure I see that 
> it is, but we can see...

I agree about the backward compatibility concern.  The issue I see is how the
RequestProcessor will store the "output" form that the Renderer prepopulated.
 Right now, the scope is dictated by the Action receiving the form.  How
would the RP know what that is?  Even if the point of prepopulation is to
allow the form to be rendered, thus making it possible for the RP to store it
in request scope and be discarded once the view is rendered, a session scoped
form might be prepopulated with fields that the immediate view will not use
but needs to be preserved for a later purpose.  Storing that in request scope
by default wouldn't work.  I'm not sure I'm comfortable with the other option
either, which is to store the "output" form in session scope, since the
receiving Action could've only specified the request scope.  I wouldn't mind
being enlightened, though.

- Hubert


__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

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