[OT] Ping

[James Mitchell]

Sorry, just testing if Yahoo will let me send this from web-based mail using my apache 
address as
"from".

Ted, Craig, whoever, please let me know if this message hangs in the queue.

James Mitchell

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

Re: javadoc patches

[James Holmes]

We most definitely accept patches.  The more the merrier.

Note, you should open a Bugzilla ticket to attach the patches to instead
of sending the patches to this list.  That way we don't lose track of
them.

-James

> I use javadoc a lot, as with most java developers.  When I use the
> struts javadocs, I don't feel that I get all the information I need.  A
> lot of times I need to look at the source.  In short: will you accept
> patches to improve that javadoc?
>
> -Trav
>
>
> - 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]

DO NOT REPLY [Bug 22189] New: - Animated GIF freezing

[bugzilla]

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

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

Animated GIF freezing

   Summary: Animated GIF freezing
   Product: Struts
   Version: 1.0 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It appears that when you submit to an Action class, any animated .gif files 
that you have on the page freeze up.  I've tried every way I can think of to 
work around this bug (layers, iframes, etc.) to no avail.  What could be 
causing this?

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

Re: Module Inheritance Revisited

[Joe Germuska]

Matt:

This does sound like kind of an abuse of modules (if you'll pardon the term...)

Shouldn't all of that structure be a layer separate from Struts?  It 
seems to me as if "knowledge items" should be part of your data 
model, not tangled up in Struts/Controller-View structures.

Further, I would suggest that if you are going to have trouble 
"finding actions after a few days" then maybe you're using actions in 
a very... er, idiomatic way?

I think Struts is very flexible, and I think it's great to try to 
make it more so, and I won't even say that it's foolish to hope that 
Struts could be as flexible as to fit your model -- but wooo-eee, 
you're pushing it to the limit!  I'm hearing Mr. Scott... "she canna 
take no more, Cap'n!"

Joe

At 16:58 -0400 8/6/03, Sgarlata Matt wrote:
Found the thread...

http://www.mail-archive.com/[EMAIL PROTECTED]/msg08910.html

So 1.1 is out now, and people are using Struts modules.  Someone said they
wanted to hear how Struts users use 1.1 with modules, so here goes.  I think
Craig will cringe if he reads this ;)  The application I work on is a
knowledge management application with many different developers working on
it.  Each "knowledge item" in the application gets its own module (let's
call it a "knowledge module").  For example, a knowledge item might be a
"document", or a "project".  There are also "functional modules", such as
"related links" or "data access" which allow the user to relate a document
to a project, or assign access rights to a knowledge item, respectively.
The knowledge modules are pretty self-contained.  The functional modules get
pretty tricky to implement since they want to access stuff in the knowledge
modules.  For example, when you link a document to a project you want to
start from the document and then search for the project using the standard
search interface for projects.  This means some tricky routing to different
modules.
So if I'm having all this difficulty with functional modules, why bother
with modules at all and not just make the entire application one module?
Well, here is the reasoning I've used:
- Each module is in its own directory and each module has few files
associated with it, so a junior programmer can get familiar with all the
files for a single module and feel like he or she "knows" that module.
- There is less source control contention for configuration files because
few changes need to be made to the web.xml file and the default
struts-config file.
- Module information is grouped together logically, and there is no way to
mess it up.  Ideally if we had one struts-config file people would group
things logically by module, but the reality is people are lazy and will (for
example) just put their newest  element at the end of the
 and it will be impossible to find  after a few
days.
- All the files for a module can be easily copied to another application and
customized for that application's needs because they are grouped together
(the JSPs have their own directory, and the complete configuration for the
module is in the WEB-INF directory).
Well I'm about out of reasons, maybe I was just using modules because they
were there ;)  Honestly if I was the only person working on the project, the
added complexity of modules wouldn't be worth it and I would just use a
single module.
Matt
- Original Message -
From: "Robert Leland" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 06, 2003 4:14 PM
Subject: Re: Resource Bundle Prototyping

 adam kramer wrote:

 >On Wed, 6 Aug 2003, Joe Germuska wrote:
 >
 >
 >>I'm pretty sure this was an explicit design intention, although the
 >>main reason may have been to make backwards compatibility more
 >>manageable (or maybe not -- I can't cite any place where this was
 >>discussed; I just have vague recollections).  From reading the lists,
 > >>it's clear that many people intuitively expect modules to be less
 >>walled off from each other.
 >>
 >>Maybe a smarter Modularization, but one which might break some
 >>compatibility, could be targetted for a 1.5 release, or some
 >>mid-point between 2.0, which has a lot of bigger changes marked for
 >>it.
 >>
 >>
 >
 > I am going to make an effort to look through the archives and find the
 >reasoning behind the design of the current modules (unless someone out
 >there can enlighten us all). And explore the code and docs to come up
with
 >some ideas for application-wide module features that won't break struts
 >conventions, etc... The modules would be much more useful to me if they
 >had a concept of "application" and module.
 >
 >
 There were some thoughts about module inheritance that were discussed
 last summer.
 To my knowledge though no real design work has been done. It does seem
 that resource
 inheritance is the #1 requested feature.  There may be a Bugzilla
 enhancement request ticket
 on this.
 -Rob

 >-adam k.
 >
 >
 >
 >---

DO NOT REPLY [Bug 22190] - TLD packaging description refers to wrong specification.

[bugzilla]

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

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

TLD packaging description refers to wrong specification.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:17 ---
For simplicity, we only note differences between Servlet 2.2 and 2.3.  Many 
users don't know what level of Servlet they're using and even less know what 
version of JSP they're using.

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

DO NOT REPLY [Bug 21679] - Map-backed ActionForms - multiple select - object value conversion

[bugzilla]

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

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

Map-backed ActionForms - multiple select - object value conversion

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:55 ---


*** This bug has been marked as a duplicate of 17698 ***

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

DO NOT REPLY [Bug 22191] New: - Map-backed form property and multiselect.

[bugzilla]

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

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

Map-backed form property and multiselect.

   Summary: Map-backed form property and multiselect.
   Product: Struts
   Version: 1.1RC2
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I use multiselect and map-backed propoerties :
stanowisko1 
stanowisko2 

private Map values = new HashMap() ;
public void setValue( String key, String[] val ) {
.
}
public String[] getValue(String key) {
..
}

I doesn`t work . setValue is never called.

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

DO NOT REPLY [Bug 21254] - nested:messagePresent tag does not append parent name to indexed property

[bugzilla]

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

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

nested:messagePresent tag does not append parent name to indexed property





--- Additional Comments From [EMAIL PROTECTED]  2003-08-06 23:56 ---
Created an attachment (id=7679)
Patch file changing interface for NestedMessagesPresentTag

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

DO NOT REPLY [Bug 17698] - The value(key) form name pattern doesn't work with

[bugzilla]

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

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

The value(key) form name pattern doesn't work with 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:55 ---
*** Bug 21679 has been marked as a duplicate of this bug. ***

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