DO NOT REPLY [Bug 4929] - nested NullPointerException not defented with ignore="true"

[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=4929

nested NullPointerException not defented with ignore="true"

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
   Priority|Other   |Low



--- Additional Comments From [EMAIL PROTECTED]  2001-11-19 19:35 ---
Changed this to an enhancement request. The current documented functionality of 
the 'ignore' attribute relates to the bean identified by the 'name' attribute. 
This bugzilla entry essentially proposes extending this functionality to 
the 'property' attribute, in particular when nested properties are used.

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

DO NOT REPLY [Bug 4836] - org/apache/struts/util/LocalStrings message format wrong

[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=4836

org/apache/struts/util/LocalStrings message format wrong

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-11-19 19:24 ---
Fixed in 2001-11-20 build. Will be fixed in Struts 1.0.1.

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

Resources page for Struts 1.0.1

[martin . cooper]

I just checked in some updates to the Resources page for the main trunk.
While I was in there, I noticed that the Resources page that will be in
Struts 1.0.1 is quite different from the page in the main trunk. Is there
any reason I shouldn't just clone the main trunk page into the 1.0 branch,
so that 1.0.1 has the latest list?

--
Martin Cooper




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

DO NOT REPLY [Bug 4867] - Struts - User Guide - Consultants

[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=4867

Struts - User Guide - Consultants

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-11-19 19:01 ---
Fixed in 2001-11-20 build.

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

DO NOT REPLY [Bug 4875] - Change Entries for BravePoint on Resources Page

[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=4875

Change Entries for BravePoint on Resources Page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-11-19 19:01 ---
Fixed in 2001-11-20 build.

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

DO NOT REPLY [Bug 4864] - Add consultant

[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=4864

Add consultant

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-11-19 19:01 ---
Fixed in 2001-11-20 build.

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

Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

[Erik Hatcher]

> That was the reason, why I wrote that application resources also play an
> important role in your design.

Without a doubt - by design!  :)

>>If buttons move from one page to another  you'd have issues in your design
>>as well, unless each page is pointing to the same action - right?

> Sure, but only in jsp pages and struts-config, not in source code.

> Of cource not dynamically. But it is quite possible that some designer
> just wants to redesign pages and move part of functionality to another
pages.

I'd still have to see a real use-case for this as I think there are more
complex issues involved in a case where you're moving a button from one page
to another that are beyond the scope of our dispatch action discussions.
All forms mapping to the same generic dispatch action that you designed?
All the same type of form bean being handled?

Erik


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

Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

[Dimitri Valdin]

>For images I would put the image name in ApplicationResource.properties and
>use  - but I probably wouldn't go to that extreme
>until localization is needed.

That was the reason, why I wrote that application resources also play an
important role in your design.

>If buttons move from one page to another  you'd have issues in your design
>as well, unless each page is pointing to the same action - right?

Sure, but only in jsp pages and struts-config, not in source code.

>It is likely in our application that buttons will be enabled/disabled (by
>logic in the JSP to conditionally output them).  I would have to see a more
>concrete example of moving buttons from one page to another, as that has
>many other implications - is it a single ActionForm multi-page wizard-like
>form?  If not then why would buttons move from one action to another?

Of cource not dynamically. But it is quite possible that some designer
just wants to redesign pages and move part of functionality to another pages.

>Understandable - and could be accomplished in my design by having the
>dispatch go to methods, which then delegated its  handling to another action
>class.  I certainly do not advocate the same code in multiple places!  :)

I would not argue. It is possible in your design. There are always several
ways to achieve the same goal. But unfortunately we haven't got any feedback
until now ;-)

>I think there is a misunderstanding here about DispatchAction.

Sorry, I have really misunderstood this point.


Dmitri



--

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn 
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das 
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



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

Re: Using Digester class to poulate form data

[Craig R. McClanahan]

On Sat, 18 Sep 1999 [EMAIL PROTECTED] wrote:

> Date: Sat, 18 Sep 1999 23:48:02 +1100
> From: [EMAIL PROTECTED]
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Using Digester class to poulate form data
>
>
>
> hi all,
>
>Has anybody tried using digester class? My problem is that i have
> data in a xml file which should populate the data in the form. Can
> anybody throw a light on whether can i use the digester utility to
> parse the xml file and put the data in the corresponding class file.
>
> thanks in advance for any help, gitanjali.
>

If the nested elements in your XML document matches the structure of the
JavaBeans you wish to create, this is pretty easy.  In fact, Struts itself
uses this technique to process the struts-config.xml file, and turns
things like  elements into instances of the
org.apache.struts.action.ActionMapping bean class.  Look at the
initDigester() method to see how Struts sets this up.

In your case (populating an ActionForm instance), a couple of different
strategies are possible:

* Let Digester create the bean and then populate it for you,
  by including an "object create rule" and a "set properties
  rule".  You will also need a "set next" rule of some sort to
  maintain a reference to the object created by the "object create
  rule", because it will be removed from the stack at the end of
  the corresponding element.  (This is the approach that Struts
  uses when reading struts-config.xml, because it pushes the
  ActionServlet instance on the stack, and calls things like
  addMapping() to register a new ActionMapping instance.

* Precreate the bean with default properties, push it on
  to the Digester evaluation stack, and set up a Digester
  that only has a "set properties" rule.

The most important convention is that the attribute names in your XML
elements should match the property names in your JavaBeans.  That way, the
"set properties" rule can match them up automatically.

I'd start by reading the Digester documentation in the Struts User's
Guide, and play with some simple Digesters in stand-alone Java programs.
You will get the idea of how to use it pretty quickly.

Craig


>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

[Erik Hatcher]

> buttons.add & buttons.delete have to be defined, which is not obvious for
somebody
> who does not take care about internationalization. In fact I would define
the
> resources in any case. But what about images ? How do you want to handle
them ?

For images I would put the image name in ApplicationResource.properties and
use  - but I probably wouldn't go to that extreme
until localization is needed.

> Sure. It is a matter of taste. But perhaps not only. What would happen if
one
> day someone decides to move 2 from 5 submit buttons to another page ? Will
you
> rewrite the class ?

If buttons move from one page to another  you'd have issues in your design
as well, unless each page is pointing to the same action - right?

It is likely in our application that buttons will be enabled/disabled (by
logic in the JSP to conditionally output them).  I would have to see a more
concrete example of moving buttons from one page to another, as that has
many other implications - is it a single ActionForm multi-page wizard-like
form?  If not then why would buttons move from one action to another?

> Single action are also helpful, if you want to call them from several
places,
> say from context-menu or even through short cuts. I prefer to have all
actions
> defined in separate classes. But this is just my preference and I accept
> another solutions.

Understandable - and could be accomplished in my design by having the
dispatch go to methods, which then delegated its  handling to another action
class.  I certainly do not advocate the same code in multiple places!  :)


>> // Go back to input (any other ideas ?)
>> return new ActionForward(mapping.getInput());

>Ideas - How about returning ActionErrors if the mapping isn't found?  Or I
>personally would throw a JspException since this is truly a situation that
>cannot be handled wisely by the action in all cases and represents a
>situation that should not happen.

Yes. Throwing exception would be really better.

>In your design, struts-config.xml will have to be modified if a designer
>switches between using a graphic button and text buttons by adding or
>removing the ".x", or as in your example, name text buttons with ".x" on
>them - which I don't prefer.  My goals are to make the designers life as

I see no harm in this ".x" suffix, especially if you work with images.
But it is not the most nice in design for sure.

>>I don't think using DispatchAction as you suggest will work.  What it
>>would do in the "add" case is this:
>>- call request.getParameter("add") - what would that return in your case?

> Sure. It won't work if you don't add ".x" suffix ;-)

I think there is a misunderstanding here about DispatchAction.
request.getParameter("add.x") would return the coordinates where the user
clicked (if it was an .  Then DispatchAction would try to find a
method by that name - and I definitely don't think you'll name methods for
each X-coordinate for an image! :)

DispatchAction dispatches to the method named by the result of getParameter,
and gets the parameter name from struts-config.  Another level of
indirection is what is accomplished by my LookupDispatchAction (and your
first solution).

So, where does that leave us with the variants of DispatchAction?  Besides
Dmitri's feedback, anyone else have opinions on it?

Erik



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

Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

[Dimitri Valdin]

Erik,

>I don't understand what you mean by application properties playing a role.
>How so?

buttons.add & buttons.delete have to be defined, which is not obvious for somebody
who does not take care about internationalization. In fact I would define the
resources in any case. But what about images ? How do you want to handle them ?

>Definitely an interesting indirection mapping scheme... but that means that
>every form there is an action mapping, and another action class and mapping
>for each button on the form.  struts-config.xml will already be huge in our
>application of hundreds of forms, so having a single mapping per form is
>important not only to keep the config smaller, but to keep it clearer.

Sure. It is a matter of taste. But perhaps not only. What would happen if one
day someone decides to move 2 from 5 submit buttons to another page ? Will you
rewrite the class ?
Single action are also helpful, if you want to call them from several places,
say from context-menu or even through short cuts. I prefer to have all actions
defined in separate classes. But this is just my preference and I accept
another solutions.


>> // Go back to input (any other ideas ?)
>> return new ActionForward(mapping.getInput());

>Ideas - How about returning ActionErrors if the mapping isn't found?  Or I
>personally would throw a JspException since this is truly a situation that
>cannot be handled wisely by the action in all cases and represents a
>situation that should not happen.

Yes. Throwing exception would be really better.

>In your design, struts-config.xml will have to be modified if a designer
>switches between using a graphic button and text buttons by adding or
>removing the ".x", or as in your example, name text buttons with ".x" on
>them - which I don't prefer.  My goals are to make the designers life as

I see no harm in this ".x" suffix, especially if you work with images.
But it is not the most nice in design for sure.

>I don't think using DispatchAction as you suggest will work.  What it
>would do in the "add" case is this:
>- call request.getParameter("add") - what would that return in your case?

Sure. It won't work if you don't add ".x" suffix ;-)

