Re: [PROPOSAL] Struts infrastructure changes

[Jeff Turner]

On Sat, Mar 20, 2004 at 09:44:23AM -0800, David Graham wrote:
...
> I've expressed my opposition to this on commons-dev so I'll sum up my
> points here:
...
> 2.  We've been fairly consistent with tracking corresponding bugzilla
> bug numbers in the cvs commit messages.  This has proved extremely
> valuable when researching and fixing bugs.  I would hate to lose that
> meta data.

The Bugzilla ID is preserved in JIRA.  I've just added a "search by old
Bugzilla ID" portlet to the default JIRA front page, to make this
searchable:

http://issues.apache.org/jira/

For instance, typing in 15216 will redirect to XMLRPC-21.  If the ID
isn't found in JIRA, the user is redirected to Bugzilla's
show_bug.cgi?id=... URL.

Incidentally, JIRA 2.6 has a "Version Control" tab for each issue,
populated by the CVS commit messages mentioning the bug's key, and
pointing to file diffs in ViewCVS.  If people are diligent about bug
references in commit logs, this can be quite useful.  Screenshot at:

http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes


--Jeff

...
> David
> 
> > 
> > 
> > One other thing is that we'll want to get external mail archivers to
> > switch to the new mailing lists once those are set up. I'm not clear on
> > whether the infrastructure folks arrange that or we need to do it
> > ourselves, but I'll ask when I submit the above.
> > 
> > Anything else I missed? (There are a lot of internal changes we'll want
> > to
> > make as well, but I'm not trying to address those here.)
> > 
> > --
> > Martin Cooper
> > 

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

Re: [PROPOSAL] Struts infrastructure changes

[Martin Cooper]

On Sat, 20 Mar 2004, Craig R. McClanahan wrote:

> Miscellaneous comments intermixed.
>
> Quoting Martin Cooper <[EMAIL PROTECTED]>:
>
> > The following is a set of proposed changes to the Apache infrastructure to
> > accommodate the Struts move to an Apache top level project. The idea is to
> > come up with a single agreed-upon set of changes that we can submit to the
> > infrastructure folks as a single request, rather than submitting each one
> > piecemeal. Your feedback is appreciated.
> >
> > Mailing Lists
> >   New mail domain: struts.apache.org
> >   The following lists are standard for an Apache TLP:
> > user@
> > dev@
> > cvs@ (usually forwarded to dev@)
>
> I would like to maintain our current practice that these are *always* forwarded
> to dev, instead of it being a separate mailing list.

I think we agree. ;-) Currently, commit messages go to a separate list
(jakarta-struts-cvs) which is forwarded to (or otherwise sent to the same
people as on) struts-dev. My intent (poorly worded, I admit) was to retain
that same mechanism.

>
> > pmc@
>
> As noted in other messages in this thread, we need an announcements list too.
> >   Moderator: Ted Husted (same as today)
> >   Existing subscribers need to be migrated.
> >   Old list addresses should be forwarded for some period of time.
> >
> > Web Site
> >   New virtual host: struts.apache.org
> >   Redirect from jakarta.apache.org/struts for some period of time.
> >   Writeable by group: struts (see below)
> >
> > Wiki
> >   New wiki: wiki.apache.org/struts
> >   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
> >
>
> This would be on the Apache infrastructure, right?

Yes, wiki.apache.org is the MoinMoin wiki that Leo set up to replace the
UseModWiki installation on nagoya.

>
> > Unix Group
> >   New group: struts
> >   Members: (Struts PMC members)
>
> It would ultimately need to include all of the committers (not just PMC
> members), in order for CVS commits to actually work.

Um, yes, you're right, of course.

>
> >
> > Source Control
> >   Old CVS repo: jakarta-struts
> >   New CVS repo: struts
>
> This can certainly be a starting point.  We should consider whether it's worth
> separating subprojects into their own repositories for ease of management
> purposes (but I agree with your other comments that commit karma would still be
> to all subprojects, no matter how this decision comes out).

Yes. See my message on a separate thread regarding our options, and my
preference, here. (In short: start with one repo, and split when we really
know what we want.)

>
> >   Optional: Move to Subversion (IMO, not now, but we can discuss.)
> >
>
> Given the amount of work this would involve, and assuming we can import our CVS
> log history somehow, this would be OK with me; but seems like something we
> could also defer to later after the dust settles.

My feeling on Subversion is that it's not quite ready for prime time yet.
I've been watching other projects migrate, and I've seen problems crop up
that have warranted new point versions of SVN. As David pointed out,
client support is also somewhat lacking today, compared to CVS.

Together with the fact that I can support just about any manipulation of
CVS that we might decide to do, but I'm completely clueless about SVN,
makes me want to stick with CVS for now.

--
Martin Cooper


>
> > Bug Database
> >   Optional: Move to Jira (IMO, now's as good a time as any.)
>
> I'm OK with either Jira or Bugzilla.  Note that other projects migrating to Jira
> have been able to import their bug history, so we wouldn't lose that.
>
> > One other thing is that we'll want to get external mail archivers to
> > switch to the new mailing lists once those are set up. I'm not clear on
> > whether the infrastructure folks arrange that or we need to do it
> > ourselves, but I'll ask when I submit the above.
> >
> > Anything else I missed? (There are a lot of internal changes we'll want to
> > make as well, but I'm not trying to address those here.)
> >
> > --
> > Martin Cooper
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> Craig
>
>
> -
> 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: [PROPOSAL] Struts infrastructure changes

[Craig R. McClanahan]

Miscellaneous comments intermixed.

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> The following is a set of proposed changes to the Apache infrastructure to
> accommodate the Struts move to an Apache top level project. The idea is to
> come up with a single agreed-upon set of changes that we can submit to the
> infrastructure folks as a single request, rather than submitting each one
> piecemeal. Your feedback is appreciated.
> 
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)

I would like to maintain our current practice that these are *always* forwarded
to dev, instead of it being a separate mailing list.

> pmc@

As noted in other messages in this thread, we need an announcements list too.
>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
> 
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
> 
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
> 

This would be on the Apache infrastructure, right?

> Unix Group
>   New group: struts
>   Members: (Struts PMC members)

It would ultimately need to include all of the committers (not just PMC
members), in order for CVS commits to actually work.

> 
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts

This can certainly be a starting point.  We should consider whether it's worth
separating subprojects into their own repositories for ease of management
purposes (but I agree with your other comments that commit karma would still be
to all subprojects, no matter how this decision comes out).

>   Optional: Move to Subversion (IMO, not now, but we can discuss.)
> 

Given the amount of work this would involve, and assuming we can import our CVS
log history somehow, this would be OK with me; but seems like something we
could also defer to later after the dust settles.

> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)

I'm OK with either Jira or Bugzilla.  Note that other projects migrating to Jira
have been able to import their bug history, so we wouldn't lose that.

> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
> 
> Anything else I missed? (There are a lot of internal changes we'll want to
> make as well, but I'm not trying to address those here.)
> 
> --
> Martin Cooper
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


Craig


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

Re: [PROPOSAL] Struts infrastructure changes

[Ted Husted]

On Sat, 20 Mar 2004 15:59:15 -0800 (PST), Martin Cooper wrote:
> Do we want our own announcements@ list? In the past, we've sent
> release announcements to the Jakarta announcements list, so I'm
> wondering if we want one of our own now, for people who don't want
> to subscribe to the Struts -user or -dev lists.

Absolutely! :)



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

Re: [PROPOSAL] Struts infrastructure changes

[Martin Cooper]

On Sat, 20 Mar 2004, Martin Cooper wrote:

> The following is a set of proposed changes to the Apache infrastructure to
> accommodate the Struts move to an Apache top level project. The idea is to
> come up with a single agreed-upon set of changes that we can submit to the
> infrastructure folks as a single request, rather than submitting each one
> piecemeal. Your feedback is appreciated.
>
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)
> pmc@

Gee, I have a comment on my own proposal. ;-)

Do we want our own announcements@ list? In the past, we've sent release
announcements to the Jakarta announcements list, so I'm wondering if we
want one of our own now, for people who don't want to subscribe to the
Struts -user or -dev lists.

--
Martin Cooper


>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
>
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
>
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
>
> Unix Group
>   New group: struts
>   Members: (Struts PMC members)
>
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts
>   Optional: Move to Subversion (IMO, not now, but we can discuss.)
>
> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)
>
>
> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
>
> Anything else I missed? (There are a lot of internal changes we'll want to
> make as well, but I'm not trying to address those here.)
>
> --
> Martin Cooper
>
> -
> 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: [PROPOSAL] Struts infrastructure changes

[Ted Husted]

I'm good with any of this, or with any product changes others want, or do not want, to 
make. :)

On Sat, 20 Mar 2004 09:05:02 -0800 (PST), Martin Cooper wrote:
> The following is a set of proposed changes to the Apache
> infrastructure to accommodate the Struts move to an Apache top
> level project. The idea is to come up with a single agreed-upon set
> of changes that we can submit to the infrastructure folks as a
> single request, rather than submitting each one piecemeal. Your
> feedback is appreciated.



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

RE: [PROPOSAL] Struts infrastructure changes

[Steve Raeburn]

All sound good with the following comments:

1. CVS integrates very nicely with my IDE right now (Eclipse/WSAD). I
don't know how well Subversion would integrate and I'd not want to move
if I lost that integration. I'm sure that also applies to other IDEs.

2. Bugzilla/Jira make no difference to me. Jira looks nicer! David's
point about the history is very important. Can we migrate the data?

Steve

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 20, 2004 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Struts infrastructure changes
>
>
> The following is a set of proposed changes to the Apache
> infrastructure to
> accommodate the Struts move to an Apache top level project.
> The idea is to
> come up with a single agreed-upon set of changes that we can
> submit to the
> infrastructure folks as a single request, rather than
> submitting each one
> piecemeal. Your feedback is appreciated.
>
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)
> pmc@
>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
>
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
>
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
>
> Unix Group
>   New group: struts
>   Members: (Struts PMC members)
>
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts
>   Optional: Move to Subversion (IMO, not now, but we can discuss.)
>
> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)
>
>
> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm
> not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
>
> Anything else I missed? (There are a lot of internal changes
> we'll want to
> make as well, but I'm not trying to address those here.)
>
> --
> Martin Cooper
>
> -
> 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: [PROPOSAL] Struts infrastructure changes

[David Graham]

--- Martin Cooper <[EMAIL PROTECTED]> wrote:
> The following is a set of proposed changes to the Apache infrastructure
> to
> accommodate the Struts move to an Apache top level project. The idea is
> to
> come up with a single agreed-upon set of changes that we can submit to
> the
> infrastructure folks as a single request, rather than submitting each
> one
> piecemeal. Your feedback is appreciated.
> 
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)
> pmc@
>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
> 
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
> 
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
> 
> Unix Group
>   New group: struts
>   Members: (Struts PMC members)
> 
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts
>   Optional: Move to Subversion (IMO, not now, but we can discuss.)

The tool support for subversion is not nearly as good as it is for cvs
yet.  It's probably a good idea to switch in the long term but I don't see
any immediate benefits.

> 
> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)

I've expressed my opposition to this on commons-dev so I'll sum up my
points here:

1.  For me, part of the fun of developing OSS is using and supporting
other OSS projects.  Jira is not open source so it takes some of the fun
away.

2.  We've been fairly consistent with tracking corresponding bugzilla bug
numbers in the cvs commit messages.  This has proved extremely valuable
when researching and fixing bugs.  I would hate to lose that meta data.

3.  I have no problem with bugzilla so it's a, "if it isn't broken, don't
fix it" situation.

David

