Re: LookupDispatchAction doesn't lookup mapping
Dakota Jack wrote: On Tue, 07 Dec 2004 12:02:52 +0100, Alexander Czernay [EMAIL PROTECTED] wrote: The problem is, that only one of those buttons works, while the other throws a MissingResourceAction. That sounds like a typo, but the strange thing is, that it tries to lookup the button's value rather than it's name (eg. having a ressource mapping like mybutton.forward=go it would try to lookup go). I presume that you know that lookup dispatch action DOES lookup the buttons value rather than its name? I just mention this because your wording half indicates that you find this surprising. Jack Well, as far as I understand it, it takes the button value (eg. go) and tries to match it in Application.properties, where it should find mybutton.forward that it looks up in the getKeyMethodMap() inside the LookupDispatchAction. My problem is, that my application tries to lookup go rather than mybutton.forward for one button, while it works for the other. I double-checked all occurences of the lookup-string and also tried to rename it in case of some cruel naming conflict. It just doesn't work. Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatchAction doesn't lookup mapping
Dakota Jack wrote:
My experience is that the computer is always right, so I would look in
my properites file, if I were you, and see whether or not I had
reversed the myButtonForward=go to go=myButtonForward. Did you? I
feel compelled to reiterate that LookupDispatchAction is a fairly poor
example of the code needed to do this stuff, in my opinion.
Jack
I will definitely try your suggestion out, but before that, I wanted to
figure out, what I had done wrong using the LookupDispatchAction.
So now some direct copy paste from my code.
My ApplicationRessurces.properties looks like this:
snip
authors-form.button.forward = weiter
authors-form.button.back = zurück
/snip
The jsp:
snip
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.back//html:submit/html:form
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.forward//html:submit/html:form
/snip
And finally the Action-Map:
snip
protected Map getKeyMethodMap() {
Map map = new HashMap();
map.put(authors-form.button.create, create);
map.put(authors-form.button.edit, edit);
map.put(authors-form.button.remove, remove);
map.put(authors-form.button.forward, forward);
map.put(authors-form.button.back, back);
return map;
}
/snip
The back-button works, while the forward doesn't.
The LookupDispatchAction tries to call a method named weiter instead
of forward, while it calls the back-method as expected.
Alexander
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
LookupDispatchAction doesn't lookup mapping
I have a strange problem with LookupDispatchAction:
I built a form displaying several entries from a db as a list. There are
several buttons for editing/removing the entries an also two buttons for
paging though the list. The problem is, that only one of those buttons
works, while the other throws a MissingResourceAction. That sounds like
a typo, but the strange thing is, that it tries to lookup the button's
value rather than it's name (eg. having a ressource mapping like
mybutton.forward=go it would try to lookup go). All this works
perfectly well with my back-button on the same page, using the same action.
Any ideas?
Alexander
ApplicationRessources.properties:
# Form Labels
authors-form.button.create = Autor hinzufügen
authors-form.button.remove = Autor löschen
authors-form.button.edit = Autor bearbeiten
authors-form.button.list = Autoren auflisten
authors-form.button.forward = weiter
authors-form.button.back = zurück
list.jsp
%@ page language=java%
%@ taglib uri=http://jakarta.apache.org/struts/tags-bean; prefix=bean%
%@ taglib uri=http://jakarta.apache.org/struts/tags-html; prefix=html%
%@ taglib uri=http://jakarta.apache.org/struts/tags-logic;
prefix=logic%
logic:messagesPresent message=false
div class=error
html:messages id=msg message=false
bean:write name=msg filter=false/
/html:messages
/div
/logic:messagesPresent
logic:messagesPresent message=true
div class=status
html:messages id=msg message=true
bean:write name=msg filter=false/
/html:messages
/div
/logic:messagesPresent
div class=group
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.create//html:submit/html:form
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.back//html:submit/html:form
bean:write name=authorForm property=strutsPage/
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.forward//html:submit/html:form
/div
div class=group
table class=list
trthCommand/ththAuthor/th/tr
logic:iterate name=AUTHORS id=author indexId=author_id
trtdhtml:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.edit//html:submithtml:submit
property=submitbean:message
key=authors-form.button.remove//html:submithtml:hidden
property=id name=author//html:form/tdtdbean:write
name=author property=name/ - bean:write name=author
property=description//td/tr
/logic:iterate
/table
/div
div class=group
html:form action=/authors-listhtml:submit
property=submitbean:message
key=authors-form.button.create//html:submit/html:form
/div
AuthorsActionList.java
package de.sbow.struts.action.Authors;
import java.util.HashMap;
import java.util.Map;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.commons.beanutils.BeanUtils;
import org.apache.commons.logging.Log;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.actions.LookupDispatchAction;
import de.sbow.MSys.Authors.value.AuthorBeanValue;
import de.sbow.common.ServiceLocator;
import de.sbow.struts.form.AuthorEditForm;
import de.sbow.struts.model.AuthorModel;
/**
* @author Alexander
*
* The Struts action-class for presenting
* the Authors list.
*
*/
public class AuthorsListAction extends LookupDispatchAction {
private static Log log = ServiceLocator.getInstance().getLog(
AuthorsListAction.class);
/**
* Key method for mapping methods to buttons
*/
protected Map getKeyMethodMap() {
Map map = new HashMap();
map.put(authors-form.button.create, create);
map.put(authors-form.button.edit, edit);
map.put(authors-form.button.remove, remove);
map.put(authors-form.button.forwar,
forward);
map.put(authors-form.button.back, back);
return map;
}
/**
* Method create
* @param mapping
* @param form
* @param request
* @param response
* @return ActionForward
*/
public ActionForward create(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
// get form
AuthorEditForm authorForm = (AuthorEditForm) form;
// TODO check if this makes sense!
authorForm.reset(mapping, request);
log.debug(Forwarding to \authors create\.);
return mapping.findForward(create);
}
/**
* Method edit
Totally stuck handling forms
I'm still trying to find a nice way for handling standard list/create/edit/delete-forms... After browsing through all the hints and tips I got from here, I started building an initial form-setup-action using DispatchAction with a parameter dispatch that should be set to list, create, edit or delete, depending on the action wanted. That form-setup-action should pre-populate the form as needed and then forward to the apropriate action for display. There are two further actions; one for listing all existing entries (form-list-action, a LookupDispatchAction) and another for displaying an individual entry for editing (form-edit-action). Now I tried to stick it all together passing parameters around. But exactly that doesn't work as expected: On the list-form I present a list of all entries available together with submit-buttons for edit/delete-actions for each individual entry. There also is a single create button for creating new entries. Pressing the create-button invokes a create-method in the form-list-action that calls a forward named create. That forward points back to the form-setup-action with ?dispatch=create added to the path. The form-setup-action should then forward to the appropriate form-create-action, but it looks like the dispatch parameter isn't passed on to the form-setup-action. I wonder if this approach is ok or if there are better ones? How could the parameters be passed from one action to another (I couldn't find any parameter one could add to a forward-tag to pass paramaters that way. Thanks for your help, Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Searching pattern/best-practise for forms
Hollaway, Shedrick L CIV TRIREFFAC wrote: Alexander, This should help you understand applying DAO/DTO patterns in a Struts app: http://javaboutique.internet.com/tutorials/ApacheDAOs/ Shed. Thanks for all your replys and suggestions, but I'm afraid I didn't ask the right question. What I really wanted to know was, how you would organize the controller/view in Struts for handling those standard create/update/delete actions. Like you have a database containing an address-book in the backend and want to display it as a list to the user, so he can select entries for editing/deletion or create new ones. When creating/editing entries you would present those as a form, validate it and write it back to the backend. I've tried some ways to do this and ended up with three actions for one form: one for setting it up, one for displaying and validating it and one for the selected backend action. I just wonder if that is a good way or if I'm introducing some problems into my applications. Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Searching pattern/best-practise for forms
I'm searching for a pattern/best-practise for handling standard data-manipulation forms (like list, create, edit, update, delete functionality) in Struts. I've read about the CRUD (create/read/update/delete) pattern many times, but couldn't find any in-depth papers on it. Is there any recommended how-to/tutorial/paper on this? Thanks for your help, Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DynaValidatorForm 'forgets' request-attribute on redisplay after validation
I have a simple DynaValidatorForm
form-bean name=categoryForm
type=org.apache.struts.validator.DynaValidatorForm
form-property name=description type=java.lang.String /
form-property name=name type=java.lang.String /
form-property name=id type=java.lang.String /
form-property name=parent type=java.lang.String /
/form-bean
that is called whtin an action
action path=/categories-edit
attribute=categoryForm
input=msys.categories-edit
name=categoryForm
scope=request
validate=true
type=de.sbow.struts.action.Categories.EditAction
forward name=success path=/categories-edit-finish.do /
/action
that inserts so data into the request inside its execute method
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
// read CategoriesTree and put it into request scope
try {
CategoriesModel categories = new CategoriesModel();
request.setAttribute(Constants.CATEGORY_TREE,
categories.getCategories());
} catch (ApplicationException e) {
request.setAttribute(Constants.CATEGORY_TREE, null);
}
return mapping.findForward(success);
}
This works quite well during the form's initial display. But if I enter
wrong values so that the validation fails, the CATEGORY_TREE-attribute
is missing and thus the JSP-view fails.
Isn't the execute-method called again when the validation fails?
Anything else wrong here?
Thanks for any help,
Alexander
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaValidatorForm 'forgets' request-attribute on redisplay after validation
The problem is, that the given form actually edits the categories-tree and as it is presented to the user after editing it, it should be updated after the form is submitted. Alexander Joe Germuska wrote: Your action isn't executed if validation fails. However, the validation is performed on a second request, so the object placed into the scope before the form was presented is no longer there. If your categories are really relatively static, consider managing them in Application scope rather than request. I often have one or more plugins which initialize common menus like states and provinces or months of the year and place them into the application scope (I like to use the DigestingPlugIn). Your code doesn't look like there's anything particularly request-sensitive about the category tree. Some people make lists a property of the form itself. This is also one of the core use cases for some kind of view controller registered against the input forward's path, which is one of my goals to implement in a Struts 1.3.x timeframe. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Prepopulate a DynaForm
I'm trying to prepopulate a DynaForm with some values - right now just
hard-coded, later should be taken from a DB. For that I'm using a
SetupAction, that is called to prepopulate the form, insert it into the
request and after that forward to the actual action for presenting the
form to the user.
Looks like this:
public class MediaArchiveSetupAction extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response){
ActionServlet servlet = this.getServlet();
MediaArchiveForm mediaArchiveForm = new MediaArchiveForm();
mediaArchiveForm.setServlet(this.getServlet());
MessageResources messageResources = servlet.getInternal();
mediaArchiveForm.set(author, test);
// TODO: check why this doesn't work
request.setAttribute(mediaArchiveForm, mediaArchiveForm);
// this does actually work
request.setAttribute(test, dummy);
return (mapping.findForward(success));
}
}
Using this approach I always get a null pointer exception, leading me to
the presumption that the actual form-object isn't built.
Any ideas why?
Thanks for any help,
Alexander
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