>>   
>> or
>>   

>I think this kind of mapping puts unnecessary stuff in an already cluttered
>struts-config.xml file.  Having a subclass of my LookupDispatchAction to

Absolutely agree with you. I also prefer to 'misuse' forwards ;-)

Thank you for your feedback.

Dmitri




--

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn 
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das 
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the 
intended recipient (or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorized copying, disclosure or 
distribution of the material in this e-mail is strictly forbidden.



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

DO NOT REPLY [Bug 4744] - Allow Secure Form Submittal with tag

[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=4744

Allow Secure Form Submittal with  tag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows NT/2K   |All

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

SV: Using Digester class to poulate form data

[Mikkel Bruun]

Yes, you could use the digester for that...

look at the documentation (its now in the commons project i believe)

Mikkel

> -Oprindelig meddelelse-
> Fra: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]]
> Sendt: 18 September 1999 14:48
> Til: [EMAIL PROTECTED]
> Emne: Using Digester class to poulate form data
> 
> 
> 
> 
> hi all,
>Has anybody tried using digester class? My problem is that 
> i have data in a
> xml file which should populate the data in the form. Can 
> anybody throw a light
> on whether can i use the digester utility to parse the xml 
> file and put the data
> in the corresponding class file.
> thanks in advance for any help,
> gitanjali.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

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