> 
> 
> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
> 
> Anything else I missed? (There are a lot of internal changes we'll want
> to
> make as well, but I'm not trying to address those here.)
> 
> --
> Martin Cooper
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

Re: [PROPOSAL] Struts infrastructure changes: Jira

[Martin Cooper]

On Sat, 20 Mar 2004, Mike Kienenberger wrote:

> Martin Cooper <[EMAIL PROTECTED]> wrote:
> >   Optional: Move to Jira (IMO, now's as good a time as any.)
>
> One thing I've noticed about Jira is that attachments cannot be deleted
> general developers, only members of the Jira admin group.
>
> Not sure if that's an issue.

I'm not aware of any way to delete an attachment with Buzilla, so I don't
think it would be an issue in moving to Jira. ;-)

--
Martin Cooper


>
> As a general user, I've found Jira far easier to use than Bugzilla.   I
> haven't been using it as a developer long enough to comment.
>
>
> -
> 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: [PROPOSAL] Struts infrastructure changes: Jira

[Mike Kienenberger]

Martin Cooper <[EMAIL PROTECTED]> wrote:
>   Optional: Move to Jira (IMO, now's as good a time as any.)

One thing I've noticed about Jira is that attachments cannot be deleted 
general developers, only members of the Jira admin group.

Not sure if that's an issue.

As a general user, I've found Jira far easier to use than Bugzilla.   I 
haven't been using it as a developer long enough to comment.


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

[PROPOSAL] Struts infrastructure changes

[Martin Cooper]

The following is a set of proposed changes to the Apache infrastructure to
accommodate the Struts move to an Apache top level project. The idea is to
come up with a single agreed-upon set of changes that we can submit to the
infrastructure folks as a single request, rather than submitting each one
piecemeal. Your feedback is appreciated.

Mailing Lists
  New mail domain: struts.apache.org
  The following lists are standard for an Apache TLP:
user@
dev@
cvs@ (usually forwarded to dev@)
pmc@
  Moderator: Ted Husted (same as today)
  Existing subscribers need to be migrated.
  Old list addresses should be forwarded for some period of time.

Web Site
  New virtual host: struts.apache.org
  Redirect from jakarta.apache.org/struts for some period of time.
  Writeable by group: struts (see below)

Wiki
  New wiki: wiki.apache.org/struts
  Migrate pages from: StrutsProjectPages on old wiki (nagoya)

Unix Group
  New group: struts
  Members: (Struts PMC members)

Source Control
  Old CVS repo: jakarta-struts
  New CVS repo: struts
  Optional: Move to Subversion (IMO, not now, but we can discuss.)

Bug Database
  Optional: Move to Jira (IMO, now's as good a time as any.)


One other thing is that we'll want to get external mail archivers to
switch to the new mailing lists once those are set up. I'm not clear on
whether the infrastructure folks arrange that or we need to do it
ourselves, but I'll ask when I submit the above.

Anything else I missed? (There are a lot of internal changes we'll want to
make as well, but I'm not trying to address those here.)

--
Martin Cooper

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

Jakarta Struts Proposal for Adoption as an Apache Top-Level Project

[Martin Cooper]

To the Board of the Apache Software Foundation:

We, the committers of the Jakarta sub-project jakarta-struts have held a
vote and agreed to apply to you for elevation of our sub-project to the
status of a top-level Apache project.

Struts is a mature, self-determining project that is able to govern
itself under the auspices of the ASF Board in accordance with ASF bylaws and 
guidelines.

We believe that normalizing our relationship with the ASF Board by
reporting directly rather than through the Jakarta PMC, and taking full
responsibility for our community and codebase will benefit all concerned.

Please find attached our proposed board resolution.

Submitted on behalf of the Struts community by:

  Craig R. McClanahan
  Ted Husted
  Rob Leland
  Cedric Dumoulin
  Martin Cooper
  Arron Bates
  James Holmes
  David M. Karr
  David Graham
  James Mitchell
  Steve Raeburn
  Don Brown
  Joe Germuska

Vote thread on the [EMAIL PROTECTED] mailing list:

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=666369
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation 
and 
consistent with the Foundation's purpose to establish a Project Management Committee 
charged with 
the creation and maintenance of open-source software related to the Apache Struts 
framework, for 
distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known 
as the 
"Apache Struts PMC", be and hereby is established pursuant to Bylaws of the 
Foundation; and be it 
further

RESOLVED, that the Apache Struts PMC be and hereby is responsible for the creation and 
maintenance 
of software for Apache Struts and for related software components, based on software 
licensed to 
the Foundation; and be it further

RESOLVED, that the office of "Vice President, Apache Struts" be and hereby is created, 
the person 
holding such office to serve at the direction of the Board of Directors as the chair 
of the Apache 
Struts PMC, and to have primary responsibility for management of the projects within 
the scope of 
responsibility of the Apache Struts PMC; and be it further

RESOLVED, that the persons listed immediately below be and hereby are appointed to 
serve as the 
initial members of the Apache Struts PMC:

  Craig R. McClanahan
  Ted Husted 
  Rob Leland 
  Cedric Dumoulin 
  Martin Cooper 
  Arron Bates 
  James Holmes 
  David M. Karr
  David Graham 
  James Mitchell
  Steve Raeburn 
  Don Brown 
  Joe Germuska

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig R. McClanahan be and hereby is 
appointed to the 
office of Vice President, Apache Struts, to serve in accordance with and subject to 
the direction 
of the Board of Directors and the Bylaws of the Foundation until death, resignation, 
retirement, 
removal or disqualification, or until a successor is appointed; and be it further

RESOLVED, that the initial Apache Struts PMC be and hereby is tasked with the creation 
of a set of 
bylaws intended to encourage open development and increased participation of the 
Apache Struts 
Project, in the Java language as well as others, and be it further

RESOLVED, that the initial Apache Struts PMC be and hereby is tasked with the 
migration and 
rationalization of the Jakarta PMC Struts subproject, and be it further

RESOLVED, that all responsibility pertaining to the Jakarta Struts sub-project and 
encumbered upon 
the Jakarta PMC are hereafter discharged.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: A proposal concerning the RequestUtils.populate()

[Martin Cooper]

On Wed, 10 Mar 2004 [EMAIL PROTECTED] wrote:

> Hi,
> First of all, sorry for my poor english, but please read carefully.
>
> I am a developer who use Struts for building RDBMS-based applications.
> I have to make so many tables that is linked by PK-FK relation.
> So There's so many Beans that are shaped like this
> (ParentBean and ChildBean is linked by PK-FK)
>
> 
> ParentBean.java
>
> public class ParentBean {
>   private int id;
>   private String name;
>   private ChildBean[] childBeans = new ChildBean[0];
>   // get/set methods
>   // ...
> }
> 
> ChildBean.java
>
> public class ChildBean {
>   private String childName;
>   // get/set methods
>   // ...
> }
> 
>
> ParentBean can have many, more than one ChildBeans,
> And I cannot guess how many ChildBeans would be created at run-time.
> So this page that is used for user-input cannot be worked properly.
>
> 
> ParentBeanInput.jsp
> ..
> 
> 
> 
> 
> ..
> 
>
> When request parameter is populated(when RequestUtils.populate() is
> called.),
> Array IndexOutofBoundary Exception is occured
> Because Property Entities like parentBean.childBeans[3].childName does not
> exist.
>
> So I use modified beanutils library that can extends length of arraies at
> run-time
> and make a component of array to populate this kind of request parameter
> that
> is mapped to array property of bean.
>
> I would like to Form-Bean processor that support array of variable length.

First of all, this type of question should be asked on struts-user, where
there are probably lots of people who have needed to do the same thing.

In any case, take a look at the LazyList class in Commons Collections. I
think this should do what you want.

http://jakarta.apache.org/commons/collections/apidocs/org/apache/commons/collections/list/LazyList.html

--
Martin Cooper


>
> Thank you for reading,Jang
>
> _
> 고.. 감.. 도.. 사.. 랑.. 만.. 들.. 기.. MSN 러브
> http://www.msn.co.kr/love/
>
>
> -
> 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]

A proposal concerning the RequestUtils.populate()

[iloveyouwo]

Hi,
First of all, sorry for my poor english, but please read carefully.
I am a developer who use Struts for building RDBMS-based applications.
I have to make so many tables that is linked by PK-FK relation.
So There's so many Beans that are shaped like this
(ParentBean and ChildBean is linked by PK-FK)

ParentBean.java
public class ParentBean {
 private int id;
 private String name;
 private ChildBean[] childBeans = new ChildBean[0];
 // get/set methods
 // ...
}

ChildBean.java
public class ChildBean {
 private String childName;
 // get/set methods
 // ...
}

ParentBean can have many, more than one ChildBeans, 
And I cannot guess how many ChildBeans would be created at run-time.
So this page that is used for user-input cannot be worked properly.


ParentBeanInput.jsp
..




..

When request parameter is populated(when RequestUtils.populate() is 
called.),
Array IndexOutofBoundary Exception is occured 
Because Property Entities like parentBean.childBeans[3].childName does not 
exist.

So I use modified beanutils library that can extends length of arraies at 
run-time 
and make a component of array to populate this kind of request parameter 
that 
is mapped to array property of bean.

I would like to Form-Bean processor that support array of variable length.

Thank you for reading,Jang

_
고.. 감.. 도.. 사.. 랑.. 만.. 들.. 기.. MSN 러브   
http://www.msn.co.kr/love/  

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

Re: [Proposal] ActionFactory refactoring

[BaTien Duong]

Vic Cekvenich wrote:



Don Brown wrote:
 It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
I think that is the key at the end of the day. I think it be more 
effective the few hours be spent on integrating IoC into struts-chain 
Yes, integration of Struts-chain and IoC seems to hold a key for 
managing a group of services that are passed via Struts-Chain as a 
controller. I am exploring this with PicoContainer (using 
DefaultLifeCyclePicoContainer which provides both life cycle management 
and Config object).

BaTien
DBGROUPS
but I do not need to remind anyone I am not a commiter, and even then 
each comiter can commit what they please, but I would rather see a 
design of IoC in CoR. If CoR already does digester, it can't be to far 
away from some level of alpha. I think it easier to work with a clean 
sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that 
could be implemented as Nano, Hivemind, etc.  and  I duno.

.V



-
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: [Proposal] ActionFactory refactoring

[Craig R. McClanahan]

Quoting Don Brown <[EMAIL PROTECTED]>:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
> 

The idea of factories for all Struts objects is an appealing one (I don't buy
the "too hard to teach" assertion either -- if you don't like teaching it, go
tell the GoF that they've got things all wrong :-).  The idea of a single
factory for all of them isn't quite so appealing -- every time we want to add a
new Struts API object, we need to go back and modify the standard factory
class, which is messy.

One interesting approach to this would be to add a responsibility to the
existing set of FooConfig objects, adding an appropriate create method to each.
 After all, if you want a specialized type of Action or ActionForm object,
you're probably going to need someplace to store extra configuration
information also, and the config object is exactly where you'd want to add
those properties.  Instead of createDynaActionForm() and
createDefaultActionForm(), then, we'd simply have createActionForm() on the
FormBeanConfig class, and it would do the right thing.  Using this approach,
configuring a specialized config bean class automatically configures a new
factory method as well, so you don't have to change two configuration settings
in struts-config.xml either.

An additional decision related to this whole condept, of course, is whether we
stick with the pure JavaBeans style object creation (zero-args constructor,
configure everything with property setters) or something like what Pico wants
(everything configured by arguments to the constructor).  I've dealt with
enough tools vendors in the last couple of years to be convinced that the
former (JavaBeans style) is *substantially* easier to build tools for, and
would therefore favor continuing that design pattern for any kinds of objects
(and object factories) that we create in the future.

Craig McClanahan


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

Re: [Proposal] ActionFactory refactoring

[Don Brown]

Heh, in my first proposal, I mentioned these bugs by name and URL too :)

Don

On Fri, 2 Jan 2004, Ted Husted wrote:

> On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> > Ok, sounds good.  I'll create a bugzilla entry and post the patches
> > there.
>
> Here's an old one that you could use:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23583
>
> -T.
>
>
>
> -
> 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: [Proposal] ActionFactory refactoring

[Ted Husted]

On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good.  I'll create a bugzilla entry and post the patches
> there.

Here's an old one that you could use:

http://issues.apache.org/bugzilla/show_bug.cgi?id=23583

-T.



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

Re: [Proposal] ActionFactory refactoring

[Ted Husted]

On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good.  I'll create a bugzilla entry and post the patches
> there.

Speaking of factories ...

http://issues.apache.org/bugzilla/show_bug.cgi?id=13638

-T.



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

Re: [Proposal] ActionFactory refactoring

[Don Brown]

On Fri, 2 Jan 2004, Ted Husted wrote:

> My one concern is the ActionServlet reference in the signature. I don't
> feel good about adding any more http dependencies to interfaces we may
> have to live with for some time. But it may be unavoidable, and when we
> do start encapsulating http, this whole she-bang might be encapsulated
> as well.

I agree, however, when we do write Servlets out of Struts, I think
everything will need to be rewritten, including this factory and the
objects it creates.  Since this is more of an internal refactoring than a
new feature, I think we don't have to be as concerned about
backward-compatibility, especially since writing Servlets out of Struts
will break everything anyways. (of course by "writing Servlets out of
Struts" I mean removing Servlet dependencies in Struts)

>
> If you can do it over the weekend, and post a patch that people could
> review first, and you felt confident in the code, I would say that it
> could still make the 1.2.0 cut. I feel strongly that we need to address
> the remaining problem reports regarding pagePattern et cetera. I'm
> actively working  on the module examples application now, but the
> application and the fixes aren't going to happen before Monday.
>
> Of course, an equally reasonable opinion would be to hold the patch for
> after the 1.2.0 roll, so that it can live in the nightly build for
> awhile. But it seems like a fairly straight-forward matter to me, and
> should either work or not.

Ok, sounds good.  I'll create a bugzilla entry and post the patches there.

Don

>
> -Ted.
>
> On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> > Yeah, I wasn't sure what to call them either.  I think it would be
> > nice to have one that will create the form from the config, no
> > matter what type it is, but still have others that create the
> > specific type.  This is mostly useful for testing as it makes it
> > easy to create dynaforms, a feature I've been hearing a lot.  Of
> > course, it could just be two methods, and if you just wanted a
> > dynaform, create a FormBeanConfig and set dynamic to true.
> >
> > As for when, it doesn't matter.  I could easily put it in over the
> > weekend, code and tests, but if we are trying to get 1.2 out the
> > door, it can wait.
> >
> > Don
> >
> >
> > On Fri, 2 Jan 2004, Martin Cooper wrote:
> >
> >
> >> Off the top of my head (meaning I haven't thought through all of
> >> the possible ramifications yet ;), I like this idea. I know that
> >> when I added factories to Commons FileUpload, it took the ability
> >> to customise things to a level that just isn't possible with
> >> straight 'new' coding. I can see how the same would be true for
> >> Actions as well.
> >>
> >> I'm not sure about the specific API you suggest. I assume by
> >> "default" you mean the non-dyna flavour? Something about the API
> >> doesn't "feel" right, but I'll try to give it some thought later
> >> and see if I can come up with anything better.
> >>
> >> BTW, I assume you're proposing this as a post-1.2.0 change?
> >>
> >>
> >> --
> >> Martin Cooper
>
>
>
> -
> 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: [Proposal] ActionFactory refactoring

[Ted Husted]

IMHO, if we were writing Struts today, then this definitely would have been a factory 
in the first place. So making it a factory now seems reasonable, so long as someone is 
willing to do the work :)

My one concern is the ActionServlet reference in the signature. I don't feel good 
about adding any more http dependencies to interfaces we may have to live with for 
some time. But it may be unavoidable, and when we do start encapsulating http, this 
whole she-bang might be encapsulated as well.

If you can do it over the weekend, and post a patch that people could review first, 
and you felt confident in the code, I would say that it could still make the 1.2.0 
cut. I feel strongly that we need to address the remaining problem reports regarding 
pagePattern et cetera. I'm actively working  on the module examples application now, 
but the application and the fixes aren't going to happen before Monday.

Of course, an equally reasonable opinion would be to hold the patch for after the 
1.2.0 roll, so that it can live in the nightly build for awhile. But it seems like a 
fairly straight-forward matter to me, and should either work or not.

-Ted.

On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> Yeah, I wasn't sure what to call them either.  I think it would be
> nice to have one that will create the form from the config, no
> matter what type it is, but still have others that create the
> specific type.  This is mostly useful for testing as it makes it
> easy to create dynaforms, a feature I've been hearing a lot.  Of
> course, it could just be two methods, and if you just wanted a
> dynaform, create a FormBeanConfig and set dynamic to true.
>
> As for when, it doesn't matter.  I could easily put it in over the
> weekend, code and tests, but if we are trying to get 1.2 out the
> door, it can wait.
>
> Don
>
>
> On Fri, 2 Jan 2004, Martin Cooper wrote:
>
>
>> Off the top of my head (meaning I haven't thought through all of
>> the possible ramifications yet ;), I like this idea. I know that
>> when I added factories to Commons FileUpload, it took the ability
>> to customise things to a level that just isn't possible with
>> straight 'new' coding. I can see how the same would be true for
>> Actions as well.
>>
>> I'm not sure about the specific API you suggest. I assume by
>> "default" you mean the non-dyna flavour? Something about the API
>> doesn't "feel" right, but I'll try to give it some thought later
>> and see if I can come up with anything better.
>>
>> BTW, I assume you're proposing this as a post-1.2.0 change?
>>
>>
>> --
>> Martin Cooper



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

Re: [Proposal] ActionFactory refactoring

[Joe Germuska]

At 10:44 AM -1000 1/2/04, Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
In general, I'm in favor.   I disagree with Vic's assertion, 
paraphrased "factories are too complicated; it's good enough to 
directly call the constructor" -- certainly that is appropriate for 
some classes, but by centralizing expertise for creating instances 
within a single class, you have a lot more flexibility to make an 
across-the-board change to what exactly which objects are created. 
(Something to which Martin alluded while I was composing this 
message.)

I won't elaborate too much at the risk of hijacking, but I wonder if 
we could also use this as an easy step towards an API whereby an 
Action could request an "output form" instance for pre-population. 
(That is, the form bean which would back an html:form block in the 
destination view, as opposed to the "input form" which  encapsulates 
the request parameters.)

This was one of the motivations for adding a view controller, which 
we talked about in the fall, and which  I looked at doing for a 
little bit.  A full-fledged view controller raised a lot of questions 
which made me inclined to wait for struts-chain, but a simple 
mechanism which boils down (for most users) to a method in Action or 
ActionMapping like "getOutputForm(String)" might be a nice 
compromise.  Personally, if I could easily get an output form in an 
Action, I could live a while longer without a separate class to 
encapsulate my view stuff.  The mechanism we use now is a horrible 
hack.

OK, I'm afraid I've already elaborated too much...  Back to the 
specifics, I'm a little uneasy about the method to explicitly get a 
DynaActionForm.  Otherwise, I think it's likely to be helpful, and 
likely to be a low-impact change.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
 "We want beef in dessert if we can get it there."
  -- Betty Hogan, Director of New Product Development, National 
Cattlemen's Beef Association

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

Re: [Proposal] ActionFactory refactoring

[Don Brown]

Yeah, I wasn't sure what to call them either.  I think it would be nice to
have one that will create the form from the config, no matter what type it
is, but still have others that create the specific type.  This is mostly
useful for testing as it makes it easy to create dynaforms, a feature I've
been hearing a lot.  Of course, it could just be two methods, and if you
just wanted a dynaform, create a FormBeanConfig and set dynamic to true.

As for when, it doesn't matter.  I could easily put it in over the
weekend, code and tests, but if we are trying to get 1.2 out the door, it
can wait.

Don

On Fri, 2 Jan 2004, Martin Cooper wrote:

> Off the top of my head (meaning I haven't thought through all of the
> possible ramifications yet ;), I like this idea. I know that when I added
> factories to Commons FileUpload, it took the ability to customise things
> to a level that just isn't possible with straight 'new' coding. I can see
> how the same would be true for Actions as well.
>
> I'm not sure about the specific API you suggest. I assume by "default" you
> mean the non-dyna flavour? Something about the API doesn't "feel" right,
> but I'll try to give it some thought later and see if I can come up with
> anything better.
>
> BTW, I assume you're proposing this as a post-1.2.0 change?
>
> --
> Martin Cooper
>
>
> On Fri, 2 Jan 2004, Don Brown wrote:
>
> > What if we extracted the creation of Actions and ActionForms (including
> > DynaActionForms) into an ActionFactory, overridable by the user?
> >
> > Here's the problem as I see it: there is no simple way for a user to plug
> > in their own code to manage the creation of actions and action
> > forms.  The actual creation is handled by static methods in
> > RequestUtils, obviously not overridable, leaving the only option to
> > extend RequestProcessor and duplicate a lot of logic.
> >
> > Why would you want to plug in your own ActionFactory?  My primary purpose
> > is to better integrate Inversion of Control (IoC), specifically Spring's
> > IoC, into Struts.  By letting Spring create Struts objects, Spring can
> > handle any dependencies and configuration they need.  Another use, as
> > stated in bug #23583
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> > factory that creates ActionForms using JavaAssist at runtime.  Finally,
> > this factory would be an easy way for the user to create their own
> > DynaActionForms, particularly useful for unit testing.
> >
> > Impact: This would have no impact on current Struts applications as it is
> > an internal refactoring and default behavior would remain the same.
> > Extensions that include custom RequestProcessors or interfere with object
> > creation might be affected.
> >
> > Configuration: I'd recommend another attribute in the 
> > element in struts-config, possibily named "actionFactoryClass", pointing
> > to the new ActionFactory implementation to use.  If none specified, a
> > default factory which mimics current behavior would be used.
> >
> > This is my proposed interface:
> >
> > public interface ActionFactory {
> >
> > public Action createAction(ActionServlet servlet);
> >
> > public DynaActionForm createDynaActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> >ActionConfig mapping);
> >
> > public ActionForm createDefaultActionForm(ActionServlet,
> >   FormBeanConfig config);
> >
> >
> > public ActionForm createActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> >ActionConfig mapping);
> >
> > }
> >
> > Note createActionForm() creates either a DynaActionForm or ActionForm
> > depending on the config.
> >
> > Comments?  Obviously, I'd perform the refactorings if this feature was
> > agreed upon.  Future targets for factories could include config objects:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
> >
> > Don
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

Don Brown wrote:
 It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
I think that is the key at the end of the day. I think it be more 
effective the few hours be spent on integrating IoC into 
struts-chain but I do not need to remind anyone I am not a commiter, 
and even then each comiter can commit what they please, but I would 
rather see a design of IoC in CoR. If CoR already does digester, it 
can't be to far away from some level of alpha. I think it easier to work 
with a clean sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that 
could be implemented as Nano, Hivemind, etc.  and  I duno.

.V



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

Re: [Proposal] ActionFactory refactoring

[Martin Cooper]

Off the top of my head (meaning I haven't thought through all of the
possible ramifications yet ;), I like this idea. I know that when I added
factories to Commons FileUpload, it took the ability to customise things
to a level that just isn't possible with straight 'new' coding. I can see
how the same would be true for Actions as well.

I'm not sure about the specific API you suggest. I assume by "default" you
mean the non-dyna flavour? Something about the API doesn't "feel" right,
but I'll try to give it some thought later and see if I can come up with
anything better.

BTW, I assume you're proposing this as a post-1.2.0 change?

--
Martin Cooper


On Fri, 2 Jan 2004, Don Brown wrote:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
>
> Here's the problem as I see it: there is no simple way for a user to plug
> in their own code to manage the creation of actions and action
> forms.  The actual creation is handled by static methods in
> RequestUtils, obviously not overridable, leaving the only option to
> extend RequestProcessor and duplicate a lot of logic.
>
> Why would you want to plug in your own ActionFactory?  My primary purpose
> is to better integrate Inversion of Control (IoC), specifically Spring's
> IoC, into Struts.  By letting Spring create Struts objects, Spring can
> handle any dependencies and configuration they need.  Another use, as
> stated in bug #23583
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> factory that creates ActionForms using JavaAssist at runtime.  Finally,
> this factory would be an easy way for the user to create their own
> DynaActionForms, particularly useful for unit testing.
>
> Impact: This would have no impact on current Struts applications as it is
> an internal refactoring and default behavior would remain the same.
> Extensions that include custom RequestProcessors or interfere with object
> creation might be affected.
>
> Configuration: I'd recommend another attribute in the 
> element in struts-config, possibily named "actionFactoryClass", pointing
> to the new ActionFactory implementation to use.  If none specified, a
> default factory which mimics current behavior would be used.
>
> This is my proposed interface:
>
> public interface ActionFactory {
>
>   public Action createAction(ActionServlet servlet);
>
>   public DynaActionForm createDynaActionForm(ActionServlet servlet,
>  FormBeanConfig config,
>  ActionConfig mapping);
>
>   public ActionForm createDefaultActionForm(ActionServlet,
> FormBeanConfig config);
>
>
> public ActionForm createActionForm(ActionServlet servlet,
>FormBeanConfig config,
>ActionConfig mapping);
>
> }
>
> Note createActionForm() creates either a DynaActionForm or ActionForm
> depending on the config.
>
> Comments?  Obviously, I'd perform the refactorings if this feature was
> agreed upon.  Future targets for factories could include config objects:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
>
> Don
>
>
> -
> 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: [Proposal] ActionFactory refactoring

[Don Brown]

On Fri, 2 Jan 2004, Vic Cekvenich wrote:

> So here are comments:
> - I like IoC idea!  I prefer Nano, Hivemind or something else Jakarta
> based. I have been using HiveMind on projects and it is very nice.

Exactly my point.  Abstracting object creating into a factory would allow
you to create a factory that uses HiveMind.  The IoC implementation
I mentioned wouldn't be a part of Struts, but rather for a Spring
plugin project I'm working on (http://struts.sf.net/struts-spring).

> - I do not like any kind of factory. It's harder to teach and maintain
> then just new(). Factory and pool had it's place in JDK 1.3, but a new()
> is not bad in 1.4. Besides we know the type of object is comming, so no
> reason for factory, it would just add complexity.

Perhaps we are speaking about different factories...  All a factory
pattern does is hide the object creation details, not necessarily object
pooling which I'm not suggesting at all.  This allows objects to be
created and therefore managed by custom code which could be an IoC impl or
a user's custom object factory.  Furthermore, it makes it easy to change
class implementation either through a different interface impl or
subclass.

Finally, very few Struts apps would use their own factory, as this is more
of an internal refactoring.  If anything, I think it would reduce
complexity as it cuts a section of code out of the huge RequestUtils.

> - I like what Struts chain does, it's simple and clever and it shows
> people how to create their own custom action that extend base action
> with the user base. That should be the starting point and improvments
> should be based on it, IMO. For example, calls from there to IoC. An IoC

Yes, with Struts chain, you would simply replace the command that creates
an action or action form, but still that duplicates logic.  A simple
factory only handles creation, not checking to see if one already exists
like in the case of form beans.

More importantly, Struts chain isn't used now.  RequestProcessor is.  This
refactoring is fairly simple, backwards-compatible, and imposes zero or
little changes the user would notice.  It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.

> DAO that populates a XMLFormBean Document. Digester could be called via
> IoC from CoR. I kind of think IoC is something users should do as calls
> from Strut's CoR. I do have a question if struts chain already reads
> digester or there is code someplace that does it or if I want to play
> with it I have to read mapping by myslef?

commons-chain contains ConfigParser, which uses the digester to build
chains from XML, however this is completely optional.  It is very easy to
build chains manually or from some other config source like a database.
The Struts-chain uses the ConfigParser to load its configuration.

Don

>
> .V
>
>
> ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other
> light weight service implementation.
>
> Don Brown wrote:
> > What if we extracted the creation of Actions and ActionForms (including
> > DynaActionForms) into an ActionFactory, overridable by the user?
> >
> > Here's the problem as I see it: there is no simple way for a user to plug
> > in their own code to manage the creation of actions and action
> > forms.  The actual creation is handled by static methods in
> > RequestUtils, obviously not overridable, leaving the only option to
> > extend RequestProcessor and duplicate a lot of logic.
> >
> > Why would you want to plug in your own ActionFactory?  My primary purpose
> > is to better integrate Inversion of Control (IoC), specifically Spring's
> > IoC, into Struts.  By letting Spring create Struts objects, Spring can
> > handle any dependencies and configuration they need.  Another use, as
> > stated in bug #23583
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> > factory that creates ActionForms using JavaAssist at runtime.  Finally,
> > this factory would be an easy way for the user to create their own
> > DynaActionForms, particularly useful for unit testing.
> >
> > Impact: This would have no impact on current Struts applications as it is
> > an internal refactoring and default behavior would remain the same.
> > Extensions that include custom RequestProcessors or interfere with object
> > creation might be affected.
> >
> > Configuration: I'd recommend another attribute in the 
> > element in struts-config, possibily named "actionFactoryClass", pointing
> > to the new ActionFactory implementation to use.  If none specified, a
> > default factory which mimics current behavior would be used.
> >
> > This is my proposed interface:
> >
> > public interface ActionFactory {
> >
> > public Action createAction(ActionServlet servlet);
> >
> > public DynaActionForm createDynaActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> > 

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

So here are comments:
- I like IoC idea!  I prefer Nano, Hivemind or something else Jakarta 
based. I have been using HiveMind on projects and it is very nice.
- I do not like any kind of factory. It's harder to teach and maintain 
then just new(). Factory and pool had it's place in JDK 1.3, but a new() 
is not bad in 1.4. Besides we know the type of object is comming, so no 
reason for factory, it would just add complexity.
- I like what Struts chain does, it's simple and clever and it shows 
people how to create their own custom action that extend base action 
with the user base. That should be the starting point and improvments 
should be based on it, IMO. For example, calls from there to IoC. An IoC 
DAO that populates a XMLFormBean Document. Digester could be called via 
IoC from CoR. I kind of think IoC is something users should do as calls 
from Strut's CoR. I do have a question if struts chain already reads 
digester or there is code someplace that does it or if I want to play 
with it I have to read mapping by myslef?

.V

ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other 
light weight service implementation.

Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms.  The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory?  My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts.  By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need.  Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime.  Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the 
element in struts-config, possibily named "actionFactoryClass", pointing
to the new ActionFactory implementation to use.  If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:

public interface ActionFactory {

	public Action createAction(ActionServlet servlet);

public DynaActionForm createDynaActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
  FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
}

Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments?  Obviously, I'd perform the refactorings if this feature was
agreed upon.  Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
Don


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

[Proposal] ActionFactory refactoring

[Don Brown]

What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?

Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms.  The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.

Why would you want to plug in your own ActionFactory?  My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts.  By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need.  Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime.  Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.

Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.

Configuration: I'd recommend another attribute in the 
element in struts-config, possibily named "actionFactoryClass", pointing
to the new ActionFactory implementation to use.  If none specified, a
default factory which mimics current behavior would be used.

This is my proposed interface:

public interface ActionFactory {

public Action createAction(ActionServlet servlet);

public DynaActionForm createDynaActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);

public ActionForm createDefaultActionForm(ActionServlet,
  FormBeanConfig config);


public ActionForm createActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);

}

Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.

