http://struts.apache.org/dtds/struts-2.0.dtd needs to be updated

[matt.payne]

I believe struts 2.0.9 and up allow use of the tag "default-class-ref".  However the dtd reference online is old and still is missing this tag.

I'd like to take advantage of this tag using configuration inheritance to create abstract crud templates for crud actions.  

<package name="Abstract-crud" extends="struts-default" abstract="true">
  <!--  edit is often used as the create/view -->
                <action name="edit" >
                        <result name="input" type="velocity">edit.vm</result>
                        <result name="success" type="velocity">edit.vm</result>
                        <result name="error" type="velocity">edit.vm</result>
                </action>
                <action name="save" >
                        <result name="input" type="velocity">edit.vm</result>
                        <result name="success" type="chain">list</result>
                        <result name="error" type="velocity">edit.vm</result>
                        <result name="cancel" type="redirect">list.action</result>
                </action>
                <action name="list" method="list">
                        <result name="success" type="redirectAction">list</result>
                </action>
                <action name="delete" method="delete">
                        <result name="success" type="redirectAction">list</result>
                </action>

        </package>
       
       
        <package name="Example" extends="Abstract-crud" namespace="/example">
                 <default-class-ref class="org.ExampleAction" />
        </package>

        <package name="Example2" extends="Abstract-crud" namespace="/example2">
                <default-class-ref class="org.Example2Action" />
                <action name="override" class="org.Example2Action" method="override">
                        <result name="success" type="velocity">somethingelse.vm</result>
                </action>
        </package>

        <package name="SubItem" extends="Abstract-crud" namespace="/example2/subItem">
                <default-class-ref class="org.SubItemAction" />
        </package>

Despite what Don Brown originally said about this tag, if it can be used in this mode, I believe its even more useful than "default-action-ref"  
 
Matt Payne

[matt.payne]

Never mind the "default-class-ref" is completely useless if there is not a way to indicate that the actions should be constructed with this class substituted.


With this setup.
<package name="Abstract-crud" extends="myDefault" abstract="true">
  <!--  edit is often used as the create/view -->
                <action name="edit" >
                        <result name="input" type="velocity">edit.vm</result>
                        <result name="success" type="velocity">edit.vm</result>
                        <result name="error" type="velocity">edit.vm</result>
                </action>
                <action name="save" >
                        <result name="input" type="velocity">edit.vm</result>
                        <result name="success" type="chain">list</result>
                        <result name="error" type="velocity">edit.vm</result>
                        <result name="cancel" type="redirect">list.action</result>
                </action>
                <action name="list" method="list">
                        <result name="success" type="redirectAction">list</result>
                </action>
                <action name="delete" method="delete">
                        <result name="success" type="redirectAction">list</result>
                </action>

        </package>
       
        <package name="Example" extends="Abstract-crud" namespace="/example">
                 <default-class-ref class="org.ExampleAction" />
        </package>

Despite org.ExampleAction having a list method, invoking /example/list.action

throws --->

com.opensymphony.xwork2.ActionSupport.list()

RequestURI=/quartz/jobs/definition/list.action
Caused by:

java.lang.NoSuchMethodException: com.opensymphony.xwork2.ActionSupport.list()

I expected my action would be substituted.  I am assuming this this behavior is broken is default-class-ref hasn't been well exercised in the wild.

Still looking for a wildcard/template solution that would allow use of packageName from the wildcard.

Matt

[Chris Pratt]

<default-class-ref> sets what class will be used when an <action> tag
doesn't include a class="" attribute.  I use it to substitute my
BaseAction for the default Action implementation, so that I can easily
handle Authentication/Authorization without having to specify the
class attribute on every action.  Not the hugest win in the world, but
it saves some typing on larger projects.
  (*Chris*)

On Jan 10, 2008 12:08 PM, matt.payne <matthew.b.payne@...> wrote:

>
>
> Never mind the "default-class-ref" is completely useless if there is not a
> way to indicate that the actions should be constructed with this class
> substituted.
>
>
> With this setup.
> <package name="Abstract-crud" extends="myDefault" abstract="true">
>                 <!--  edit is often used as the create/view -->
>                 <action name="edit" >
>                         <result name="input" type="velocity">edit.vm</result>
>                         <result name="success" type="velocity">edit.vm</result>
>                         <result name="error" type="velocity">edit.vm</result>
>                 </action>
>                 <action name="save" >
>                         <result name="input" type="velocity">edit.vm</result>
>                         <result name="success" type="chain">list</result>
>                         <result name="error" type="velocity">edit.vm</result>
>                         <result name="cancel" type="redirect">list.action</result>
>                 </action>
>                 <action name="list" method="list">
>                         <result name="success" type="redirectAction">list</result>
>                 </action>
>                 <action name="delete" method="delete">
>                         <result name="success" type="redirectAction">list</result>
>                 </action>
>
>         </package>
>
>         <package name="Example" extends="Abstract-crud"
> namespace="/example">
>                  <default-class-ref class="org.ExampleAction" />
>         </package>
>
> Despite org.ExampleAction having a list method, invoking
> /example/list.action
>
> throws --->
>
> com.opensymphony.xwork2.ActionSupport.list()
>
> RequestURI=/quartz/jobs/definition/list.action
> Caused by:
>
> java.lang.NoSuchMethodException:
> com.opensymphony.xwork2.ActionSupport.list()
>
> I expected my action would be substituted.  I am assuming this this behavior
> is broken is default-class-ref hasn't been well exercised in the wild.
>
> Still looking for a wildcard/template solution that would allow use of
> packageName from the wildcard.
>
> Matt
> --
> View this message in context: http://www.nabble.com/http%3A--struts.apache.org-dtds-struts-2.0.dtd-needs-to-be-updated-tp14742352p14742757.html
>
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[matt.payne]