Using Digester class to poulate form data

[Gitanjali_Singh]

hi all,
   Has anybody tried using digester class? My problem is that i have data in a
xml file which should populate the data in the form. Can anybody throw a light
on whether can i use the digester utility to parse the xml file and put the data
in the corresponding class file.
thanks in advance for any help,
gitanjali.




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

Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons

[Erik Hatcher]

Dmitri,

> you solution is very interesting, but I am not absolutely happy with the
> fact,
> that control is specified not only in struts-config.xml but in source code
> as well (map definition).

I don't think my solution takes control away from struts-config, it only
gives the action more control over how it handles things directed towards
it.

> Even application properties play here an important
> role.

I don't understand what you mean by application properties playing a role.
How so?

More comments in-line below

> I have tried to use your ideas and produced very simple solution which
would
> satisfy
> both buttons and images needs.
>
> struts-config.xml
> =
>
> type="org.apache.struts.actions.MultiSubmitAction"
>name="testForm"
>   scope="request"
>   input="/test.jsp">
>   
>   
> 

Definitely an interesting indirection mapping scheme... but that means that
for
every form there is an action mapping, and another action class and mapping
for each button on the form.  struts-config.xml will already be huge in our
application of hundreds of forms, so having a single mapping per form is
important not only to keep the config smaller, but to keep it clearer.