Comments?  Obviously, I'd perform the refactorings if this feature was
agreed upon.  Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638

Don


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

Re: [PROPOSAL] archive all unmirrored struts releases

[robert burrell donkin]

move completed.

- robert

On Thursday, September 4, 2003, at 12:43 AM, David Graham wrote:

+1
Complying with the Apache standard is reason enough for me.
David

--- robert burrell donkin <[EMAIL PROTECTED]> wrote:
(i'm resending this from the account i'm subscribed under. there may be
a
near-duplicate moderated through later.)
(as many you will know) the apache software foundation policy concerning

releases is now that all releases should be available only through:

1. the main mirrored ASF distribution directories
2. the main ASF archives
the latest 1.1 struts release is available through the mirrors (well
done
guys!) but the older releases are still available through the older
unmirrored directories. the download statistics (supply by
infrastructure)
  show that unmirrored struts downloads are still proving too popular.
my proposal is that the older releases (under
jakarta.apache.org/builds/jakarta-struts/) be moved into the ASF
archives
(where they will remain available for download) and that all requests be
redirected to the main jakarta binary download page where the latest
release can be download or the link to the archives can be followed.
(unless someone else steps forward) i'll volunteer to carry out this
work.
  (unless someone corrects me) i'll assume that the decision will
proceed
by lazy consensus. (unless someone forces a vote before then) i'll carry
out this work sometime after 12 noon GMT tomorrow (thursday 4th
september)
- robert

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


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-
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: [PROPOSAL] archive all unmirrored struts releases

[David Graham]

+1
Complying with the Apache standard is reason enough for me.

David

--- robert burrell donkin <[EMAIL PROTECTED]> wrote:
> (i'm resending this from the account i'm subscribed under. there may be
> a 
> near-duplicate moderated through later.)
> 
> (as many you will know) the apache software foundation policy concerning
> 
> releases is now that all releases should be available only through:
> 
> 1. the main mirrored ASF distribution directories
> 2. the main ASF archives
> 
> the latest 1.1 struts release is available through the mirrors (well
> done 
> guys!) but the older releases are still available through the older 
> unmirrored directories. the download statistics (supply by
> infrastructure)
>   show that unmirrored struts downloads are still proving too popular.
> 
> my proposal is that the older releases (under 
> jakarta.apache.org/builds/jakarta-struts/) be moved into the ASF
> archives 
> (where they will remain available for download) and that all requests be
> 
> redirected to the main jakarta binary download page where the latest 
> release can be download or the link to the archives can be followed.
> 
> (unless someone else steps forward) i'll volunteer to carry out this
> work.
>   (unless someone corrects me) i'll assume that the decision will
> proceed 
> by lazy consensus. (unless someone forces a vote before then) i'll carry
> 
> out this work sometime after 12 noon GMT tomorrow (thursday 4th
> september)
> 
> - robert
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

[PROPOSAL] archive all unmirrored struts releases

[robert burrell donkin]

(i'm resending this from the account i'm subscribed under. there may be a 
near-duplicate moderated through later.)

(as many you will know) the apache software foundation policy concerning 
releases is now that all releases should be available only through:

1. the main mirrored ASF distribution directories
2. the main ASF archives
the latest 1.1 struts release is available through the mirrors (well done 
guys!) but the older releases are still available through the older 
unmirrored directories. the download statistics (supply by infrastructure)
 show that unmirrored struts downloads are still proving too popular.

my proposal is that the older releases (under 
jakarta.apache.org/builds/jakarta-struts/) be moved into the ASF archives 
(where they will remain available for download) and that all requests be 
redirected to the main jakarta binary download page where the latest 
release can be download or the link to the archives can be followed.

(unless someone else steps forward) i'll volunteer to carry out this work.
 (unless someone corrects me) i'll assume that the decision will proceed 
by lazy consensus. (unless someone forces a vote before then) i'll carry 
out this work sometime after 12 noon GMT tomorrow (thursday 4th september)

- robert

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

Pageflow proposal

[Paul_T_Smith]

Quick question, has anybody looked at the framework? Weve been focusing on
the question of whether or not workflow is appropriate for Struts. However,
there's a lot more here than just that. Ive used Struts in many production
projects, and found that it adds a great deal of productivity to the team.
Using the pageflow extension to build the example application was even more
productive. So this is more like a Struts 2.0 proposal than anything else. 

Ill give you an example. In the pageflow extension you can declare a
page-instance with mappings. 








What this actually does is copy all the values from the user object stored
in the session to the form everytime you go to the registration page and, if
you declare a mapTo, it copies any changed values back to the object
whenever you leave the page. This saves the developer from doing any form
handling coding at all. That alone saves tons of time. There are many other
productivity enhancements as well.

I guess what Im asking is could some of you guys download the example and
play with it? If you cant stand it then that's fine, but you might also find
that it is pretty easy to use and provides some real enhancement to Struts
1.1. The roadmap says we are going to potentially re-architect the platform
with the 2.0 release anyway, so pageflow is just a proposal for that.

Thanks,
Paul


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

Re: [PROPOSAL] Modular Struts Examples

[James Mitchell]

That's great!!  I'm looking forward to capitalizing on your success.oh
waitI'm doing that already, thanks again!!!

--
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
678-910-8017
AIM:jmitchtx


- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 8:03 AM
Subject: Re: [PROPOSAL] Modular Struts Examples


> Just wanted to mention that I did some work on the "Struts University"
> application last week, and it seemed to work well in a classroom
> environment. I'll have another post regarding this soon.
>
>
> Ted Husted wrote:
> > I've started work on a "Struts University" application, based on Steve's
> > Struts Examples application.
> >
> > Struts University uses the same "Tomcat Example" format. The idea is
> > that the examples will be ordered and grouped to help teach Struts
> > through a series of working examples.
>
> 
>
>
>
>
> -
> 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: [PROPOSAL] Modular Struts Examples

[Ted Husted]

Just wanted to mention that I did some work on the "Struts University" 
application last week, and it seemed to work well in a classroom 
environment. I'll have another post regarding this soon.

Ted Husted wrote:
I've started work on a "Struts University" application, based on Steve's 
Struts Examples application.

Struts University uses the same "Tomcat Example" format. The idea is 
that the examples will be ordered and grouped to help teach Struts 
through a series of working examples.




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

Re: Fw: [PROPOSAL] Modular Struts Examples

[Ted Husted]

James Mitchell wrote:
How will this affect update of the Struts site?
I typically copy things over, so it would just affect slightly where I 
copy them from.

The other approach is to copy over the WAR and then expand it. To keep 
that functionality, I'm sure we could come up with a build target that 
would ZIP up the website and we could use that instead of a WAR.

For extra credit, it would be interesting to see a build file that could 
build the same set as one application or a portal of modules. =:0)

-T.



--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


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

Re: Fw: [PROPOSAL] Modular Struts Examples

[James Mitchell]

On Friday 11 July 2003 12:45, Ted Husted wrote:



> The proposed end-game would be to first consolidate our various examples
> (upload, validator, tiles, Steve's examples, and more) into the Struts
> University application. Then, we could considering making the
> MailReader, Taglib-Exercises, University, and the Website Documentation,

How will this affect update of the Struts site?

> -Ted.
>



-- 
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
678-910-8017
AIM:jmitchtx



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

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

I've started work on a "Struts University" application, based on Steve's 
Struts Examples application.

Struts University uses the same "Tomcat Example" format. The idea is 
that the examples will be ordered and grouped to help teach Struts 
through a series of working examples.

I've made a prototype available for review. The first example is using 
an action as welcome page (via redirection). This does double duty as 
the welcome page to the university application.

The prototype with the first example is up on SourceForge.

http://sourceforge.net/project/showfiles.php?group_id=49385

It's way down under the "slides" release category. I put it under the 
"slides", since I may do a set of companion presentations to go with 
these, so it becomes more like an actual class.

[See org.apache.struts.university.UniversityTestCase.APP_ROOT before 
trying to run the test target.]

My intention is to use simple-but-effective best practices throughout 
the application and examples and to also use all the standard 
bells-and-whistles like Tiles and the Validator.

I'd also like to provide Struts TestCases for each example. This package 
has been available on SourceForge for some time and is growing in 
popularity. There are still some rough edges, but nothing that can't be 
smoothed out. (One of which is that you usually need to set the local 
system path to run the Mock tests.) I'm sure the examples will generate 
some useful patches -- I've one pending already.

The proposed end-game would be to first consolidate our various examples 
(upload, validator, tiles, Steve's examples, and more) into the Struts 
University application. Then, we could considering making the 
MailReader, Taglib-Exercises, University, and the Website Documentation, 
all standalone modules of a single "Struts Library" application. (Blank 
would remain standalone.)

It's my feeling that a single modular application will not only save 
bandwidth on the binary downloads (since all the same JARs are 
replicated in each), it will make everything more accessible, since the 
Struts Library application can act as a portal to the modules.

Of course, I'll setup a prototype that everyone can play-test before 
suggesting any changes to the HEAD.

-Ted.

--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .


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

Re: [PROPOSAL] Wildcard-matched actions

[Don Brown]

On Sunday 06 July 2003 02:12 am, Ted Husted wrote:

> Don,
>
> Would your patch interact with
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=15921

I don't see why not.  My patch inserts a few lines in processMapping which 
calls a helper class that runs through all the action configs, matches one, 
clones it and replaces wildcard values with the literal values, and returns 
the new clone.  

I'll put the code in patch form and post it on bugzilla.

Don

>
>
> -Ted.
>
> Graham Leggett wrote:
> > Don Brown wrote:
> >> Perhaps now that 1.1 is final, this would be a good time to bring this
> >> up.
> >> I've written a small extension to Struts that allows action mappings to
> >> use wildcards in matching URIs.
> >
> > I submitted a patch to bugzilla a while back that did prefix matching in
> > matching URIs. A config called "foo" could be called, regardless of
> > whether it was accessed as "/bar/foo", or "/fred/foo". Very useful for
> > standard functionality that is reused in a site, such as a login form.
> > We've been using it for a while, and it works great.
> >
> > Wildcard matching would also be really useful.
> >
> > Regards,
> > Graham


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

Re: [PROPOSAL] Wildcard-matched actions

[Ted Husted]

Graham,

I don't see that ticket on the current patch list:

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Bug+Number

[Select all status but RESOLVED and CLOSED, select Struts, enter 
"PatchAvailable" in keyword.]

do you have the ticket number?

Don,

Would your patch interact with

http://issues.apache.org/bugzilla/show_bug.cgi?id=15921

-Ted.

Graham Leggett wrote:
Don Brown wrote:

Perhaps now that 1.1 is final, this would be a good time to bring this 
up.
I've written a small extension to Struts that allows action mappings to
use wildcards in matching URIs.


I submitted a patch to bugzilla a while back that did prefix matching in 
matching URIs. A config called "foo" could be called, regardless of 
whether it was accessed as "/bar/foo", or "/fred/foo". Very useful for 
standard functionality that is reused in a site, such as a login form. 
We've been using it for a while, and it works great.

Wildcard matching would also be really useful.

Regards,
Graham


--
Ted Husted,
Struts in Action 


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

Re: [PROPOSAL] Wildcard-matched actions

[Graham Leggett]

Don Brown wrote:

Perhaps now that 1.1 is final, this would be a good time to bring this up.
I've written a small extension to Struts that allows action mappings to
use wildcards in matching URIs.
I submitted a patch to bugzilla a while back that did prefix matching in 
matching URIs. A config called "foo" could be called, regardless of 
whether it was accessed as "/bar/foo", or "/fred/foo". Very useful for 
standard functionality that is reused in a site, such as a login form. 
We've been using it for a while, and it works great.

Wildcard matching would also be really useful.

Regards,
Graham
--
-
[EMAIL PROTECTED]   "There's a moon
over Bourbon Street
tonight..."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] Wildcard-matched actions

[Don Brown]

And I forgot to mention, when using the wildcard matcher, only action mappings 
that actually contain wildcards will be tested.

Don

On Saturday 05 July 2003 01:18 pm, Don Brown wrote:
> Actually, the way I wrote the code, wildcards are only matched if an exact
> match cannot be found but before the "unknown" action mapping is executed.
> So, there is no performance penalty for existing applications that use
> specific matchings.  The order:
>
>  - Try to find an action mapping that matches the path exactly
>  - Try to find an action mapping using wildcard matching
>  - Try to locate the mapping for "unknown" paths
>
> Don
>
> On Saturday 05 July 2003 08:31 am, Craig R. McClanahan wrote:
> > On Sat, 5 Jul 2003, Niall Pemberton wrote:
> > > Date: Sat, 5 Jul 2003 01:32:45 +0100
> > > From: Niall Pemberton <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Re: [PROPOSAL] Wildcard-matched actions
> > >
> > > I like it.
> > >
> > > Perhaps you should create an enhancement request in bugzilla and attach
> > > a patch with your code.
> >
> > The idea makes some sense, and gets us more towards a general purpose
> > "site map" approach to mapping arbitrary URLs to arbitrary actions.  My
> > one concern will be performance related, since this kind of matching will
> > be slower than the existing approach.  This could perhaps be alleviated
> > by having a per-module-setting (or some smart initialization code) that
> > only used the wildcard matching code if the module actually has some
> > actions that need it, and uses the optimized version otherwise.
> >
> > > Niall
> >
> > Craig
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: [PROPOSAL] Wildcard-matched actions

[Don Brown]

Actually, the way I wrote the code, wildcards are only matched if an exact 
match cannot be found but before the "unknown" action mapping is executed.  
So, there is no performance penalty for existing applications that use 
specific matchings.  The order:

 - Try to find an action mapping that matches the path exactly
 - Try to find an action mapping using wildcard matching
 - Try to locate the mapping for "unknown" paths

Don



On Saturday 05 July 2003 08:31 am, Craig R. McClanahan wrote:
> On Sat, 5 Jul 2003, Niall Pemberton wrote:
> > Date: Sat, 5 Jul 2003 01:32:45 +0100
> > From: Niall Pemberton <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Re: [PROPOSAL] Wildcard-matched actions
> >
> > I like it.
> >
> > Perhaps you should create an enhancement request in bugzilla and attach a
> > patch with your code.
>
> The idea makes some sense, and gets us more towards a general purpose
> "site map" approach to mapping arbitrary URLs to arbitrary actions.  My
> one concern will be performance related, since this kind of matching will
> be slower than the existing approach.  This could perhaps be alleviated by
> having a per-module-setting (or some smart initialization code) that only
> used the wildcard matching code if the module actually has some actions
> that need it, and uses the optimized version otherwise.
>
> > Niall
>
> Craig
>
> -
> 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: [PROPOSAL] Wildcard-matched actions

[Craig R. McClanahan]

On Sat, 5 Jul 2003, Niall Pemberton wrote:

> Date: Sat, 5 Jul 2003 01:32:45 +0100
> From: Niall Pemberton <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: [PROPOSAL] Wildcard-matched actions
>
> I like it.
>
> Perhaps you should create an enhancement request in bugzilla and attach a
> patch with your code.

The idea makes some sense, and gets us more towards a general purpose
"site map" approach to mapping arbitrary URLs to arbitrary actions.  My
one concern will be performance related, since this kind of matching will
be slower than the existing approach.  This could perhaps be alleviated by
having a per-module-setting (or some smart initialization code) that only
used the wildcard matching code if the module actually has some actions
that need it, and uses the optimized version otherwise.

>
> Niall

Craig

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

Re: [PROPOSAL] Wildcard-matched actions

[Niall Pemberton]

I like it.

Perhaps you should create an enhancement request in bugzilla and attach a
patch with your code.

Niall


- Original Message - 
From: "Don Brown" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 30, 2003 11:18 PM
Subject: [PROPOSAL] Wildcard-matched actions


> Perhaps now that 1.1 is final, this would be a good time to bring this up.
> I've written a small extension to Struts that allows action mappings to
> use wildcards in matching URIs.  The matched values can then be
> substituted anywhere in the action mapping - similar to how Cocoon
> operates (in fact the wildcard code was copied from Cocoon).  The code
> only affects the processActionMapping method of the RequestProcessor.
>
> Why you ask?
>
>  - Much smaller config files
>  - Use of wildcards encourages more consistency of naming action forms,
> actions, and jsp files.
>  - Allows for noun-based URLs in addition to current verb-based URLS,
> particularly useful in REST-style web services
>  - No performance loss: wildcard matching only occurs when a direct
> mapping for the URI cannot be found
>
> For example:
>
> 
> type="org.apache.struts.webapp.example.Edit{1}Action"
>   attribute="{1}Form"
>   scope="request"
>validate="false">
>   
>   
> 
>
> By including this feature directly in Struts, wildcards would be available
> to all Struts applications as opposed to now where wildcard support
> requires a RequestProcessor extension.
>
> For more information:
>
> http://www.twdata.org/struts-wildcard/
>
> Don
>
>
> -
> 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: [PROPOSAL] Modular Struts Examples

[Phil Steitz]

Craig R. McClanahan wrote:


Right now, it's in particular a "front controller" framework, in design
pattern terms.  That's one of the areas I would personally like to see us
do some innovation.
Can you expand a little on what you mean here, Craig?

Phil

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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

For more general purpose use (such as in the business tier), doesn't
RowSet already do everything you need?  I've heard it argued that this can
be the standarized DAO interface you are talking about.
What if the Data Feed is MQ, or Soap? RowSet has all this other 
mechanisam that gets in the way. Also disconected rowset for Oracle 
works a bit dieferent than RowSet for pgSQL, etc. So porting from SQL to 
   SQL will depened on RowSet driver, ouch. DAO interface can be 
tabular like disconected rowset, but based on Collections.


JSF (as you know :-( ) I personaly consider propriatory. Once I see the
real production license in 1.0 release by Sun or others, I will
re-consider.


It's under exactly the same terms as the Servlet API, or JSP -- for
example, you cannot ship a Servlet 2.4 container today, because Servlet
2.4 is not yet final.  Yet, we all know that it *will* become final, so we
can plan ahead on how to leerage it when it's released.
TC5.02 has been release as has Resin 3.1.
bP today downloads with TC5 and Resin 3.0 integrated, both have a great 
license.


2nd, JSF makes some architectral mistakes that remind me of EJB. I could
write another long letter to the JCP, but too late, the comitte is
locked.  Short story is that Java Everywhere plan will *not* work for
GUI, UI must be browswer, not Java, and not by a Java Developer but by
graphic artist. (As proof, I could show you some sites I designed the
GUI for :-) ). Also, I sincerley, but maybe naivley, think that JSF push
by Sun will push Java Developers into .Net. Nothing in version 1.0 will
fly, look how Struts was allowd to grow in 0.6 in a shade. If my clients
balk at JSF, I have no choice. Diverting Apache Struts users to Sun JSF
is not a great idea.


Your argument is pretty ironic, given that even Microsoft provides
mechanisms to programmatically create and modify UI components (using VB
or C# or whatever), so obviously there are at least a few people in the
world who differ on "UI must be browser".  :-)

Rich UI should not be Java, even if miniroity think it. We can agree to 
disagree, but I think that is where JSF misses. Masses are fickle.




I think JSTL is a great direction, and JSP 2.0 is great (KISS). If a
data grid was based on JSTL more, would that suffice?


No.

JSP and JSTL exist only at rendering time (what JavaServer Faces
calls the "render response" phase of the request processing lifecycle).
That does not provide any opportunity to perform event processing and/or
server side validation, which any robust UI framework needs to support.
Further, page authors need to be able to think of a DataGrid as a single
"thing" they can manipulate, and concentrate on look-and-feel issues,
without worrying about things like the iteration and result set scrolling
that would have to be explicitly dealt with if you're doing it the JSTL
way.  Sure, you can create something like the Pager tag library that makes
this kind of thing possible today, but still exposes lots of the plumbing.



If in JSF the Java Developer in a JSP creates a bean, populates it and 
then uses DataGrid for UI  then they are worying about pluming more 
so than Model 2; but I do not want to be confused for someone who wants 
JSF to get better :-). HTML was not meant for the complex forms we do 
now, and it can't be fixed at the server, but up close.

This is what "we" Model 2 people used to do in Struts in the days of 
Java, before JSF came and paved the way for .NET: :-)
In action we create a bean a populate it and put it in request, then the 
display tag  in JSP access the collection and displays it using CSS 
styles. Any pageing is done at the Data Layer (DAO) where page down, 
page up data can be cached (data cached at data layer, not view layer).