It would be a ton more useful if it could provide the default class for actions defined in a abstract parent package, where the implementation class for those actions was not specified.
(did that make sense)

Matt

Chris Pratt wrote:

<default-class-ref> sets what class will be used when an <action> tag
doesn't include a class="" attribute.  I use it to substitute my
BaseAction for the default Action implementation, so that I can easily
handle Authentication/Authorization without having to specify the
class attribute on every action.  Not the hugest win in the world, but
it saves some typing on larger projects.
  (*Chris*)

On Jan 10, 2008 12:08 PM, matt.payne <[e-mail]> wrote:
>
>
> Never mind the "default-class-ref" is completely useless if there is not a
> way to indicate that the actions should be constructed with this class
> substituted.
>
>
> With this setup.
> <package name="Abstract-crud" extends="myDefault" abstract="true">
>                 <!--  edit is often used as the create/view -->
>                 <action name="edit" >
>                         <result name="input" type="velocity">edit.vm</result>
>                         <result name="success" type="velocity">edit.vm</result>
>                         <result name="error" type="velocity">edit.vm</result>
>                 </action>
>                 <action name="save" >
>                         <result name="input" type="velocity">edit.vm</result>
>                         <result name="success" type="chain">list</result>
>                         <result name="error" type="velocity">edit.vm</result>
>                         <result name="cancel" type="redirect">list.action</result>
>                 </action>
>                 <action name="list" method="list">
>                         <result name="success" type="redirectAction">list</result>
>                 </action>
>                 <action name="delete" method="delete">
>                         <result name="success" type="redirectAction">list</result>
>                 </action>
>
>         </package>
>
>         <package name="Example" extends="Abstract-crud"
> namespace="/example">
>                  <default-class-ref class="org.ExampleAction" />
>         </package>
>
> Despite org.ExampleAction having a list method, invoking
> /example/list.action
>
> throws --->
>
> com.opensymphony.xwork2.ActionSupport.list()
>
> RequestURI=/quartz/jobs/definition/list.action
> Caused by:
>
> java.lang.NoSuchMethodException:
> com.opensymphony.xwork2.ActionSupport.list()
>
> I expected my action would be substituted.  I am assuming this this behavior
> is broken is default-class-ref hasn't been well exercised in the wild.
>
> Still looking for a wildcard/template solution that would allow use of
> packageName from the wildcard.
>
> Matt
> --
> View this message in context: http://www.nabble.com/http%3A--struts.apache.org-dtds-struts-2.0.dtd-needs-to-be-updated-tp14742352p14742757.html
>
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

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

[Chris Pratt]

On Jan 10, 2008 1:15 PM, matt.payne <matthew.b.payne@...> wrote:
>
> It would be a ton more useful if it could provide the default class for
> actions defined in a abstract parent package, where the implementation class
> for those actions was not specified.
> (did that make sense)
>
> Matt
>

I'm not sure what you mean by the "abstract parent package", otherwise
that seems like exactly what it does.  If you create a package in
struts.xml and define the default-class-ref, then create another
package that extends the first, it should inherit the
default-class-ref from the parent package.
  (*Chris*)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[matt.payne]

Chris Pratt wrote:

On Jan 10, 2008 1:15 PM, matt.payne <[e-mail]> wrote:
>
> It would be a ton more useful if it could provide the default class for
> actions defined in a abstract parent package, where the implementation class
> for those actions was not specified.
> (did that make sense)
>
> Matt
>

I'm not sure what you mean by the "abstract parent package", otherwise
that seems like exactly what it does.  If you create a package in
struts.xml and define the default-class-ref, then create another
package that extends the first, it should inherit the
default-class-ref from the parent package.
  (*Chris*)

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

My expectation would be that child package would override "default-class-ref" and have that applied/substituted to the actions defined in the parent.

[newton.dave]

--- "matt.payne" <matthew.b.payne@...> wrote:

> Chris Pratt wrote:
> > On Jan 10, 2008 1:15 PM, matt.payne <matthew.b.payne@...> wrote:
> >> It would be a ton more useful if it could provide the default class for
> >> actions defined in a abstract parent package, where the implementation
> >> class for those actions was not specified.
> > I'm not sure what you mean by the "abstract parent package", otherwise
> > that seems like exactly what it does.  If you create a package in
> > struts.xml and define the default-class-ref, then create another
> > package that extends the first, it should inherit the
> > default-class-ref from the parent package.
> My expectation would be that child package would override
> "default-class-ref" and have that applied/substituted to the actions
> defined in the parent.