Your solution does accomplish the multi-button issue by naming each button
uniquely.  I feel more comfortable with each button having the same name,
but I suppose that is a matter of preference (and as such is accounted for
in the two base classes I'm proposing).  In your case you'd have to be
careful not to have a property of your form bean with the same name as any
of the button names - in my design you'd just have to make sure not to have
one form bean property (i.e. "action").

> MultiSubmitAction.java
> ==
>
> public class MultiSubmitAction extends Action {
>
> public ActionForward perform(ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException {
>
> String forwards[] = mapping.findForwards();
>
> for (int i = 0; i < forwards.length; i++) {
> if (request.getParameter(forwards[i]) != null) {
> // Return the required ActionForward instance
> return mapping.findForward(forwards[i]);
> }
> }
>
> // Go back to input (any other ideas ?)
> return new ActionForward(mapping.getInput());

Ideas - How about returning ActionErrors if the mapping isn't found?  Or I
personally would throw a JspException since this is truly a situation that
cannot be handled wisely by the action in all cases and represents a
situation that should not happen.

> Some considerations:
>
> If you never intend to use images, then you can omit ".x" suffix.

In your design, struts-config.xml will have to be modified if a designer
switches between using a graphic button and text buttons by adding or
removing the ".x", or as in your example, name text buttons with ".x" on
them - which I don't prefer.  My goals are to make the designers life as
easy and straightforward as possible, and having text buttons named ".x"
just doesn't make a lot of sense without knowing whats going on under the
hood.  A designer shouldn't have to care what is going on under the hood.

> If somebody wants to have all methods stored in one file he can subclass
> DispatchAction
> and play with parameter property:
>
> type="org.apache.struts.webapp.example.AddDeleteAction"
>name="testForm"
>   parameter="add"
>   scope="request"
>   input="/test.jsp">
> 
>
> type="org.apache.struts.webapp.example.AddDeleteAction"
>name="testForm"
>   parameter="delete"
>   scope="request"
>   input="/test.jsp">
> 

I don't think using DispatchAction as you suggest will work.  What it
would do in the "add" case is this:

- call request.getParameter("add") - what would that return in your case?
The text of the button.

- Then it would attempt to look up a method named the text of the button.
This is not a very plausible scenario because the button labels need to be
separated from the action, and not considered (directly), and of course its
unlikely you'd name your methods appropriately, since you couldn't have a
method named "Add Record" but that is a very likely button text.

Maybe I'm missing a piece of your design here, but the parameter value used
in DispatchAction uses a level of indirection that I don't see being
accounted for here.

> Instead of 'misusing' mappings it might be possible to introduce some
> additional tag
> to action config:
>
>   
> or
>   

I think this kind of mapping puts unnecessary stuff in an already cluttered
struts-config.xml file.  Having a subclass of my LookupDispatchAction to
control what happens for each button seems the right place to put that