If JSF is not at some DAO level, but at a RowSet level... one would have 
to cache data in the view or controller for pageinator.



JSF needs to be more open, scaleable, rich UI (right now not even
Javascript support).


I thought you said that Struts should *not* have a UI at all, and
concentrate on the controller tier?  Make up your mind :-).

I think Struts should stay View agnostic.
(Why not add EJB to Struts? same argument, it is contraversial, ex:
Bitter EJB) JSF could become an anti-patern.


No matter how much people like you like to diss EJB, it's been the basis
for more than a few successful application deployments in large scale,
high availabililty, production environments.  Whether you like it or not
doesn't matter much to me ... there's enough people that do to have built
an entire app server software industry around it.
It wouldn't bother me at all for JavaServer Faces to have the same kind of
effect, and it still won't matter much to me whether *you* like it or not
:-).  It's clear already that more than a few vendors are taking it
seriously enough to build product around.  It's clear already that lots of
users like the direction.  There's already a SourceForge project (MyFaces)
pretty far along at an o

Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[Nathan Bubna]

David Graham said:
... 
> Struts is view agnostic.  You can use any view technology you like.

agreed!  but it could be made friendlier to non-JSP view technologies.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16814

:-)  

(btw, congrats again on getting 1.1 out.  ya'll are great!)

Nathan Bubna
[EMAIL PROTECTED]


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

Re: [PROPOSAL] Modular Struts Examples

[Craig R. McClanahan]

On Thu, 3 Jul 2003, Vic Cekvenich wrote:

> Date: Thu, 03 Jul 2003 17:22:21 -0400
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
> Craig R. McClanahan wrote:
>
> >
> > On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> >
> >
> >>My point was a shade on the other side. Yes Struts can show integration
> >>to do 100's of things out there.
> >>But at its core, Struts is a controller framework.
> >
> >
> > Right now, it's in particular a "front controller" framework, in design
> > pattern terms.  That's one of the areas I would personally like to see us
> > do some innovation.
> >
> >
> >>Action Event Object execute signature- instead of the execute signature
> >>with 4 arguments, have a single object containing the 4 objects.
> >>This reduces people new to Struts creating properties in action, and
> >>allows same execute signature for TilesAction, etc. The code looks a lot
> >>cleaner. bP does this (as I think does Expresso)
> >
> >
> > No matter how technically worthy such an idea might be, this isn't going
> > to happen in a 1.x train, due to backwards compatibility expectations.
> > This is part of the responsibility that goes with being a widely deployed
> > and utilized framework -- we have to protect the investment of people who
> > have built on top of the existing architecture.  If we only had a few
> > users, we would be more free to do stuff like this.  But according to the
> > Apache web site stats (unofficial, but seem like they're pretty accurate)
> > we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.
> >
> > If we're willing to look at changing the fundamental APIs (and I think we
> > are in a 2.x train), there is a lot more we can do to make Struts better
> > than just this kind of change -- I'd rather look at the overall
> > architecture more holistically, instead of incrementally, when making
> > decisions like this.  For example, I will shortly be done with a pretty
> > radical proposal for the "decomposing the request processor" conundrum
> > that has been discussed a lot lately on STRUTS-DEV.
> >
> > Incremental change is great for improving implementations.  It's not so
> > great for modifying fundamental APIs.  To do the latter well, you need to
> > be prepared to think outside the box, and even re-invent yourself on
> > occasion.
>
> It is a simple change, like perform and execute signatures.

Simple for developers to implement if we chose to.  Disastrous for Struts
users, because it would break 100% of the Action and ActionForm
implementations in the world, unless you provide backwards compatible
hooks that continue to support the existing APIs -- and that just makes
life more complicated, not less.

> >
> >
> >>protected List _list in FormBean. As Husted's book points out (and bP
> >>implements), it is nice to store data in a protected _list. (I am sure I
> >>took it out of context) People mostly work with a tabular recordset,
> >>rows of columns, eg: List of Maps. There are many ways of getting DAO
> >>data to FormBean, but a good idea is to store the rows as a _list.
> >>People that extend the ValidatorFormBean can then write their own
> >>getValue, setValue and beann getters/setter, it nuges people in right
> >>direction to store data agnosticly. (Ex: MQ gets results, remaped via
> >>magic to formBean, and stores in a list).  Things like indexed
> >>properties become easier then ... and best view in JSP world is display
> >>tag, works with collection. Note that I would not implement the methods,
> >>just leave it like that, protected _list, a place to plug into.
> >>
> >
> >
> > As you well know :-), you and I don't totally share a vision of what a
> > form bean is for, and what it's not for :-).  However, the recent progress
> > on JavaServer Faces clearly indicates that Struts's form bean approach,
> > and total lack of any real UI component model, needs to be addressed.
>
> Yes. But we do agree that FormBeans have nothing to do with how the data
> comes in. (And I have adjusted my designs a lot since)
>
>
> >
> > I'd actually rather address it by focusing on the controller (as you
> > suggest), and let all the view-layer considerations be separated as well.
> > I think that form beans, by themselves, are too limiting as a long term
> 

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Got it "we".

Vic Cekvenich wrote:



Ted Husted wrote:

Craig R. McClanahan wrote:

sbip.

While ee should keep the new Struts-Examples application tied to 
what's in our core distribution, I think there's room for a 
Struts-Extensions application that uses things like DisplayTag, Struts 
Menu, xDoclet, and so forth. But, that's something I would envision 
living on the Struts SourceForge site (assuming somone wants to build 
it).

Typo on ee?


-Ted.




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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Ted Husted wrote:

Craig R. McClanahan wrote:

sbip.
While ee should keep the new Struts-Examples application tied to what's 
in our core distribution, I think there's room for a Struts-Extensions 
application that uses things like DisplayTag, Struts Menu, xDoclet, and 
so forth. But, that's something I would envision living on the Struts 
SourceForge site (assuming somone wants to build it).

Typo on ee?


-Ted.




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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:

On Thu, 3 Jul 2003, Vic Cekvenich wrote:


My point was a shade on the other side. Yes Struts can show integration
to do 100's of things out there.
But at its core, Struts is a controller framework.


Right now, it's in particular a "front controller" framework, in design
pattern terms.  That's one of the areas I would personally like to see us
do some innovation.

Action Event Object execute signature- instead of the execute signature
with 4 arguments, have a single object containing the 4 objects.
This reduces people new to Struts creating properties in action, and
allows same execute signature for TilesAction, etc. The code looks a lot
cleaner. bP does this (as I think does Expresso)


No matter how technically worthy such an idea might be, this isn't going
to happen in a 1.x train, due to backwards compatibility expectations.
This is part of the responsibility that goes with being a widely deployed
and utilized framework -- we have to protect the investment of people who
have built on top of the existing architecture.  If we only had a few
users, we would be more free to do stuff like this.  But according to the
Apache web site stats (unofficial, but seem like they're pretty accurate)
we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.
If we're willing to look at changing the fundamental APIs (and I think we
are in a 2.x train), there is a lot more we can do to make Struts better
than just this kind of change -- I'd rather look at the overall
architecture more holistically, instead of incrementally, when making
decisions like this.  For example, I will shortly be done with a pretty
radical proposal for the "decomposing the request processor" conundrum
that has been discussed a lot lately on STRUTS-DEV.
Incremental change is great for improving implementations.  It's not so
great for modifying fundamental APIs.  To do the latter well, you need to
be prepared to think outside the box, and even re-invent yourself on
occasion.
It is a simple change, like perform and execute signatures.


protected List _list in FormBean. As Husted's book points out (and bP
implements), it is nice to store data in a protected _list. (I am sure I
took it out of context) People mostly work with a tabular recordset,
rows of columns, eg: List of Maps. There are many ways of getting DAO
data to FormBean, but a good idea is to store the rows as a _list.
People that extend the ValidatorFormBean can then write their own
getValue, setValue and beann getters/setter, it nuges people in right
direction to store data agnosticly. (Ex: MQ gets results, remaped via
magic to formBean, and stores in a list).  Things like indexed
properties become easier then ... and best view in JSP world is display
tag, works with collection. Note that I would not implement the methods,
just leave it like that, protected _list, a place to plug into.


As you well know :-), you and I don't totally share a vision of what a
form bean is for, and what it's not for :-).  However, the recent progress
on JavaServer Faces clearly indicates that Struts's form bean approach,
and total lack of any real UI component model, needs to be addressed.
Yes. But we do agree that FormBeans have nothing to do with how the data 
comes in. (And I have adjusted my designs a lot since)


I'd actually rather address it by focusing on the controller (as you
suggest), and let all the view-layer considerations be separated as well.
I think that form beans, by themselves, are too limiting as a long term
abstraction for server-side view state.
Just as an example of this, look at where JavaServer Faces is today, with
respect to the concepts behind form beans and actions:
* You can use one form bean per page, or more than one -- your choice.
This I think is a mistake on JSF part. A formBean should map a form 
(JSP). If JSP is nested, so formBean should nest beans.
The major benefit is that one can unit test the formBean outside of the 
JSP for CRUD, etc. Modular! Else you are integrating in the JSP and that 
is just no good, now we need Container debugging, since less of a unit test.

* You can combine the form bean data with your "action" class
  (the way that WebWorks does it) or keep them separate -- your choice.
* You can ask for ANY bean to be automatically instantiated on demand,
  not just form beans.
Hey, now that is a security problem potentialy. It should map to the 
form(JSP). And then what about bean.populate() and if there  is no data 
found or ...
Model 1!

The technology train is passing us by.  We're not going to be able to
catch up with simple incremental changes.

Maveric instead of Ant for build. My argument is this. CVS out
CommonsSQL and use Maverick to build it. Sexy!
It auto downloads all the other jars it needs. People can target any
thing very easily. The build process becomes simple and fun.
(I do not have this code, 

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

Craig R. McClanahan wrote:
Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view

Other Struts developers, of course, can speak for themselves.
There are a ton of very cool extension for Struts, DisplayTag, SSL-Ext, 
Struts-Menu, to name a very few. Many more than we could ever try to 
support here.

But, the beauty of the open source world is that we don't ~need~ to 
support everything here. People can setup projects at SourceForge and so 
forth and do everything there that they could do here.

I'd like to see more HOW-TOs in our documentation in regard to the many 
extensions. But it's up to the people using these extensions to 
contribute them. I'm also hoping to get caught up on the resources page 
soon, which is also sadly behind the times.

While ee should keep the new Struts-Examples application tied to what's 
in our core distribution, I think there's room for a Struts-Extensions 
application that uses things like DisplayTag, Struts Menu, xDoclet, and 
so forth. But, that's something I would envision living on the Struts 
SourceForge site (assuming somone wants to build it).

-Ted.

--
Ted Husted,
Struts in Action 


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

Re: [PROPOSAL] Modular Struts Examples

[David Graham]

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> 
> On Thu, 3 Jul 2003, Vic Cekvenich wrote:
> 
> > Date: Thu, 03 Jul 2003 16:32:02 -0400
> > From: Vic Cekvenich <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PROPOSAL] Modular Struts Examples
> >
> >
> >
> > Craig R. McClanahan wrote:
> > >
> >
> > >>>
> > >>>David
> >
> > >>>>
> > >>
> > >>Would David's argument be that JSF integration (requires 2.3) be
> > >>postponed till Struts 2.0?
> > >
> > >
> > > For integration into the core of Struts, yes it does.  But we can
> provide
> > > an optional add-on integration for Faces, just like struts-el does
> for EL
> > > evaluation, as soon as Faces 1.0 goes final.  Use it if you want,
> but it's
> > > not required by the core of Struts.
> > >
> > >
> > >>OK, just do one or the other, so everyone is playing on the level
> field.
> > >
> >
> > So all I am saying, call v 1.2 2.0 if you want, but target 2.3.
> >
> 
> Target what?  The core of Struts?  As you'll see from my other message,
> I'd rather see us skip 2.3 for Struts 2.0; the incremental benefits of
> Servlet 2.4 and JSP 2.0 are well worth it.

I agree with skipping 2.3.  I don't much care about the Servlet 2.4 stuff
but JSP 2.0 is a big deal. 

David

> 
> >
> > .V
> 
> Craig
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: [PROPOSAL] Modular Struts Examples

[Craig R. McClanahan]

On Thu, 3 Jul 2003, Vic Cekvenich wrote:

> Date: Thu, 03 Jul 2003 16:32:02 -0400
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
>
> Craig R. McClanahan wrote:
> >
>
> >>>
> >>>David
>
> >>>>
> >>
> >>Would David's argument be that JSF integration (requires 2.3) be
> >>postponed till Struts 2.0?
> >
> >
> > For integration into the core of Struts, yes it does.  But we can provide
> > an optional add-on integration for Faces, just like struts-el does for EL
> > evaluation, as soon as Faces 1.0 goes final.  Use it if you want, but it's
> > not required by the core of Struts.
> >
> >
> >>OK, just do one or the other, so everyone is playing on the level field.
> >
>
> So all I am saying, call v 1.2 2.0 if you want, but target 2.3.
>

Target what?  The core of Struts?  As you'll see from my other message,
I'd rather see us skip 2.3 for Struts 2.0; the incremental benefits of
Servlet 2.4 and JSP 2.0 are well worth it.

>
> .V

Craig


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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:


David


Would David's argument be that JSF integration (requires 2.3) be
postponed till Struts 2.0?


For integration into the core of Struts, yes it does.  But we can provide
an optional add-on integration for Faces, just like struts-el does for EL
evaluation, as soon as Faces 1.0 goes final.  Use it if you want, but it's
not required by the core of Struts.

OK, just do one or the other, so everyone is playing on the level field.

So all I am saying, call v 1.2 2.0 if you want, but target 2.3.

.V



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

Re: [PROPOSAL] Modular Struts Examples

[Craig R. McClanahan]

On Thu, 3 Jul 2003, Vic Cekvenich wrote:

> My point was a shade on the other side. Yes Struts can show integration
> to do 100's of things out there.
> But at its core, Struts is a controller framework.

Right now, it's in particular a "front controller" framework, in design
pattern terms.  That's one of the areas I would personally like to see us
do some innovation.

>
> Action Event Object execute signature- instead of the execute signature
> with 4 arguments, have a single object containing the 4 objects.
> This reduces people new to Struts creating properties in action, and
> allows same execute signature for TilesAction, etc. The code looks a lot
> cleaner. bP does this (as I think does Expresso)

No matter how technically worthy such an idea might be, this isn't going
to happen in a 1.x train, due to backwards compatibility expectations.
This is part of the responsibility that goes with being a widely deployed
and utilized framework -- we have to protect the investment of people who
have built on top of the existing architecture.  If we only had a few
users, we would be more free to do stuff like this.  But according to the
Apache web site stats (unofficial, but seem like they're pretty accurate)
we get ~75,000 downloads per month, and that was BEFORE 1.1 went final.

If we're willing to look at changing the fundamental APIs (and I think we
are in a 2.x train), there is a lot more we can do to make Struts better
than just this kind of change -- I'd rather look at the overall
architecture more holistically, instead of incrementally, when making
decisions like this.  For example, I will shortly be done with a pretty
radical proposal for the "decomposing the request processor" conundrum
that has been discussed a lot lately on STRUTS-DEV.

Incremental change is great for improving implementations.  It's not so
great for modifying fundamental APIs.  To do the latter well, you need to
be prepared to think outside the box, and even re-invent yourself on
occasion.

>
> protected List _list in FormBean. As Husted's book points out (and bP
> implements), it is nice to store data in a protected _list. (I am sure I
> took it out of context) People mostly work with a tabular recordset,
> rows of columns, eg: List of Maps. There are many ways of getting DAO
> data to FormBean, but a good idea is to store the rows as a _list.
> People that extend the ValidatorFormBean can then write their own
> getValue, setValue and beann getters/setter, it nuges people in right
> direction to store data agnosticly. (Ex: MQ gets results, remaped via
> magic to formBean, and stores in a list).  Things like indexed
> properties become easier then ... and best view in JSP world is display
> tag, works with collection. Note that I would not implement the methods,
> just leave it like that, protected _list, a place to plug into.
>

As you well know :-), you and I don't totally share a vision of what a
form bean is for, and what it's not for :-).  However, the recent progress
on JavaServer Faces clearly indicates that Struts's form bean approach,
and total lack of any real UI component model, needs to be addressed.

I'd actually rather address it by focusing on the controller (as you
suggest), and let all the view-layer considerations be separated as well.
I think that form beans, by themselves, are too limiting as a long term
abstraction for server-side view state.

Just as an example of this, look at where JavaServer Faces is today, with
respect to the concepts behind form beans and actions:

* You can use one form bean per page, or more than one -- your choice.

* You can combine the form bean data with your "action" class
  (the way that WebWorks does it) or keep them separate -- your choice.

* You can ask for ANY bean to be automatically instantiated on demand,
  not just form beans.

The technology train is passing us by.  We're not going to be able to
catch up with simple incremental changes.

> Maveric instead of Ant for build. My argument is this. CVS out
> CommonsSQL and use Maverick to build it. Sexy!
> It auto downloads all the other jars it needs. People can target any
> thing very easily. The build process becomes simple and fun.
> (I do not have this code, but could)
>

In the Apache world, Maven provides similar sorts of capabilities, and
does not require you to give up the ability to use plain old Ant (Maven
can generate a build.xml file for you).  If we're going to switch, I'd
rather go that direction (if the Maven folks would ever ship a final
release, at least).

Improving the build process is definitely needed, but that's mostly for us
as developers, not for users.

> Required in DTD of sturts-config the request processor element. - This
> nudges expert users in extending Struts in the right place, it expo

Re: [PROPOSAL] Modular Struts Examples

[Craig R. McClanahan]

On Thu, 3 Jul 2003, Vic Cekvenich wrote:

> Date: Thu, 03 Jul 2003 15:27:58 -0400
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
> snip
> >>
> >>Target servlet 2.3 snip - There are now dependencies on 2.3 and
> >>more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like
> >>
> >>more fun. People that want 2.2 or 1.3 could rebuild, or they can keep
> >>using solid 1.1. A small KISS step. By the time 1.2 comes out
> >>
> snip
>
> >
> >
> > How many times do we need to explain this to you?  Struts 1.x is based on
> > Servlet 2.2 and JSP 1.1.  It would take a major release version upgrade to
> > change that dependency.
> >
> > David
> >
> >
> >>.V
> >>
> >>>
> >>>Craig
> >>
> >>
>
>
> Would David's argument be that JSF integration (requires 2.3) be
> postponed till Struts 2.0?

For integration into the core of Struts, yes it does.  But we can provide
an optional add-on integration for Faces, just like struts-el does for EL
evaluation, as soon as Faces 1.0 goes final.  Use it if you want, but it's
not required by the core of Struts.