Isn't that sort of backwards to how inheritance works? A child package
defines behavior for it and its children, not its parents.

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[matt.payne]

No not backwards at all.  It is exactly how inheritance works.  A child is free to override in case it wants to provide its own implementation of something.

Sure a child package inherits things from the parent.  With that in mind a child can override settings.  
e.g child says given me you settings, except namespace="/x".  When a child does that, all this actions appear under /contextName/x.

A child can also redefine the interceptor stack for a package.  Say the interceptor stack for the parent package includes some security interceptor and is under namespace "/secure", and child is free to redefine that interceptor stack for the package so it does not to include the security interceptor and say the namespace ="/demo".  A child can do this without redefining all the actions again.  

In this light it would appear to be a bug, that "default-class-ref" couldn't be overriden by the children.

Matthew Payne

newton.dave wrote:

--- "matt.payne" <[e-mail]> wrote:
> Chris Pratt wrote:
> > On Jan 10, 2008 1:15 PM, matt.payne <[e-mail]> wrote:
> >> It would be a ton more useful if it could provide the default class for
> >> actions defined in a abstract parent package, where the implementation
> >> class for those actions was not specified.
> > I'm not sure what you mean by the "abstract parent package", otherwise
> > that seems like exactly what it does.  If you create a package in
> > struts.xml and define the default-class-ref, then create another
> > package that extends the first, it should inherit the
> > default-class-ref from the parent package.
> My expectation would be that child package would override
> "default-class-ref" and have that applied/substituted to the actions
> defined in the parent.

Isn't that sort of backwards to how inheritance works? A child package
defines behavior for it and its children, not its parents.

d.

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

[matt.payne]

Sorry about my last message.  I wasn't sure if your response was directed to Chris or myself.

newton.dave wrote:

--- "matt.payne" <[e-mail]> wrote:
> Chris Pratt wrote:
> > On Jan 10, 2008 1:15 PM, matt.payne <[e-mail]> wrote:
> >> It would be a ton more useful if it could provide the default class for
> >> actions defined in a abstract parent package, where the implementation
> >> class for those actions was not specified.
> > I'm not sure what you mean by the "abstract parent package", otherwise
> > that seems like exactly what it does.  If you create a package in
> > struts.xml and define the default-class-ref, then create another
> > package that extends the first, it should inherit the
> > default-class-ref from the parent package.
> My expectation would be that child package would override
> "default-class-ref" and have that applied/substituted to the actions
> defined in the parent.

Isn't that sort of backwards to how inheritance works? A child package
defines behavior for it and its children, not its parents.

d.

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

[newton.dave]

--- "matt.payne" <matthew.b.payne@...> wrote:
> In this light it would appear to be a bug, that "default-class-ref"
> couldn't be overriden by the children.

Oh, I understand what you're saying now.

I always assumed that a default-class-ref was valid only for the package it
was being defined in, and I'm pretty sure that's the behavior I'd want.
Others may disagree.

I use class-less action definitions for non-dynamic pages; if I had an
extending package I wouldn't want a default-class-ref to modify the behavior
of the parent package.

d.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ted Husted]

On Jan 13, 2008 10:34 PM, matt.payne <matthew.b.payne@...> wrote:
> No not backwards at all.  It is exactly how inheritance works.  A child is
> free to override in case it wants to provide its own implementation of
> something.

It's how configuration works, when there "can be only one"
configuration setting. But it is not how inheritance works in
languages like Java.

In the case of this particular setting, I would say that each package
should be allowed its own copy of the setting, and that if we change
the setting for a child, then only its children inherit the setting.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[matt.payne]

I created the Jira issue for xwork.

http://jira.opensymphony.com/browse/XW-603

Ted Husted wrote:

On Jan 13, 2008 10:34 PM, matt.payne <[e-mail]> wrote:
> No not backwards at all.  It is exactly how inheritance works.  A child is
> free to override in case it wants to provide its own implementation of
> something.

It's how configuration works, when there "can be only one"
configuration setting. But it is not how inheritance works in
languages like Java.

In the case of this particular setting, I would say that each package
should be allowed its own copy of the setting, and that if we change
the setting for a child, then only its children inherit the setting.

-Ted.

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

[matt.payne]

Not to forget.  The dtd file located here -->
http://struts.apache.org/dtds/struts-2.0.dtd 

Still needs to be updated to include default-class-ref

Can someone update the site?

Matt


I created the Jira issue for xwork.

http://jira.opensymphony.com/browse/XW-603

Ted Husted wrote:

On Jan 13, 2008 10:34 PM, matt.payne <[e-mail]> wrote:
> No not backwards at all.  It is exactly how inheritance works.  A child is
> free to override in case it wants to provide its own implementation of
> something.

It's how configuration works, when there "can be only one"
configuration setting. But it is not how inheritance works in
languages like Java.

In the case of this particular setting, I would say that each package
should be allowed its own copy of the setting, and that if we change
the setting for a child, then only its children inherit the setting.

-Ted.

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