> OK, just do one or the other, so everyone is playing on the level field.
>
> And a great argument on Maverick vs Ant David.
> Good thing I did not do the diff for all of this.
>
> Here is "Struts" with JSP2.0:
>
> 
> 
>   
> ${fb['title']}
>   
> 
> 
>   
>   
>${fb['content']}
>   
> 
> 
>
> The most importnat part is that the C tag, DOES NOT NEED TO BE DECLARED
> in the JSP 2.0, since C tag, and EL is part of the JSP 2.0 Spec. Nice.

Well, if you actually use  you still have to declare the tag
library :-).  But your point is well taken, that you don't even need to
use  in most cases.

>
>
> .V

Craig

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

RE: [PROPOSAL] Modular Struts Examples

[Steve Raeburn]

I think the examples themselves are OK but there's no single place you can
look to find an answer.

I realise that people *should* be able to find everything they need from
what's already there, but I think we need to go the extra mile to put the
information in front of them. It's really self-interest on my part- I'd like
Struts to be *even* more widely adopted but it would be nice not to have to
keep answering the same old questions. If we are able to repeatedly refer
these questions to a single source for the answer, then it *might* just
stick that that's the place to look before you ask a question! If not then
it's still easier to ask people to LATFE (look at the examples ;-))

And if we have a really clear set of introductory functional examples, that
makes it more reasonable IMHO to have a more realistic working example that
need not cater so much to absolute beginners.

Steve

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: July 2, 2003 1:39 PM
> To: Struts Developers List
> Subject: RE: [PROPOSAL] Modular Struts Examples
>
>
> Do users find the examples confusing?  I often refer people to the
> struts-example and struts-validator apps for help so I don't think they're
> under publicized.  I'm not sure that consolidating the examples would make
> them easier to understand.  I certainly want an example module app and an
> app that demonstrates a real world example would also be helpful.
>
> David
>




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

RE: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[Steve Raeburn]

Thanks David, that's clearer now. 

Steve

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: July 2, 2003 1:45 PM
> To: Struts Developers List
> Subject: Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts
> Examples)
> 
> 
> --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > What problems would be solved by repackaging into seperate jars?
> 
> There is a perception among some people that Struts only supports JSP in
> the view layer because it provides JSP tags.  While this is not true, it
> would be clearer if there was a separate taglib jar.  Velocity users
> wouldn't have to lug around the JSP tags but, more importantly, the tags
> could have their own release cycle.  A *large* percentage of bugs are
> reported against the tags so it makes sense to decouple them from the
> "core".
> 
> Also, as JSF becomes the standard view technology, there won't be a need
> for the Struts specific html taglibs (JSTL has already largely replaced
> the bean and logic taglibs).  So, it makes sense to separate the Struts
> "core" from the view layer technology because there are many choices out
> there besides the Struts JSP custom tags.
> 
> I don't see any benefit to separating out other parts of Struts besides
> the custom tags.
> 
> David
> 
> > 
> > Steve
> > 



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

RE: [PROPOSAL] Modular Struts Examples

[Steve Raeburn]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: July 3, 2003 4:40 AM
> To: Struts Developers List
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
>
> I'm -1 on demonstrating anything but best practices all the time. We
> made that mistake with MailReader and it has haunted us ever since.
> Unfortunately, people expect everything we do to be an example they can
> emulate.

Perhaps I overstated it when I said "best practices". What I meant is that
in a set of examples aimed at newcomers we should favour clarity over
elegance. That may mean doing things that we wouldn't do in a production
app. I certainly don't intend to demonstrate *bad* practices.

For instance, in my current set of examples there's a great deal of
duplication of code in both the actions and JSPs that would normally be
eliminated. I felt it was important for each example to be self-contained so
that users would not get confused by having to refer to many different
sections of the app to understand how the example worked.

> Meanwhile, I would be +1 on using Tiles in the Struts Examples module,
> since there is so much repetitive markup, anything else would be a bad
> practice =:)

See above on why I'm not sure this is so good :-)

My reasoning behind suggesting the two apps is that the former would provide
a minimal demonstration of the functions of Struts where the example is
self-contained and stripped down to the bare minimum in order to not confuse
the user with infrastructure details. The latter would show how to do things
"the right way" in concert with other features. ("The right way" here
meaning one of several possible right ways).

To my mind we're addressing two different issues. The first is functional;
"How do I do ...?" and the second is architectural, "What's the best way to
design ...?".  My concern is that combining the two will make it harder than
necessary to understand the simple examples. If they can both be addressed
in the same application without sacrificing clarity then I'm all for it.

Steve



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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

snip
Target servlet 2.3 snip - There are now dependencies on 2.3 and 
more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like

more fun. People that want 2.2 or 1.3 could rebuild, or they can keep 
using solid 1.1. A small KISS step. By the time 1.2 comes out

snip



How many times do we need to explain this to you?  Struts 1.x is based on
Servlet 2.2 and JSP 1.1.  It would take a major release version upgrade to
change that dependency.
David


.V

Craig




Would David's argument be that JSF integration (requires 2.3) be 
postponed till Struts 2.0?
OK, just do one or the other, so everyone is playing on the level field.

And a great argument on Maverick vs Ant David.
Good thing I did not do the diff for all of this.
Here is "Struts" with JSP2.0:



 
   ${fb['title']}
 


 
 
  ${fb['content']}
 


The most importnat part is that the C tag, DOES NOT NEED TO BE DECLARED 
in the JSP 2.0, since C tag, and EL is part of the JSP 2.0 Spec. Nice.

.V



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

Re: [PROPOSAL] Modular Struts Examples

[David Graham]

> I have no problem beeing silly. :-)
> My point was a shade on the other side. Yes Struts can show integration 
> to do 100's of things out there.
> But at its core, Struts is a controller framework.
> So the "value" of MVC upload is a bit of a gray area.
> If we kind of agree (ahh agree) that Struts is model agnostic and view 
> agnostic, I was just implying that upload is not a core value of Struts.

Providing upload ability in Struts is needed.  Struts is designed to make
developing webapps simple, not ripping out functionality and telling
people to go do it themselves.


> Maveric instead of Ant for build. My argument is this. CVS out 
> CommonsSQL and use Maverick to build it. Sexy!

I don't know what you mean by this but CVS and Ant are *well* understood
by thousands of developers.  There is no reason to change it now.

> It auto downloads all the other jars it needs. People can target any 
> thing very easily. The build process becomes simple and fun.
> (I do not have this code, but could)
> 
> Required in DTD of sturts-config the request processor element. - This 
> nudges expert users in extending Struts in the right place, it exposes 
> the right place overlooked.
> 
> Reduce number of actions and formbeans in Struts. It could be
> consolidated.
> 
> DAO - OK, here I walk a fine line.
> Struts is model agnostic. But slowest part of J2EE is DAO; and Struts is
> 
> the most popular J2EE framework. No one outside of Struts-dev can fix 
> this. If there can be an interface (I know, if you change it bla, 
> bla) for a DAO, that is KISS, but could work for JDO, EJB, Hibrenate, 
> RowSet, MQ, etc. etc. It would enable people to easily plug and play a 
> model. I do not care what the signatures of this DAO are other than it 
> must allow ANY DAO implementation to be used and shoud be unit testable 
> for CRUD.
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bPproj/src/war/com/baseBeans/scaFfoldingXpress/base/DAO.java
> Craig, I realy realy think that only you can make this happen. (That 
> registration of DAO for JSF I did not like, interface is KISS)

There is a project in the Commons sandbox called Mapper that attempts to
do exactly this.  Struts has no business incorporating DAOs.

> 
> Display tag- (Talk out of bouth sides of your mouth) Yes Stuts is view 
> agnostic. But Display tag commiters are trying to make it updateable 
> AFAIK. Download the display tag war and run examples. This is the 
> colosest thing to DataGrid in JSP. Put it in Struts to get focus (and 
> then slowly move to taglibs).
> 
> Anything else out of bP that somoene likes. (Ex: j2Ee + Sturts security 
> example, multi row updates, events - like action changed event for 
> session clean up)
> 
> Target servlet 2.3 and JDK 1.4. - There are now dependencies on 2.3 and 
> more comming. Almost no one uses Tomcat 3. TC 5 level JSP 2.0 looks like
> 
> more fun. People that want 2.2 or 1.3 could rebuild, or they can keep 
> using solid 1.1. A small KISS step. By the time 1.2 comes out
> 
> I will do the legwork on any of these, if a single dev is interested in 
> applying the diff., but most are trivial and do not need man hours. The 
> last one I hope makes it for the 1.2 release

How many times do we need to explain this to you?  Struts 1.x is based on
Servlet 2.2 and JSP 1.1.  It would take a major release version upgrade to
change that dependency.

David

> 
> .V
> 
> 
> 
> V
> >>
> > 
> > 
> > Craig
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> 
=== message truncated ===


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

Craig R. McClanahan wrote:
SNIP> 

We definitely need examples of modules, and all of the other individual
features.  I am not a believer that "one big example app" is the right way
to approach that -- the sheer scale of such a thing would be a barrier to
entry.  It's better in some cases (say, illustrating the different ways
you can use some of the tags) to have single-page illustrations (like what
we do in struts-exercise-taglib, but focused on, and documented as, being
examples rather than pseudo-unit-tests).
Also, there's no way that one could ever hope to illustrate *all* possible
best practices in a single application anyway, because there are
legitimate application-specific needs to choose between various
alternatives at every design point.  The fact that you choose one
particular strategy for user authentication (say, to use SecurityFilter
instead of container managed authentication) does not automatically make
all other choices "bad" or even "not best" -- they are just "different".

Yes, no monolithic best practice. It also changes over time, what was 
best done with logic can now be done via C tag, etc. etc. So just keep 
adding more better examples ... and then when something is way to old, 
just stop carrying the war. Sites like struts.sf.net and others have 
more examples  plus what Craig said, many different approaches, 
Camino, Expresso. Else all would be using basicPortal :-)


I think struts-upload could be deprecated (along with bean and logic
tags). People can do file upload out of commons, or using Jason Hunter's
COS upload. etc. Upload is not a Struts core value and could go back to
commons.


Have you been paying attention, Vic?  The Struts file upload
implementation uses commons-fileupload already :-).
More seriously, though, file uploading functionality really has two parts:

* The generic part that can be (and is) used in any web application
  framework, and/or stand alone (as is the case with
  commons-fileupload, which is used by Turbine and Tapestry
  as well as by Struts).
* The part that integrates the generic library into your
  particular framework (for our purposes, that's things like the
   tag that is Struts-specific, and not appropriate
  for the generic library).  It's entirely reasonable to have
  adapters like this; every other framework will do the same.
We did the right thing by factoring out the common part of fileupload and
sharing it -- just like we did with validator. 
GREAT!

 But it is silly to suggest
that Struts should give up the custom integration part of that, simply
because the fundamental logic is generic.
I have no problem beeing silly. :-)
My point was a shade on the other side. Yes Struts can show integration 
to do 100's of things out there.
But at its core, Struts is a controller framework.
So the "value" of MVC upload is a bit of a gray area.
If we kind of agree (ahh agree) that Struts is model agnostic and view 
agnostic, I was just implying that upload is not a core value of Struts. 
People that want upload can upload, and Struts is agnostic. So if 
struts-dev decides to slolwy move tags to jsptaglib, one think that can 
be marked for moving out (and solidifying core) is upload integration.
I do not feel strongly about it at all, to say that Struts can redcue 
it's scope a bit. So no + or - 0.


I would like for 1.2 to ... (can someone set up a "wish list" wiki
please?) is repackage into 2 jars: Struts core, and other (taglibs), a
few patches and a quick release. Also maybe Mavenize Struts build.


As Ted says, the Wiki is available for everyone to make their own
proposals.  So is the STRUTS-DEV list :-).  In either case, though,
specific proposals (with specific action plans) are generally more likely
to have useful effects, rather than generic suggestions.
And, don't forget, patches often speak louder than words :-)
I have 18 months ago worked with a few people(clients) to post patches 
to Struts with diff in bugzila and ... nothing happened. And I have seen 
this with other things in bugzilla.
So the things I propose I can post code to (since I use/tested already 
on site), if a commiter is willing to work with me to put in CVS. So 
after I propose, if a dev says oh, thats sounds fun, I, Vic, will do 
the CVS diff. after there is at least tiny interest of a specific dev 
member.

Ex:

Action Event Object execute signature- instead of the execute signature 
with 4 arguments, have a single object containing the 4 objects.
This reduces people new to Struts creating properties in action, and 
allows same execute signature for TilesAction, etc. The code looks a lot 
cleaner. bP does this (as I think does Expresso)

protected List _list in FormBean. As Husted's book points out (and bP 
implements), it is nice to store data in a protected _list. (I am sure I 
took it out of context) People mostly work with a tabular recordset, 
rows of columns, eg: List of Maps. There are many ways of getting DAO 
data to FormBean, but a good idea is t

Re: [PROPOSAL] Modular Struts Examples

[Craig R. McClanahan]

On Wed, 2 Jul 2003, Vic Cekvenich wrote:

> Date: Wed, 02 Jul 2003 06:55:06 -0400
> From: Vic Cekvenich <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Modular Struts Examples
>
> -0.
>
> Module was... is optional and confusing. I think delay this a point
> after 1.2.
>

We definitely need examples of modules, and all of the other individual
features.  I am not a believer that "one big example app" is the right way
to approach that -- the sheer scale of such a thing would be a barrier to
entry.  It's better in some cases (say, illustrating the different ways
you can use some of the tags) to have single-page illustrations (like what
we do in struts-exercise-taglib, but focused on, and documented as, being
examples rather than pseudo-unit-tests).

Also, there's no way that one could ever hope to illustrate *all* possible
best practices in a single application anyway, because there are
legitimate application-specific needs to choose between various
alternatives at every design point.  The fact that you choose one
particular strategy for user authentication (say, to use SecurityFilter
instead of container managed authentication) does not automatically make
all other choices "bad" or even "not best" -- they are just "different".

> I think struts-upload could be deprecated (along with bean and logic
> tags). People can do file upload out of commons, or using Jason Hunter's
> COS upload. etc. Upload is not a Struts core value and could go back to
> commons.

Have you been paying attention, Vic?  The Struts file upload
implementation uses commons-fileupload already :-).

More seriously, though, file uploading functionality really has two parts:

* The generic part that can be (and is) used in any web application
  framework, and/or stand alone (as is the case with
  commons-fileupload, which is used by Turbine and Tapestry
  as well as by Struts).

* The part that integrates the generic library into your
  particular framework (for our purposes, that's things like the
   tag that is Struts-specific, and not appropriate
  for the generic library).  It's entirely reasonable to have
  adapters like this; every other framework will do the same.

We did the right thing by factoring out the common part of fileupload and
sharing it -- just like we did with validator.  But it is silly to suggest
that Struts should give up the custom integration part of that, simply
because the fundamental logic is generic.

>
> I would like for 1.2 to ... (can someone set up a "wish list" wiki
> please?) is repackage into 2 jars: Struts core, and other (taglibs), a
> few patches and a quick release. Also maybe Mavenize Struts build.

As Ted says, the Wiki is available for everyone to make their own
proposals.  So is the STRUTS-DEV list :-).  In either case, though,
specific proposals (with specific action plans) are generally more likely
to have useful effects, rather than generic suggestions.

And, don't forget, patches often speak louder than words :-)

>
> (after 1.2 consolidate actions and beans classes).
>
> .V
>

Craig

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

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

Vic Cekvenich wrote:
> OK, just to enumerate:
>
> struts-documentation.war ( html tag docs),
> mail-reader.war,
> TomcatLikeNewExampleByTheNewCommiter.war,
> tiles.war
> blank.war
> validator.war
>
> Is this the list?
> .V
The list of applications we ship now is

struts-blank
struts-documentation (website)
struts-example (MailReader)
struts-exercise-taglib
struts-template
struts-upload
struts-validator
tiles-documentation
I would suggest we can reduce this list to

struts-blank
struts-docs
by making the others modules to struts-docs, and adding an new module, 
struts-examples, based on Steve's application.

Template can be removed altoghether, I think. The content of Upload and 
Validator can be moved into the Examples module. So, I'd foresee four 
modules in struts-docs

examples
exercise-taglibs
mailreader
website
At first there would probably be a tiles-docs module too, but it's 
possible that we can reduce those to a section in the examples module.

I think the examples approach to demonstrating how to do things will be 
more effective than what we are doing now, with only a small additional 
investment of effort. The source page gives you a place to show how it 
all fits together, and also to add notes if necessary.

-Ted.



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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

OK, just to enumerate:

struts-documentation.war ( html tag docs),
mail-reader.war,
TomcatLikeNewExampleByTheNewCommiter.war,
tiles.war
blank.war
validator.war
Is this the list?
.V
Ted Husted wrote:
Steve Raeburn wrote:

In the interests of ease of understanding, the first application would 
not
necessarily exhibit best practice all the time. For instance, in the
examples I put together I have made no effort to protect JSPs with a
security constraint or by placing them under WEB-INF. I felt this was not
necessary to demonstrate the tags in use and might confuse novice 
users. I
don't necessarily think this app should use modules as this could again
confuse new users. I'm prepared to be convinced on that, Ted :-)


I'm -1 on demonstrating anything but best practices all the time. We 
made that mistake with MailReader and it has haunted us ever since. 
Unfortunately, people expect everything we do to be an example they can 
emulate.

Though, I don't agree that using a security constraint or placing pages 
under WEB-INF is a best practice. It's a common *pattern*, but there's 
no tangible benefit. If I do do it, it's just to remind other team 
members to follow the "Link only to actions (never to server pages)" 
best practice. [See what I mean, just because I document the pattern, 
people think I advocate it as a best practice =:)]

Meanwhile, I would be +1 on using Tiles in the Struts Examples module, 
since there is so much repetitive markup, anything else would be a bad 
practice =:)


The second application should demonstrate current best practice in the
context of a working, realistic application. The purpose of this app 
would
not be to tutor novice users but to show how Struts features can be used
together to create real-world applications. Struts Pet Store springs 
to mind
as a possible example.


I think something like this might be a good candidate for the Struts 
Application site at SourceForge. IMHO, our scope here should be the core 
documentation, a simple starter application (MailReader is fine), and a 
library of examples, like the ones you started. I think much of the 
Tiles-Doc would work better in the example format as well.

To help with the understanding how it all comes together, I'd like to 
adopt the "example" format for the MailReader too. So instead of just 
having a plain text "tour", we would have an annotated walk-through, 
where people can call up the corresponding source code and JSPs along 
the way. (Wish I thought of that when I first wrote the tour -- we had 
the Tomcat Examples even then).


Struts-blank would continue as the basic starter application template.


+1, and I think this should be the only second application that we need, 
and only because it's intended use is to drag, drop, and develop.

The intended course would then be to walk through MailReader to get the 
big picture, start your own development with Struts Blank, picking and 
choosing whatever use cases you needed from the Examples. For additional 
background, the core documentation would be "right there" as well.

-Ted.


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

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

+1 on integration testing. =:)

Though, I think that we will find that once the Examples application is 
available, it will turn into a fertile ground for testing the 
integration of new features. Rather than trying to stretch the 
MailReader to fill a new use case, we can do a use-case example and make 
that another of the Examples.

I'm working on a cookbook project that does this for a ton of examples. 
It takes a bit of work to keep it all together, but with a few simple 
conventions, it can be quite manageable.

For taglibs, I'd suggest we try to add or extend a taglib-exercise for 
any new tag or tag enhancement, but IMHO those tests work best as simple 
Model 1 creatures without dependencies on other objects.

-Ted

David Graham wrote:
However we combine the apps I want to make sure MailReader continues to be
suitable for testing changes in.  I often run through and/or modify
MailReader to test changes before committing them.
David


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

Re: [PROPOSAL] Modular Struts Examples

[David Graham]

However we combine the apps I want to make sure MailReader continues to be
suitable for testing changes in.  I often run through and/or modify
MailReader to test changes before committing them.

David

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Steve Raeburn wrote:
> > In the interests of ease of understanding, the first application would
> not
> > necessarily exhibit best practice all the time. For instance, in the
> > examples I put together I have made no effort to protect JSPs with a
> > security constraint or by placing them under WEB-INF. I felt this was
> not
> > necessary to demonstrate the tags in use and might confuse novice
> users. I
> > don't necessarily think this app should use modules as this could
> again
> > confuse new users. I'm prepared to be convinced on that, Ted :-)
> 
> I'm -1 on demonstrating anything but best practices all the time. We 
> made that mistake with MailReader and it has haunted us ever since. 
> Unfortunately, people expect everything we do to be an example they can 
> emulate.
> 
> Though, I don't agree that using a security constraint or placing pages 
> under WEB-INF is a best practice. It's a common *pattern*, but there's 
> no tangible benefit. If I do do it, it's just to remind other team 
> members to follow the "Link only to actions (never to server pages)" 
> best practice. [See what I mean, just because I document the pattern, 
> people think I advocate it as a best practice =:)]
> 
> Meanwhile, I would be +1 on using Tiles in the Struts Examples module, 
> since there is so much repetitive markup, anything else would be a bad 
> practice =:)
> 
> 
> > The second application should demonstrate current best practice in the
> > context of a working, realistic application. The purpose of this app
> would
> > not be to tutor novice users but to show how Struts features can be
> used
> > together to create real-world applications. Struts Pet Store springs
> to mind
> > as a possible example.
> 
> I think something like this might be a good candidate for the Struts 
> Application site at SourceForge. IMHO, our scope here should be the core
> 
> documentation, a simple starter application (MailReader is fine), and a 
> library of examples, like the ones you started. I think much of the 
> Tiles-Doc would work better in the example format as well.
> 
> To help with the understanding how it all comes together, I'd like to 
> adopt the "example" format for the MailReader too. So instead of just 
> having a plain text "tour", we would have an annotated walk-through, 
> where people can call up the corresponding source code and JSPs along 
> the way. (Wish I thought of that when I first wrote the tour -- we had 
> the Tomcat Examples even then).
> 
> 
> > Struts-blank would continue as the basic starter application template.
> 
> +1, and I think this should be the only second application that we need,
> 
> and only because it's intended use is to drag, drop, and develop.
> 
> The intended course would then be to walk through MailReader to get the 
> big picture, start your own development with Struts Blank, picking and 
> choosing whatever use cases you needed from the Examples. For additional
> 
> background, the core documentation would be "right there" as well.
> 
> -Ted.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

Vic Cekvenich wrote:
-0.

Module was... is optional and confusing. I think delay this a point 
after 1.2.
I'd say the opposite. We need to "eat our own dog food" and use modules 
in our own applications or drop that line of development altogether.

Given modules in 1.1, it's hard to justify distributing all these 
picyune applications, that could just as easily be modules.


I think struts-upload could be deprecated (along with bean and logic 
tags). People can do file upload out of commons, or using Jason Hunter's 
COS upload. etc. Upload is not a Struts core value and could go back to 
commons.
The upload example application uses the Commons-Fileupload package. If 
we bring the Struts Examples module online, the file upload example 
would be just one of these, and wouldn't need to be a separate application.


I would like for 1.2 to ... (can someone set up a "wish list" wiki 
please?) 
The Wiki is open to everyone. Asking someone else to setup a wiki page 
is contrary to the whole idea of a wiki =:0)

-Ted.





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

Re: [PROPOSAL] Modular Struts Examples

[Ted Husted]

Steve Raeburn wrote:
In the interests of ease of understanding, the first application would not
necessarily exhibit best practice all the time. For instance, in the
examples I put together I have made no effort to protect JSPs with a
security constraint or by placing them under WEB-INF. I felt this was not
necessary to demonstrate the tags in use and might confuse novice users. I
don't necessarily think this app should use modules as this could again
confuse new users. I'm prepared to be convinced on that, Ted :-)
I'm -1 on demonstrating anything but best practices all the time. We 
made that mistake with MailReader and it has haunted us ever since. 
Unfortunately, people expect everything we do to be an example they can 
emulate.

Though, I don't agree that using a security constraint or placing pages 
under WEB-INF is a best practice. It's a common *pattern*, but there's 
no tangible benefit. If I do do it, it's just to remind other team 
members to follow the "Link only to actions (never to server pages)" 
best practice. [See what I mean, just because I document the pattern, 
people think I advocate it as a best practice =:)]

Meanwhile, I would be +1 on using Tiles in the Struts Examples module, 
since there is so much repetitive markup, anything else would be a bad 
practice =:)


The second application should demonstrate current best practice in the
context of a working, realistic application. The purpose of this app would
not be to tutor novice users but to show how Struts features can be used
together to create real-world applications. Struts Pet Store springs to mind
as a possible example.
I think something like this might be a good candidate for the Struts 
Application site at SourceForge. IMHO, our scope here should be the core 
documentation, a simple starter application (MailReader is fine), and a 
library of examples, like the ones you started. I think much of the 
Tiles-Doc would work better in the example format as well.

To help with the understanding how it all comes together, I'd like to 
adopt the "example" format for the MailReader too. So instead of just 
having a plain text "tour", we would have an annotated walk-through, 
where people can call up the corresponding source code and JSPs along 
the way. (Wish I thought of that when I first wrote the tour -- we had 
the Tomcat Examples even then).


Struts-blank would continue as the basic starter application template.
+1, and I think this should be the only second application that we need, 
and only because it's intended use is to drag, drop, and develop.

The intended course would then be to walk through MailReader to get the 
big picture, start your own development with Struts Blank, picking and 
choosing whatever use cases you needed from the Examples. For additional 
background, the core documentation would be "right there" as well.

-Ted.



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

Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[David Graham]

--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:
> Agree 99.5%! (other than JSF of course, but all commers are welcome)
> 
> Struts does not select a DAO! There are some good DAO's standard or not 
> and some bad ones. How many use the standard JDO? What if Struts shiped 
> with JDO by Castor(and Castor proved slow for example, as it did)?
> 
> Struts could get out of View (very slowly move tags to jakarta taglib) 
> and be agnostic on view. 

Struts is view agnostic.  You can use any view technology you like.

David

> Pick your poison. I think a lot of people (my 
> clients all do) use display tag (and Struts menu), but it does not ship 
> with Struts, no big deal.
> 
> And Struts could down the road then dish out XML, ala SOA, or Axis. XML 
> could then be rendered by any view I can think of, like the X tag. Maybe
> 
> require the request processor element in struts-config.dtd to nudge
> people.
> 
> Struts core is controller and with that focus maybe better release
> cycle.
> 
> .V
> 
> David Graham wrote:
> > --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > 
> >>What problems would be solved by repackaging into seperate jars?
> > 
> > 
> > There is a perception among some people that Struts only supports JSP
> in
> > the view layer because it provides JSP tags.  While this is not true,
> it
> > would be clearer if there was a separate taglib jar.  Velocity users
> > wouldn't have to lug around the JSP tags but, more importantly, the
> tags
> > could have their own release cycle.  A *large* percentage of bugs are
> > reported against the tags so it makes sense to decouple them from the
> > "core".
> > 
> > Also, as JSF becomes the standard view technology, there won't be a
> need
> > for the Struts specific html taglibs (JSTL has already largely
> replaced
> > the bean and logic taglibs).  So, it makes sense to separate the
> Struts
> > "core" from the view layer technology because there are many choices
> out
> > there besides the Struts JSP custom tags.
> > 
> > I don't see any benefit to separating out other parts of Struts
> besides
> > the custom tags.
> > 
> > David
> > 
> > 
> >>Steve
> >>
> >>
> >>>-Original Message-
> >>>From: Etienne Labonté [mailto:[EMAIL PROTECTED]
> >>>Sent: July 2, 2003 7:46 AM
> >>>To: 'Struts Developers List'
> >>>Subject: RE: [PROPOSAL] Modular Struts Examples
> >>>
> >>>
> >>>I propose (quite informally) a new packaging:
> >>>
> >>>  Struts.jar (core logic only)
> >>>  Struts-taglib-rt.jar
> >>>  Struts-taglib-el.jar (from current contrib/struts-el.jar)
> >>>  *Struts-tiles.jar
> >>>  *Struts-upload.jar
> >>>  *Struts-validator.jar
> >>>  Struts-jsf.jar
> >>>
> >>>Jars preceded by * are optional. I see no problem with leaving
> >>>those closer
> >>>to the core.
> >>>
> >>>Perhaps heavier on the backs of release managers, but more intuitive
> >>
> >>in my
> >>
> >>>sense. Someone using Struts with velocity could use only the core
> >>
> >>part.
> >>
> >>>Someone doing JSP will know the difference between EL and non-EL.
> >>>Does this
> >>>make sense to you?
> >>>
> >>>
> >>>Etienne
> >>
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> > 
> > 
> > 
> > __
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[Vic Cekvenich]

Agree 99.5%! (other than JSF of course, but all commers are welcome)

Struts does not select a DAO! There are some good DAO's standard or not 
and some bad ones. How many use the standard JDO? What if Struts shiped 
with JDO by Castor(and Castor proved slow for example, as it did)?

Struts could get out of View (very slowly move tags to jakarta taglib) 
and be agnostic on view. Pick your poison. I think a lot of people (my 
clients all do) use display tag (and Struts menu), but it does not ship 
with Struts, no big deal.

And Struts could down the road then dish out XML, ala SOA, or Axis. XML 
could then be rendered by any view I can think of, like the X tag. Maybe 
require the request processor element in struts-config.dtd to nudge people.

Struts core is controller and with that focus maybe better release cycle.

.V

David Graham wrote:
--- Steve Raeburn <[EMAIL PROTECTED]> wrote:

What problems would be solved by repackaging into seperate jars?


There is a perception among some people that Struts only supports JSP in
the view layer because it provides JSP tags.  While this is not true, it
would be clearer if there was a separate taglib jar.  Velocity users
wouldn't have to lug around the JSP tags but, more importantly, the tags
could have their own release cycle.  A *large* percentage of bugs are
reported against the tags so it makes sense to decouple them from the
"core".
Also, as JSF becomes the standard view technology, there won't be a need
for the Struts specific html taglibs (JSTL has already largely replaced
the bean and logic taglibs).  So, it makes sense to separate the Struts
"core" from the view layer technology because there are many choices out
there besides the Struts JSP custom tags.
I don't see any benefit to separating out other parts of Struts besides
the custom tags.
David


Steve


-Original Message-
From: Etienne Labonté [mailto:[EMAIL PROTECTED]
Sent: July 2, 2003 7:46 AM
To: 'Struts Developers List'
Subject: RE: [PROPOSAL] Modular Struts Examples
I propose (quite informally) a new packaging:

 Struts.jar (core logic only)
 Struts-taglib-rt.jar
 Struts-taglib-el.jar (from current contrib/struts-el.jar)
 *Struts-tiles.jar
 *Struts-upload.jar
 *Struts-validator.jar
 Struts-jsf.jar
Jars preceded by * are optional. I see no problem with leaving
those closer
to the core.
Perhaps heavier on the backs of release managers, but more intuitive
in my

sense. Someone using Struts with velocity could use only the core
part.

Someone doing JSP will know the difference between EL and non-EL.
Does this
make sense to you?
Etienne


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


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


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

Re: Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[David Graham]

--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> What problems would be solved by repackaging into seperate jars?

There is a perception among some people that Struts only supports JSP in
the view layer because it provides JSP tags.  While this is not true, it
would be clearer if there was a separate taglib jar.  Velocity users
wouldn't have to lug around the JSP tags but, more importantly, the tags
could have their own release cycle.  A *large* percentage of bugs are
reported against the tags so it makes sense to decouple them from the
"core".

Also, as JSF becomes the standard view technology, there won't be a need
for the Struts specific html taglibs (JSTL has already largely replaced
the bean and logic taglibs).  So, it makes sense to separate the Struts
"core" from the view layer technology because there are many choices out
there besides the Struts JSP custom tags.

I don't see any benefit to separating out other parts of Struts besides
the custom tags.

David

> 
> Steve
> 
> > -Original Message-
> > From: Etienne Labonté [mailto:[EMAIL PROTECTED]
> > Sent: July 2, 2003 7:46 AM
> > To: 'Struts Developers List'
> > Subject: RE: [PROPOSAL] Modular Struts Examples
> >
> >
> > I propose (quite informally) a new packaging:
> >
> >   Struts.jar (core logic only)
> >   Struts-taglib-rt.jar
> >   Struts-taglib-el.jar (from current contrib/struts-el.jar)
> >   *Struts-tiles.jar
> >   *Struts-upload.jar
> >   *Struts-validator.jar
> >   Struts-jsf.jar
> >
> > Jars preceded by * are optional. I see no problem with leaving
> > those closer
> > to the core.
> >
> > Perhaps heavier on the backs of release managers, but more intuitive
> in my
> > sense. Someone using Struts with velocity could use only the core
> part.
> > Someone doing JSP will know the difference between EL and non-EL.
> > Does this
> > make sense to you?
> >
> >
> > Etienne
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

RE: [PROPOSAL] Modular Struts Examples

[David Graham]

Do users find the examples confusing?  I often refer people to the
struts-example and struts-validator apps for help so I don't think they're
under publicized.  I'm not sure that consolidating the examples would make
them easier to understand.  I certainly want an example module app and an
app that demonstrates a real world example would also be helpful.

David


--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> There are currently seven different webapps within the Struts
> distribution
> that users are referred to for examples of Struts usage:
> 
>  - struts-blank
>  - struts-example
>  - struts-excercise-taglib
>  - struts-template (not so much)
>  - tiles-documentation
>  - struts-upload
>  - struts-validator
> 
> Not to mention the examples hosted at Sourceforge.
> 
> Judging by the repetitive nature of certain questions on the user list
> there
> is a problem with finding/understanding the examples and/or
> finding/understanding the documentation.
> 
> I have observed that requests for examples tend to fall into two
> distinct
> categories:
>  1. examples demonstrating usage of a particular tag or feature
>  2. examples of best practice in using the Struts framework
> 
> I would like to see the existing examples consolidated to just two
> applications, each targeted at one of the categories just mentioned.
> 
> The first example application would provide many discrete examples, each
> demonstrating the use of just one feature of struts. This application
> should
> be easy to understand for a new Struts user, should be simple to deploy
> (drop-in war deployment with no configuration required) and should
> become
> *the* point of reference for the Struts documentation and mailing lists.
> It
> could also be used a library of cut-and-paste code. Based on the Tomcat
> examples, I have created what could be the basis for this app
> (http://www.ninsky.com/struts).
> 
> In the interests of ease of understanding, the first application would
> not
> necessarily exhibit best practice all the time. For instance, in the
> examples I put together I have made no effort to protect JSPs with a
> security constraint or by placing them under WEB-INF. I felt this was
> not
> necessary to demonstrate the tags in use and might confuse novice users.
> I
> don't necessarily think this app should use modules as this could again
> confuse new users. I'm prepared to be convinced on that, Ted :-)
> 
> The second application should demonstrate current best practice in the
> context of a working, realistic application. The purpose of this app
> would
> not be to tutor novice users but to show how Struts features can be used
> together to create real-world applications. Struts Pet Store springs to
> mind
> as a possible example.
> 
> Struts-blank would continue as the basic starter application template.
> 
> I would hope that consolidating the examples and effectively publicizing
> them would help reduce the support burden (call me a dreamer!) and
> enable
> users to become more productive with Struts more quickly.
> 
> Steve
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

Struts repackaging (was RE: [PROPOSAL] Modular Struts Examples)

[Steve Raeburn]

What problems would be solved by repackaging into seperate jars?

Steve

> -Original Message-
> From: Etienne Labonté [mailto:[EMAIL PROTECTED]
> Sent: July 2, 2003 7:46 AM
> To: 'Struts Developers List'
> Subject: RE: [PROPOSAL] Modular Struts Examples
>
>
> I propose (quite informally) a new packaging:
>
>   Struts.jar (core logic only)
>   Struts-taglib-rt.jar
>   Struts-taglib-el.jar (from current contrib/struts-el.jar)
>   *Struts-tiles.jar
>   *Struts-upload.jar
>   *Struts-validator.jar
>   Struts-jsf.jar
>
> Jars preceded by * are optional. I see no problem with leaving
> those closer
> to the core.
>
> Perhaps heavier on the backs of release managers, but more intuitive in my
> sense. Someone using Struts with velocity could use only the core part.
> Someone doing JSP will know the difference between EL and non-EL.
> Does this
> make sense to you?
>
>
> Etienne



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

RE: [PROPOSAL] Modular Struts Examples

[Steve Raeburn]

There are currently seven different webapps within the Struts distribution
that users are referred to for examples of Struts usage:

 - struts-blank
 - struts-example
 - struts-excercise-taglib
 - struts-template (not so much)
 - tiles-documentation
 - struts-upload
 - struts-validator

Not to mention the examples hosted at Sourceforge.

Judging by the repetitive nature of certain questions on the user list there
is a problem with finding/understanding the examples and/or
finding/understanding the documentation.

I have observed that requests for examples tend to fall into two distinct
categories:
 1. examples demonstrating usage of a particular tag or feature
 2. examples of best practice in using the Struts framework

I would like to see the existing examples consolidated to just two
applications, each targeted at one of the categories just mentioned.

The first example application would provide many discrete examples, each
demonstrating the use of just one feature of struts. This application should
be easy to understand for a new Struts user, should be simple to deploy
(drop-in war deployment with no configuration required) and should become
*the* point of reference for the Struts documentation and mailing lists. It
could also be used a library of cut-and-paste code. Based on the Tomcat
examples, I have created what could be the basis for this app
(http://www.ninsky.com/struts).

In the interests of ease of understanding, the first application would not
necessarily exhibit best practice all the time. For instance, in the
examples I put together I have made no effort to protect JSPs with a
security constraint or by placing them under WEB-INF. I felt this was not
necessary to demonstrate the tags in use and might confuse novice users. I
don't necessarily think this app should use modules as this could again
confuse new users. I'm prepared to be convinced on that, Ted :-)

The second application should demonstrate current best practice in the
context of a working, realistic application. The purpose of this app would
not be to tutor novice users but to show how Struts features can be used
together to create real-world applications. Struts Pet Store springs to mind
as a possible example.

Struts-blank would continue as the basic starter application template.

I would hope that consolidating the examples and effectively publicizing
them would help reduce the support burden (call me a dreamer!) and enable
users to become more productive with Struts more quickly.

Steve



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

RE: [PROPOSAL] Modular Struts Examples

[Etienne Labonté]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 02, 2003 11:03 AM
> To: Struts Developers List
> Subject: RE: [PROPOSAL] Modular Struts Examples
> 
> --- Etienne_Labonté <[EMAIL PROTECTED]> wrote:
> > I propose (quite informally) a new packaging:
> >
> >   Struts.jar (core logic only)
> >   Struts-taglib-rt.jar
> >   Struts-taglib-el.jar (from current contrib/struts-el.jar)
> 
> I don't think we need separate rt and el jars.
> 

Agreed.
 
> >   *Struts-tiles.jar
> 
> Tiles includes taglibs. Do those go in struts-tiles.jar or
> struts-taglib.jar[?].
> 

I think tiles, upload and validator should remain in the core struts.jar and
tiles taglibs be put in struts-taglib.jar

> >   *Struts-upload.jar
> >   *Struts-validator.jar
> 
> Separating these 2 from struts.jar doesn't seem too useful to me.  However
> we end up breaking up the jars, I think it's important to have a
> struts-full.jar that has everything in it for people that don't want to
> mess with getting the right jars.
> 

Well, I end up saying "Hey, lets merge EL-contrib into the main body and
please do separate the taglibs from the core". 

The new list:

  Struts.jar
  Struts-taglib.jar
  Struts-jsf.jar

I don't think this would bring much confusion. And, anyway, people that
don't want to mess with getting the right jars usually just
bind them all to their webapp.

> David
> 
> >   Struts-jsf.jar
> >
> > Jars preceded by * are optional. I see no problem with leaving those
> > closer
> > to the core.
> >
> > Perhaps heavier on the backs of release managers, but more intuitive in
> > my
> > sense. Someone using Struts with velocity could use only the core part.
> > Someone doing JSP will know the difference between EL and non-EL. Does
> > this
> > make sense to you?
> >
> >
> > Etienne
> >
> > -Original Message-
> > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 30, 2003 4:53 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PROPOSAL] Modular Struts Examples
...
> 
> 
> __
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] Modular Struts Examples

[David Graham]

--- Etienne_Labonté <[EMAIL PROTECTED]> wrote:
> I propose (quite informally) a new packaging:
> 
>   Struts.jar (core logic only)
>   Struts-taglib-rt.jar
>   Struts-taglib-el.jar (from current contrib/struts-el.jar)

I don't think we need separate rt and el jars.

>   *Struts-tiles.jar

Tiles includes taglibs. Do those go in struts-tiles.jar or
struts-taglib.jar.

>   *Struts-upload.jar
>   *Struts-validator.jar

Separating these 2 from struts.jar doesn't seem too useful to me.  However
we end up breaking up the jars, I think it's important to have a
struts-full.jar that has everything in it for people that don't want to
mess with getting the right jars.

David

>   Struts-jsf.jar
> 
> Jars preceded by * are optional. I see no problem with leaving those
> closer
> to the core.
> 
> Perhaps heavier on the backs of release managers, but more intuitive in
> my
> sense. Someone using Struts with velocity could use only the core part.
> Someone doing JSP will know the difference between EL and non-EL. Does
> this
> make sense to you?
> 
> 
> Etienne
> 
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> Sent: Monday, June 30, 2003 4:53 PM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Modular Struts Examples
> 
> I'd like to propose that we gather together the
> 
> struts-documentation,
> struts-example (MailReader),
> struts-exercise-taglib,
> struts-upload,
> struts-validator, and
> tiles-documentation
> 
> webapps into a single "struts-docs" application, where each of the
> existing applications becomes a module. (Leaving the struts-blank out,
> since it is meant as a application template.)
> 
> At the same time, I would like to take Steve Raeburn up on his kind 
> offer to donate his Struts-Examples application
> 
> http://www.ninsky.com/struts/
> 
> to Struts and the Apache Software Foundation.
> 
> The Struts-Examples application offers a number of very useful code 
> samples. We can continue to grow the examples step-by-step over time and
> 
> defray many of the requests on the list for code samples.
> 
> As part of refactoring the various Struts applications into a single 
> application of several modules, we can also bring Steve's application on
> 
> board as another module to "Struts-Docs".
> 
> -Ted.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

RE: [PROPOSAL] Modular Struts Examples

[Etienne Labonté]

I propose (quite informally) a new packaging:

  Struts.jar (core logic only)
  Struts-taglib-rt.jar
  Struts-taglib-el.jar (from current contrib/struts-el.jar)
  *Struts-tiles.jar
  *Struts-upload.jar
  *Struts-validator.jar
  Struts-jsf.jar

Jars preceded by * are optional. I see no problem with leaving those closer
to the core.

Perhaps heavier on the backs of release managers, but more intuitive in my
sense. Someone using Struts with velocity could use only the core part.
Someone doing JSP will know the difference between EL and non-EL. Does this
make sense to you?


Etienne

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 30, 2003 4:53 PM
To: [EMAIL PROTECTED]
Subject: [PROPOSAL] Modular Struts Examples

I'd like to propose that we gather together the

struts-documentation,
struts-example (MailReader),
struts-exercise-taglib,
struts-upload,
struts-validator, and
tiles-documentation

webapps into a single "struts-docs" application, where each of the
existing applications becomes a module. (Leaving the struts-blank out,
since it is meant as a application template.)

At the same time, I would like to take Steve Raeburn up on his kind 
offer to donate his Struts-Examples application

http://www.ninsky.com/struts/

to Struts and the Apache Software Foundation.

The Struts-Examples application offers a number of very useful code 
samples. We can continue to grow the examples step-by-step over time and 
defray many of the requests on the list for code samples.

As part of refactoring the various Struts applications into a single 
application of several modules, we can also bring Steve's application on 
board as another module to "Struts-Docs".

-Ted.




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

Re: [PROPOSAL] Modular Struts Examples

[Vic Cekvenich]

-0.

Module was... is optional and confusing. I think delay this a point 
after 1.2.

I think struts-upload could be deprecated (along with bean and logic 
tags). People can do file upload out of commons, or using Jason Hunter's 
COS upload. etc. Upload is not a Struts core value and could go back to 
commons.

I would like for 1.2 to ... (can someone set up a "wish list" wiki 
please?) is repackage into 2 jars: Struts core, and other (taglibs), a 
few patches and a quick release. Also maybe Mavenize Struts build.

(after 1.2 consolidate actions and beans classes).

.V

Rob Leland wrote:
Ted Husted wrote:

I'd like to propose that we gather together the

struts-documentation,
struts-example (MailReader),
struts-exercise-taglib,
struts-upload,
struts-validator, and
tiles-documentation 


I am curretly -0 on this.
I don't like smashing --all-- the examples into one example simply
because it would be too much of a bite for new users to swallow.
Tiles already uses modules as part of it's documentation.
Having the :
struts-example (MailReader),
struts-upload,
struts-validator as a single application seem reasonable.
Perhaps we can structure them so they are both standalond and modules ?

-Rob


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

Re: [PROPOSAL] Modular Struts Examples

[Rob Leland]

Ted Husted wrote:

I'd like to propose that we gather together the

struts-documentation,
struts-example (MailReader),
struts-exercise-taglib,
struts-upload,
struts-validator, and
tiles-documentation 
I am curretly -0 on this.
I don't like smashing --all-- the examples into one example simply
because it would be too much of a bite for new users to swallow.
Tiles already uses modules as part of it's documentation.
Having the :
struts-example (MailReader),
struts-upload,
struts-validator as a single application seem reasonable.
Perhaps we can structure them so they are both standalond and modules ?

-Rob





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

[PROPOSAL] Wildcard-matched actions

[Don Brown]

Perhaps now that 1.1 is final, this would be a good time to bring this up.
I've written a small extension to Struts that allows action mappings to
use wildcards in matching URIs.  The matched values can then be
substituted anywhere in the action mapping - similar to how Cocoon
operates (in fact the wildcard code was copied from Cocoon).  The code
only affects the processActionMapping method of the RequestProcessor.

Why you ask?

 - Much smaller config files
 - Use of wildcards encourages more consistency of naming action forms,
actions, and jsp files.
 - Allows for noun-based URLs in addition to current verb-based URLS,
particularly useful in REST-style web services
 - No performance loss: wildcard matching only occurs when a direct
mapping for the URI cannot be found

For example:



  
  


By including this feature directly in Struts, wildcards would be available
to all Struts applications as opposed to now where wildcard support
requires a RequestProcessor extension.

For more information:

http://www.twdata.org/struts-wildcard/

Don


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

Re: [PROPOSAL] Modular Struts Examples

[David Graham]

I made a plea a while back for a module example app to test module
features in.  It looks like I may get my wish after all :-).

+1 but modules seem buggy at the moment so maybe we should fix those
problems first.

David

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> I'd like to propose that we gather together the
> 
> struts-documentation,
> struts-example (MailReader),
> struts-exercise-taglib,
> struts-upload,
> struts-validator, and
> tiles-documentation
> 
> webapps into a single "struts-docs" application, where each of the
> existing applications becomes a module. (Leaving the struts-blank out,
> since it is meant as a application template.)
> 
> At the same time, I would like to take Steve Raeburn up on his kind 
> offer to donate his Struts-Examples application
> 
> http://www.ninsky.com/struts/
> 
> to Struts and the Apache Software Foundation.
> 
> The Struts-Examples application offers a number of very useful code 
> samples. We can continue to grow the examples step-by-step over time and
> 
> defray many of the requests on the list for code samples.
> 
> As part of refactoring the various Struts applications into a single 
> application of several modules, we can also bring Steve's application on
> 
> board as another module to "Struts-Docs".
> 
> -Ted.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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

[PROPOSAL] Modular Struts Examples

[Ted Husted]

I'd like to propose that we gather together the

struts-documentation,
struts-example (MailReader),
struts-exercise-taglib,
struts-upload,
struts-validator, and
tiles-documentation
webapps into a single "struts-docs" application, where each of the
existing applications becomes a module. (Leaving the struts-blank out,
since it is meant as a application template.)
At the same time, I would like to take Steve Raeburn up on his kind 
offer to donate his Struts-Examples application

http://www.ninsky.com/struts/

to Struts and the Apache Software Foundation.

The Struts-Examples application offers a number of very useful code 
samples. We can continue to grow the examples step-by-step over time and 
defray many of the requests on the list for code samples.

As part of refactoring the various Struts applications into a single 
application of several modules, we can also bring Steve's application on 
board as another module to "Struts-Docs".

-Ted.



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

RE: [proposal]Adding queryString property to ForwardConfig

[Ias]

> -Original Message-
> From: Jeff Robertson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 25, 2003 10:41 PM
> To: 'Struts Developers List'
> Subject: RE: [proposal]Adding queryString property to ForwardConfig
> 
> > -Original Message-
> [...snip...]
> > In conclusion, you can take advantage of global forwards and
> > forwards in
> > actions with redirected parameters like
> >
> > ActionForward homeForward =
> > mapping.findForward("welcome");
> > homeForward.setQueryString("pid=" + pageSrno);
> >
> > Instead of
> > ActionForward homeForward = new
> > ActionForward("/portal/index.jsp?pid=" + pageSrno, true);
> >
> > If you like to get this proposal as a form of patches, I'm
> > willing to make
> > and submit them to bugzilla.
> 
> Have you considered a parameter/properties style interface to this?
> 
>   ActionForward homeForward = mapping.findForward("welcome");
>   homeForward.setParameter("pid", pageSrno);
> 
> Nobody really likes messing around with query strings.
> 

I understand that. I actually designed 3 methods:

ForwardConfig.setParameter(String name, String value);
ForwardConfig.setParameters(Map map);
ForwardConfig.setQueryString(String query);

However, I thought that the first two methods could be converted into the
last one, and moreover, setParameter method seemed like setAttribute, so it
also means that removeParameter may be necessary for handling parameters
more delicately. From that perspective, I made up my mind that it is enough
for my proposal to have one single method for setting parameters generically
without adding relatively too many methods.

> Btw, passing a parameter to a JSP like this almost always implies that the
> JSP contains more code that it ought to in an "MVC" application. You also
> said you were concerned about losing your beans when you do a redirect;
> but
> you really have no business redirecting to a JSP anyhow. If you can
> redirect
> to a JSP and have it work, that further implies too much logic in that
JSP.
> 

In contemporary Java web application development, "forward by dispatcher"
mechanism is preferred and recommended in most cases. However, sometimes it
is mandatory to choose redirection for users' sake. In this case, a JSP page
that has presentation logics (e.g. action tags for dynamic HTML rendering)
affected by a certain business logic in request scope needs an alternative
to obtain data from the business logic, and passing parameters is
essentially one (and maybe only) way for that. The reason why I suggested
the query getter-setter method is not to compensate the loss of beans from
redirection but to enable JSP to get information in an elegant manner with
Struts when redirection must be performed. To summarize, JSP may have as
many presentation logics dependent on results of business logics as needed,
and that's not inconsistent with MVC model in my humble opinion.

> With all of that out of the way, I could see your idea being useful for
> forwarding/redirecting from one Action to another.
> 

Thanks.

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


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

RE: [proposal]Adding queryString property to ForwardConfig

[Andrew Hill]

With all of that out of the way, I could see your idea being useful for
forwarding/redirecting from one Action to another.


I also tend to use forwards as a way of configuring in one place all the
urls that get rendered in various anchor tags etc in the view...

-Original Message-
From: Jeff Robertson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 March 2003 21:41
To: 'Struts Developers List'
Subject: RE: [proposal]Adding queryString property to ForwardConfig


> -Original Message-
[...snip...]
> In conclusion, you can take advantage of global forwards and
> forwards in
> actions with redirected parameters like
>
>   ActionForward homeForward =
> mapping.findForward("welcome");
>   homeForward.setQueryString("pid=" + pageSrno);
>
> Instead of
>   ActionForward homeForward = new
> ActionForward("/portal/index.jsp?pid=" + pageSrno, true);
>
> If you like to get this proposal as a form of patches, I'm
> willing to make
> and submit them to bugzilla.

Have you considered a parameter/properties style interface to this?

ActionForward homeForward = mapping.findForward("welcome");
homeForward.setParameter("pid", pageSrno);

Nobody really likes messing around with query strings.

Btw, passing a parameter to a JSP like this almost always implies that the
JSP contains more code that it ought to in an "MVC" application. You also
said you were concerned about losing your beans when you do a redirect; but
you really have no business redirecting to a JSP anyhow. If you can redirect
to a JSP and have it work, that further implies too much logic in that JSP.

With all of that out of the way, I could see your idea being useful for
forwarding/redirecting from one Action to another.

-
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: [proposal]Adding queryString property to ForwardConfig

[Andrew Hill]

+1
Now thats spooky. Before I read your msg I was outside having a smoke and
thinking along exactly the same lines!

ActionForwards have evolved into something of a generic URL wrapper class
for struts, and this change would be quite useful in this regard.

The way Id envisaged it was that you could set the query parameters in a
similar manner to those on a request:

ActionForward forward = mapping.findForward("editThing").clone();
forward.setQueryParameter("pid",pageSrno");
return forward;

In terms of elegance this seems nicer than what Im doing right now:
ActionForward forward = mapping.findForward("editThing").clone();
return new ActionForward( appendParam(forward.getPath,"pid",pageSrno),
forward.getRedirect());

This thought also lead to another thought:
ActionForwards whose path is specified in the form of another ActionForward
but whose parameters (& redirect etc...) can differ.

At the moment my struts config is full of 'redundant' forwards like:




It would be nice to use something like:


  


  


Then if the path needs to be changed I need only modify one forward...


-Original Message-
From: iasandcb [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 March 2003 20:33
To: [EMAIL PROTECTED]
Subject: [proposal]Adding queryString property to ForwardConfig


I tried to develop some application with Struts, and found that there was no
Struts-like way to handle ActionForward with query string, e.g.
index.jsp?pid=1. Mainly what I confronted was the following:

ActionForward homeForward = new
ActionForward("/portal/index.jsp?pid=" + pageSrno, true);

I needed to redirect to a URL, /portal/index.jsp with pid parameter.
Simultaneously, there was a global forward correspondent to the URL.



What I wanted to do is to avoid a hardcoded URL but use an appropriate
ActionForward from ActionMapping. For example,

ActionForward homeForward = mapping.findForward("welcome");
..
However, in this case it's not possible to attach a parameter in terms of
query string. (It is evident that you can use request.setAttribute for
passing data to JSPs, but when it comes to redirection, it's useless and
query string is necessary for the job.)

What I'd like to propose comes from a question, "What if ActionForward has
some property for query string?" For instance,

homeForward.setQueryString("pid=" + pageSrno);

actually means "/portal/index.jsp?pid=1" by combining the global forward and
a programmatic query string.

For implementing this feature, I added some codes to two classes:

In org.apache.struts.config.ForwardConfig

protected String queryString = null;

public String getQueryString() {
return (this.queryString);
}

public void setQueryString(String queryString) {
/*
This property can be set dynamically, so the freezing is not demanded.
if (configured) {
throw new IllegalStateException("Configuration is frozen");
*/
}this.queryString = queryString;
}

In org.apache.struts.action.RequestProcessor

protected void processForwardConfig(HttpServletRequest request,
HttpServletResponse response,
ForwardConfig forward)
throws IOException, ServletException {
...
// paths not starting with / should be passed through without any processing
// (ie. they're absolute)
if (forwardPath.startsWith("/")) {
uri = RequestUtils.forwardURL(request, forward);// get
module relative uri
} else {
uri = forwardPath;
}

// Newly added part-processing queryString
String queryString = forward.getQueryString();
if (queryString != null)
{
uri += "?" + queryString;
}

if (forward.getRedirect()) {
// only prepend context path for relative uri
if (uri.startsWith("/")) {
uri = request.getContextPath() + uri;
}
response.sendRedirect(response.encodeRedirectURL(uri));

} else {
doForward(uri, request, response);
}

}

In conclusion, you can take advantage of global forwards and forwards in
actions with redirected parameters like

ActionForward homeForward = mapping.findForward("welcome");
homeForward.setQueryString("pid=" + pageSrno);

Instead of
ActionForward homeForward = new
ActionForward("/portal/index.jsp?pid=" + pageSrno, true);

If you like to get this proposal as a form of patches, I'm willing to make
and submit them to bugzilla.

Ias

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
 

RE: [proposal]Adding queryString property to ForwardConfig

[Jeff Robertson]

> -Original Message-
[...snip...]
> In conclusion, you can take advantage of global forwards and 
> forwards in
> actions with redirected parameters like
> 
>   ActionForward homeForward = 
> mapping.findForward("welcome");
>   homeForward.setQueryString("pid=" + pageSrno);
> 
> Instead of 
>   ActionForward homeForward = new
> ActionForward("/portal/index.jsp?pid=" + pageSrno, true);
> 
> If you like to get this proposal as a form of patches, I'm 
> willing to make
> and submit them to bugzilla.

Have you considered a parameter/properties style interface to this?

ActionForward homeForward = mapping.findForward("welcome");
homeForward.setParameter("pid", pageSrno);

Nobody really likes messing around with query strings.

Btw, passing a parameter to a JSP like this almost always implies that the
JSP contains more code that it ought to in an "MVC" application. You also
said you were concerned about losing your beans when you do a redirect; but
you really have no business redirecting to a JSP anyhow. If you can redirect
to a JSP and have it work, that further implies too much logic in that JSP.

With all of that out of the way, I could see your idea being useful for
forwarding/redirecting from one Action to another.

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

[proposal]Adding queryString property to ForwardConfig

[iasandcb]

I tried to develop some application with Struts, and found that there was no
Struts-like way to handle ActionForward with query string, e.g.
index.jsp?pid=1. Mainly what I confronted was the following:

ActionForward homeForward = new
ActionForward("/portal/index.jsp?pid=" + pageSrno, true);

I needed to redirect to a URL, /portal/index.jsp with pid parameter.
Simultaneously, there was a global forward correspondent to the URL.



What I wanted to do is to avoid a hardcoded URL but use an appropriate
ActionForward from ActionMapping. For example,

ActionForward homeForward = mapping.findForward("welcome");
..
However, in this case it's not possible to attach a parameter in terms of
query string. (It is evident that you can use request.setAttribute for
passing data to JSPs, but when it comes to redirection, it's useless and
query string is necessary for the job.)

What I'd like to propose comes from a question, "What if ActionForward has
some property for query string?" For instance,

homeForward.setQueryString("pid=" + pageSrno);

actually means "/portal/index.jsp?pid=1" by combining the global forward and
a programmatic query string.

For implementing this feature, I added some codes to two classes:
 
In org.apache.struts.config.ForwardConfig

protected String queryString = null;

public String getQueryString() {
return (this.queryString);
}

public void setQueryString(String queryString) {
/*
This property can be set dynamically, so the freezing is not demanded.
if (configured) {
throw new IllegalStateException("Configuration is frozen");
*/
}this.queryString = queryString;
}

In org.apache.struts.action.RequestProcessor

protected void processForwardConfig(HttpServletRequest request,
HttpServletResponse response,
ForwardConfig forward)
throws IOException, ServletException {
...
// paths not starting with / should be passed through without any processing
// (ie. they're absolute)
if (forwardPath.startsWith("/")) {
uri = RequestUtils.forwardURL(request, forward);// get
module relative uri
} else {
uri = forwardPath;
}

// Newly added part-processing queryString
String queryString = forward.getQueryString();
if (queryString != null)
{
uri += "?" + queryString;
}

if (forward.getRedirect()) {
// only prepend context path for relative uri
if (uri.startsWith("/")) {
uri = request.getContextPath() + uri;
}
response.sendRedirect(response.encodeRedirectURL(uri));

} else {
doForward(uri, request, response);
}

}

In conclusion, you can take advantage of global forwards and forwards in
actions with redirected parameters like

ActionForward homeForward = mapping.findForward("welcome");
homeForward.setQueryString("pid=" + pageSrno);

Instead of 
    ActionForward homeForward = new
ActionForward("/portal/index.jsp?pid=" + pageSrno, true);

If you like to get this proposal as a form of patches, I'm willing to make
and submit them to bugzilla.

Ias

===
Lee, Changshin (Korean name)
Ias (International name)
   Company Web Site: http://www.tmax.co.kr
   Personal Web Site: http://www.iasandcb.pe.kr
-
Senior Researcher & Java Technology Evangelist
JCP member - http://jcp.org/en/participation/members/L
R&D Institute
Tmax Soft, Inc. 
JCP member - http://jcp.org/en/participation/members/T
==


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

Re: [PROPOSAL] Abstraction layer betwenn the httpServlet package and the action classes

[Emmanuel Feller]

Hi Vic,

I take a look to your class and it fill major part of my
proposal, but the struts engine is still http oriented.

So the action classes don't depend on httpservlet package
any more but you still can't process ftp or irc request.
That's why i proposed an enhancement of core engine.

Emmanuel
- Message d'origine -
De : "Vic Cekvenich" <[EMAIL PROTECTED]>
À : <[EMAIL PROTECTED]>
Envoyé : dimanche 16 mars 2003 16:12
Objet : Re: [PROPOSAL] Abstraction layer betwenn the
httpServlet package and the action classes


> I do something similar:
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/b
P/WEB-INF/src/war/org/apache/scaffoldingLib/base/BaseAct.jav
a
> See the execute has execute(ActionEvent ae) {} and a
dispatcher.
> This way people can add what ever they want to
Event/Context object and
> it's thread safe.
>
> As pointed out, it makes it easier to do non HTML, like
SOAP (included
> in Resin 3.1).
>
> YAAS (Yet Anoother Action Signature).
> .V
>




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

Re: [PROPOSAL] Abstraction layer betwenn the httpServlet packageand the action classes

[Vic Cekvenich]

I do something similar:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/bP/WEB-INF/src/war/org/apache/scaffoldingLib/base/BaseAct.java
See the execute has execute(ActionEvent ae) {} and a dispatcher.
This way people can add what ever they want to Event/Context object and 
it's thread safe.

As pointed out, it makes it easier to do non HTML, like SOAP (included 
in Resin 3.1).

YAAS (Yet Anoother Action Signature).
.V


Emmanuel Feller wrote:
Hello everybody,

I am still quiet newby in struts technologies, but i am
working on a mvc framework for 2years and when i started
2months ago using struts i was supprised : everytime i want
to push some information from my action classe to my jsp i
must take the request or the session.
So writing a struts application is not simple because it
need knowledge of servlet and jsp technologies.
I am hacking the code to add an abstraction layer, but i
prefer do a proposal before submit a patch. This is a better
way to standardize the API and to have a stable release more
quickly ... or to retake a good way if i am
miss-understanding.
I propose a sessionManager, which is a technical wrapper to
the session. It is able to take care of the mappings,
request and session.
I add three context :
a ViewContext, a HashMap, into which you push your data. So
you don't have to take back the request or session anymore.
The viewContext should be use to manage business data as
well as technicals ones ...
a ModuleContext, this is an intermediate level betwenn the
request scope and the session scope. information in
available only in the module where you are.
a SessionContext, this is a wrapper for session. Information
are available at any time in any module.
One advantage of the module is the segmentation of
information, so you can't have anymore conflict into 2
modules when you push data into the session object.
I also change the signature for the execute method :
ActionForm X (SessionManager, ViewContext,
ModuleContext, ActionForm)
I do not include the mapping because i am searching an issue
to make the navigation available to the developper : it
should be automatic and only in exception case do
redirection. (i don't have found the better way yet).
I have not inserted the name of the method because i propose
an enhancement into struts-config for action tag. We should
add a command tag, if it is present, the method called will
be the named, else it will be the standard execute method.
So when you have lots of action on a screen, it will not
need lots of action class, only bigger one ...
We are able to do the transformation with backward
compatibility, ie into 1.2 family, or into 2.0 family, as
you prefer. But it will need lots of modifications into
taglibs.
We can do the modification in 2 times, the first (into 1.2)
could be only the add of the new interfaces, and preserve
backward compatibility, the second one into 2.0 family could
be total refactor of the core request processing and also
add new transport protocol (ie ftp, soap, ... ) to make
struts open for new technologies as IRC services ;)) ...
I am waiting for your comments,

Regards,
Emmanuel Feller
Senior Developper
Cap Gemini Ernst & Young
+33 2 51 17 35 00 phone 3716
+33 6 23 34 63 39


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

[PROPOSAL] Abstraction layer betwenn the httpServlet package and the action classes

[Emmanuel Feller]

Hello everybody,

I am still quiet newby in struts technologies, but i am
working on a mvc framework for 2years and when i started
2months ago using struts i was supprised : everytime i want
to push some information from my action classe to my jsp i
must take the request or the session.

So writing a struts application is not simple because it
need knowledge of servlet and jsp technologies.

I am hacking the code to add an abstraction layer, but i
prefer do a proposal before submit a patch. This is a better
way to standardize the API and to have a stable release more
quickly ... or to retake a good way if i am
miss-understanding.

I propose a sessionManager, which is a technical wrapper to
the session. It is able to take care of the mappings,
request and session.
I add three context :
a ViewContext, a HashMap, into which you push your data. So
you don't have to take back the request or session anymore.
The viewContext should be use to manage business data as
well as technicals ones ...
a ModuleContext, this is an intermediate level betwenn the
request scope and the session scope. information in
available only in the module where you are.
a SessionContext, this is a wrapper for session. Information
are available at any time in any module.

One advantage of the module is the segmentation of
information, so you can't have anymore conflict into 2
modules when you push data into the session object.

I also change the signature for the execute method :
ActionForm X (SessionManager, ViewContext,
ModuleContext, ActionForm)

I do not include the mapping because i am searching an issue
to make the navigation available to the developper : it
should be automatic and only in exception case do
redirection. (i don't have found the better way yet).

I have not inserted the name of the method because i propose
an enhancement into struts-config for action tag. We should
add a command tag, if it is present, the method called will
be the named, else it will be the standard execute method.
So when you have lots of action on a screen, it will not
need lots of action class, only bigger one ...

We are able to do the transformation with backward
compatibility, ie into 1.2 family, or into 2.0 family, as
you prefer. But it will need lots of modifications into
taglibs.

We can do the modification in 2 times, the first (into 1.2)
could be only the add of the new interfaces, and preserve
backward compatibility, the second one into 2.0 family could
be total refactor of the core request processing and also
add new transport protocol (ie ftp, soap, ... ) to make
struts open for new technologies as IRC services ;)) ...

I am waiting for your comments,

Regards,
Emmanuel Feller
Senior Developper
Cap Gemini Ernst & Young
+33 2 51 17 35 00 phone 3716
+33 6 23 34 63 39



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

Code Proposal: Extend nested:text to allow dynamic sizing (Code Included)

[Michael McElwee]

This is my first code contribution to this forum. From information I 
received from the Struts web site, this seems to be the appropriate place 
to post; I apologize if it is not.

THE PROBLEM:

The tag:   allows you to pull 
the data for the text box from a bean property, but 
does not allow you to dynamically set the text box's size or maxlength 
from a property...you must either hard code them or use scriptlet syntax. 
In the solution I came up with for a project I am working on, the tag 
becomes:



where the bean in question pulls its size and maxlength from properties 
specified in the bean itself. This would be useful in many applications 
where fields, etc. are created dynamically. My code allows you to specify 
literal numbers for size and maxlength as well, where it will behave like 
it currently does. This idea could be extended to other nested tags as 
well to allow more dynamic behavior.

-
//THE SOLUTION:

package org.apache.struts.taglib.nested.html;

import javax.servlet.jsp.tagext.Tag;
import org.apache.commons.beanutils.BeanUtils;
import org.apache.struts.taglib.nested.NestedPropertyHelper;
import org.apache.struts.taglib.nested.html.NestedTextTag;
import org.apache.struts.util.RequestUtils;

public class ExtendedNestedTextTag extends NestedTextTag {
private String sz;
private String maxLen;

public ExtendedNestedTextTag () {
super();
}

public String getMaxlength() {
return maxLen;
}
 
public void setMaxlength(String property){
 
if(property == null)
return;
else if(property.charAt(0) >= '0' && 
property.charAt(0) <='9') //specifying a literal number
super.setMaxlength(property);
else{ //specifying a bean property
Object bean; 
try{
Tag parentTag = 
NestedPropertyHelper.getNestingParentTag(this); 
String propName = 
NestedPropertyHelper.getNestedProperty(property,parentTag);
 
bean = RequestUtils.lookup(pageContext, 
name, null);
this.maxLen = BeanUtils.getProperty(bean,propName);
super.setMaxlength(this.maxLen);
}catch(Exception e){
System.out.println("Exception: "+e);
}
}
}

public String getSize() {
return sz;
}
 
public void setSize(String property) { 
if(property == null)
return;
else if(property.charAt(0) >= '0' && 
property.charAt(0) <='9') //specifying a literal number
super.setSize(property);
else{ //specifying a bean property
Object bean; 
try{
Tag parentTag = 
NestedPropertyHelper.getNestingParentTag(this); 
String propName = 
NestedPropertyHelper.getNestedProperty(property,parentTag);
bean = RequestUtils.lookup(pageContext, 
name, null);
this.sz = BeanUtils.getProperty(bean,propName);
super.setSize(this.sz);
}catch(Exception e){
System.out.println("Exception: "+e);
}
}
}
}

-
Then, you would just need to change the text tag in the struts-nested.tld 
file so that it pointed to my class instead of NestedTextTag. Let me know 
what you think. If there is interest, I can document it better or make 
other additions/changes.

Thanks,
Michael McElwee

[proposal] Add Validating Two Fields to Validator (codeincluded)

[Raible, Matt]

I would like to propose that we add the validateTwoFields functionality to
the validator.  I don't have the source, so I can't submit a "true" patch,
but hopefully this e-mail will get the ball rolling.

Add this method, in my case it's in org.appfuse.webapp.util.ValidationUtil:

public static boolean validateTwoFields(Object bean, ValidatorAction
va,

Field field, ActionErrors errors,

HttpServletRequest request) {
String value =
ValidatorUtil.getValueAsString(bean,
field.getProperty());
String sProperty2 = field.getVarValue("secondProperty");
String value2 = ValidatorUtil.getValueAsString(bean,
sProperty2);

if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(),

Resources.getActionError(request, va, field));

return false;
}
} catch (Exception e) {
errors.add(field.getKey(),

Resources.getActionError(request, va, field));

return false;
}
}

return true;
}

Then in validation-rules.xml - add the following for server-side AND
client-side validation:

  
 
 
   
 
I haven't "thouroughly" tested this, but it's working for me on a
password/confirm password scenario.

Thanks,

Matt


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

RE: [PROPOSAL] Add Exception Handling to ActionForwards

[Hal Deadman]

The tiles:insert problem is discussed here
http://issues.apache.org/bugzilla/show_bug.cgi?id=13279

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 21, 2003 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Add Exception Handling to ActionForwards
> 
> 
> I tried implementing a simpler solution for Tiles controllers 
> by customizing 
> the RequestProcessor.  I discovered that the  
> tag also calls 
> the controller and just displays exceptions to the user.  I'm 
> a little 
> unsure about what to do at this point...
> 
> David
> 
> >I'll start with a specific situation:
> >Tiles allows you to configure a Controller class on a tile that gets 
> >executed whenever that tile gets used.  This is most 
> commonly used to 
> >prepare data for the tile from some datasource.  However, 
> the declarative 
> >exception handling feature does not apply to this, rendering 
> this Tiles 
> >feature fairly useless.
> >
> >The general feature idea:
> >The problem is that the RequestProcessor only invokes the exception 
> >handling mechanism on an Action's execute() method.  If we 
> extended this 
> >idea to handling exceptions from ActionForwards we could allow 
> >implementations to report errors that occurred while 
> forwarding and allow 
> >applications to recover gracefully.  As it is, I think a 
> ServletException 
> >get propagated up to the servlet.
> >
> >I believe the changes would include changing
> >RequestProcessor.processForwardConfig() throws IOException, 
> >ServletException
> >
> >to
> >
> >RequestProcessor.processForwardConfig() throws Exception
> >
> >and the 2 places that processForwardConfig() is called in 
> RequestProcessor 
> >would catch the Exception and pass it to processException().
> >
> >Thoughts?
> >David
> >
> >
> >
> 
> 
> _
> Tired of spam? Get advanced junk mail protection with MSN 8. 
> 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: [PROPOSAL] Add Exception Handling to ActionForwards

[David Graham]

I tried implementing a simpler solution for Tiles controllers by customizing 
the RequestProcessor.  I discovered that the  tag also calls 
the controller and just displays exceptions to the user.  I'm a little 
unsure about what to do at this point...

David

I'll start with a specific situation:
Tiles allows you to configure a Controller class on a tile that gets 
executed whenever that tile gets used.  This is most commonly used to 
prepare data for the tile from some datasource.  However, the declarative 
exception handling feature does not apply to this, rendering this Tiles 
feature fairly useless.

The general feature idea:
The problem is that the RequestProcessor only invokes the exception 
handling mechanism on an Action's execute() method.  If we extended this 
idea to handling exceptions from ActionForwards we could allow 
implementations to report errors that occurred while forwarding and allow 
applications to recover gracefully.  As it is, I think a ServletException 
get propagated up to the servlet.

I believe the changes would include changing
RequestProcessor.processForwardConfig() throws IOException, 
ServletException

to

RequestProcessor.processForwardConfig() throws Exception

and the 2 places that processForwardConfig() is called in RequestProcessor 
would catch the Exception and pass it to processException().

Thoughts?
David




_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

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

RE: [PROPOSAL] Add Exception Handling to ActionForwards

[David Graham]

I think reset is really only needed for checkboxes.  Why would you do 
database lookups in that method?  My proposal is focused on allowing 
RequestProcessor implementations to report errors when handling 
ActionForwards.

David



From: "Taylor, Jason" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Subject: RE: [PROPOSAL] Add Exception Handling to ActionForwards
Date: Thu, 20 Feb 2003 14:47:09 -0800

I remember avoiding reset() because any exceptions caused by DB interaction
couldn't be handled gracefully-- i.e., the exceptions would be thrown prior
to the execute() method.

This case seems to be another of the type addressed by this proposal-- am I
right?

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 20, 2003 12:30 PM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Add Exception Handling to ActionForwards
>
>
> I'll start with a specific situation:
> Tiles allows you to configure a Controller class on a tile that gets
> executed whenever that tile gets used.  This is most commonly used to
> prepare data for the tile from some datasource.  However, the
> declarative
> exception handling feature does not apply to this, rendering
> this Tiles
> feature fairly useless.
>
> The general feature idea:
> The problem is that the RequestProcessor only invokes the
> exception handling
> mechanism on an Action's execute() method.  If we extended
> this idea to
> handling exceptions from ActionForwards we could allow
> implementations to
> report errors that occurred while forwarding and allow
> applications to
> recover gracefully.  As it is, I think a ServletException get
> propagated up
> to the servlet.
>
> I believe the changes would include changing
> RequestProcessor.processForwardConfig() throws IOException,
> ServletException
>
> to
>
> RequestProcessor.processForwardConfig() throws Exception
>
> and the 2 places that processForwardConfig() is called in
> RequestProcessor
> would catch the Exception and pass it to processException().
>
> Thoughts?
> David
>
>
>
>
>
>
>
> _
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> http://join.msn.com/?page=features/virus
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail


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

RE: [PROPOSAL] Add Exception Handling to ActionForwards

[Taylor, Jason]

I remember avoiding reset() because any exceptions caused by DB interaction
couldn't be handled gracefully-- i.e., the exceptions would be thrown prior
to the execute() method.  

This case seems to be another of the type addressed by this proposal-- am I
right?

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 20, 2003 12:30 PM
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL] Add Exception Handling to ActionForwards
> 
> 
> I'll start with a specific situation:
> Tiles allows you to configure a Controller class on a tile that gets 
> executed whenever that tile gets used.  This is most commonly used to 
> prepare data for the tile from some datasource.  However, the 
> declarative 
> exception handling feature does not apply to this, rendering 
> this Tiles 
> feature fairly useless.
> 
> The general feature idea:
> The problem is that the RequestProcessor only invokes the 
> exception handling 
> mechanism on an Action's execute() method.  If we extended 
> this idea to 
> handling exceptions from ActionForwards we could allow 
> implementations to 
> report errors that occurred while forwarding and allow 
> applications to 
> recover gracefully.  As it is, I think a ServletException get 
> propagated up 
> to the servlet.
> 
> I believe the changes would include changing
> RequestProcessor.processForwardConfig() throws IOException, 
> ServletException
> 
> to
> 
> RequestProcessor.processForwardConfig() throws Exception
> 
> and the 2 places that processForwardConfig() is called in 
> RequestProcessor 
> would catch the Exception and pass it to processException().
> 
> Thoughts?
> David
> 
> 
> 
> 
> 
> 
> 
> _
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
> http://join.msn.com/?page=features/virus
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

[PROPOSAL] Add Exception Handling to ActionForwards

[David Graham]

I'll start with a specific situation:
Tiles allows you to configure a Controller class on a tile that gets 
executed whenever that tile gets used.  This is most commonly used to 
prepare data for the tile from some datasource.  However, the declarative 
exception handling feature does not apply to this, rendering this Tiles 
feature fairly useless.

The general feature idea:
The problem is that the RequestProcessor only invokes the exception handling 
mechanism on an Action's execute() method.  If we extended this idea to 
handling exceptions from ActionForwards we could allow implementations to 
report errors that occurred while forwarding and allow applications to 
recover gracefully.  As it is, I think a ServletException get propagated up 
to the servlet.

I believe the changes would include changing
RequestProcessor.processForwardConfig() throws IOException, ServletException

to

RequestProcessor.processForwardConfig() throws Exception

and the 2 places that processForwardConfig() is called in RequestProcessor 
would catch the Exception and pass it to processException().

Thoughts?
David







_
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus


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

Re: [Proposal] Migrate to Dependency on commons-resources

[David Graham]

Please post your patches (in diff -u format) to this ticket:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16792

Thanks!
David




From: Steve Peterson <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Thu, 06 Feb 2003 09:51:14 -0600

I'm wondering:

a) is it something the project would accept as a patch for 1.2

b) whether now is a good time to be working on it (I assume it is since 1.1 
is nearly complete and changes in that area look unlikely)

If the answer to a) or b) is no, I'm open to suggestions of other things to 
work on.  I have some time available now, have benefited from Struts, and 
would like to contribute.

Steve

At 08:16 AM 2/6/2003 -0700, David Graham wrote:
We'll be doing that for 1.2.

David




From: Steve Peterson <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED]
Subject: Re: [Proposal] Migrate to Dependency on commons-resources
Date: Thu, 06 Feb 2003 01:54:48 -0600

I'm looking at taking on (2) below as my first contribution to Struts.  
Let me know if you have any specific suggestions or don't think it's 
something that should be worked on right now.

S

At 06:34 PM 1/12/2003 -0800, Craig R. McClanahan wrote:
As we've discussed a couple of times, the last major functionality 
change
we had discussed for Struts 1.1 was to migrate to dependence on
commons-resources, rather than the proprietary message resource 
facilities
inside og.apache.struts.util.  As you might recall, Michael Schacter 
took
a first crack at factoring out the Struts resources classes out to 
create
this commons package, which is currently in the sandbox.

I've recently gone through it, and did a major refactoring of
commons-resources, to the point where I'm now ready to propose that we
modify Struts to depend on it.  I'd like the other committers to 
evaluate
the current state of commons-resources, and my proposed integration plan
below, to see what they think of this idea.

The nightly build of commons-resources.jar included in recent Struts
nightly builds is the code that I'm proposing.  You can see the Javadocs
for this code at:

  http://jakarta.apache.org/commons/resources/api/

and get the sources via either CVS (from jakarta-commons-sandbox) or
nightly snapshots:


http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/

In terms of Struts integration, I propose:

(1) Most Struts classes declare a static MessageResources instance
for the messages unique to that Struts package.  For example,
org.apache.struts.taglib.bean.CookieTag has this:

protected static MessageResources messages =
  MessageResources.getMessageResources
  ("org.apache.struts.taglib.bean.LocalStrings");

This would be migrated to the new Messages class from 
commons-resources:

protected static Messages messages =
  Messages.getMessages("org.apache.struts.taglib.bean");

The calls to actually retrieve message strings are compatible with
the existing code, as well as the properties files used to acquire
the message strings, so no other changes should be required.

(2) Convert o.a.s.u.MessageResources (and its friends) to wrappers
around equivalent functionality from commons-resources (much like
GenericDataSource now wraps commons-dbcp), and deprecate them.
This protects existing apps that are customizing these APIs,
but allows us to remove the o.a.s.u classes in a future version.

(3) Modify the  initialization element to allow
the selection and configuration of an appropriate
ResourcesFactory from commons-resources, wrapped by a Messages
instance.  This is primarily a change in the interpretation of
the "factory" attribute, and should not affect anyone that uses
the current default.

(4) Modify all internal uses (including in tag libraries) of
org.apache.struts.util.MessageResources to use
org.apache.commons.resources.Messages instead.  This will be
transparent to users that use the standard implementations, but
will require folks who have subclassed the MessageResources
classes to migrate their code as well.

What do you think?  Should we go ahead and do this migration?  Is the
commons-resources package as it stands now as complete and functional as
it needs to be (obviously, it'll need to be promoted to a standard 
Commons
package and released so we can rely on it, which will require a couple 
of
volunteers willing to help me maintain it).  Should we do the entire
migration outlined above, or maybe only part of it?

Thoughts, please.

Craig



--
To unsubscribe, e-mail:
<mailto:[EMAIL