Re: FW: Struts help
I think the your problem might be relative paths. If you are using the base tag html:base /, your relative path will start from context-root/jsp. If your css file is included in your page using a relative path, your css file must be in the /jsp directory. LINK rel=stylesheet href=style.css type=text/css In WSAD, you can locate your jsp's in folder under the WebContent and assign other url mappings in your web deployment descriptor, like /Test1.jsp where they acually live in WebContent/jsp/. In WSAD, this mapping will effect the value of the html:base tag, where in tomcat, the mapping doesn't seem to have the same effect. We are using tiles and ended up just placing our layouts in the base WebContent folder so that we have the option of using tomcat if we don't want to wait 5 minutes for WAS to load :-) The virtual host mapping in WAS has to do with the domain name as it relates to the webserver plugin. You can use the virutal host name to channel a request to a specific WAS server or cluster of WAS servers. For example, you might not have an internal verses external network but you have applications you want to make avaliable internally only. You could create a domain name like www.acme.internal, register it with your internal DNS. Then install your application to this virtual host mapping www.acme.internal:80. The default virtual host mapping is *:80. I think your error is related to how WSAD handles url mapping to jsp resources as it relates to the html:base / tag. Gary Hi, I am using struts with WSAD for creating my web application. I have a jsp page which intern calls a css file and displays images also. when I call my jsp: , test1.jsp, the page displays fine and I can see the i,ages and the css file also takes effect. Now, I added an action mapping, updateAction in my struts config file action-mappings action name=update path=/update scope=request type=com.test.testweb.actions.UpdateAction forward name=success path=/jsp/Test1.jsp /forward /action /action-mappings Here, when I added the action mapping, I am forwarding to the same page, test1.jsp after a success. ie, my form is getting submitted and I am coming to the same page. But when the same page gets displayed again, the images are not getting displayed and its not recognising the css file. My console gives the following errors: [3/19/04 9:16:40:408 CST] 154a763c OSEListenerDi E PLGN0021E: Servlet Request Processor Exception: Virtual Host/WebGroup Not Found : The web group /images/logo.gif has not been defined Why is this happening ? Do I need to add anything so that the images and css files are recognised from an action link ? Thanks Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
At 11:29 PM -0500 1/15/04, Ted Husted wrote: My only comment is that it seems we're throwing a lot of technology at a problem that could be solved by putting an empty DynaActionForm in the Struts config, and just referring to that. Perhaps something like: form-bean name=buttonForm type=org.apache.struts.action.DynaForm / That doesn't solve the problem if you want to use html:input tags when you haven't created the form-beans yet. That's kind of a corner case, but we are gradually getting non-developers who can write JSPs and tags ok but haven't yet learned struts-config syntax. Eventually I hope that they will, and then this might not be so important. From the writ, page 172? My favorite romance novel :) form-bean name=buttonForm type=org.apache.struts.action.DynaForm form-property name=value type=java.util.TreeMap / /form-bean html:text propety='value(key)'/ bean:write name=buttonForm property='value(key)' / I still prefer to err on the side of permissiveness -- a blank form rather than a stack trace. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: why are form beans required for html:form?
I think this is a great idea. We often use buttons on the form for navigation between inquiry/dispaly pages which requires that we use a default formbean. Maybe you could add the attributre to the action noded of the struts config file instead of making it a custom tag attribute? This would allow you to let the request processor do the check and instantiate a base/dummy action form. Then you wouldn't have to refactor the tag libraries? I suppose this might sound like a kluge. Gary VanMatre -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 7:09 AM To: Struts Developers List Subject: RE: why are form beans required for html:form? At 8:59 PM -0700 1/14/04, Richard Hightower wrote: how about another attribute, i.e., html:form checkFormBean=false ... The checkFormBean defaults to true so it is backwards compatible with other versions. I like the idea that html:form checks for the form bean. It makes it easier to debug the way it is. However, I can see when you would not want that Well, I'm figuring that if you actually NEED the form bean, then something else would throw an exception; presumably the first input tag which isn't backed by some explicitly named bean. I'd probably leave out the parameter in preference of error checking at the right spot. I think what Ted was getting at in his email was that other tags might not be doing good error checking because they've always deferred to html:form -- and yes, it would be bad to remove the check and then start having NPEs thrown that might be much harder to debug. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
We have a solution for dynamic page content that is component based. I wouldnt say that it stands up to JSF but its similar in concept. The content of the page is defined using xml metadata. However, I suppose that you could argue, why not use JSF? I would be interested in hearing what advantage you would have using struts with JSF when JSF handles both the view layer and controller? Consider the following DTD and XML snippet: !ELEMENT display-element (attribute*, set-property*) !ATTLIST display-element displayElementId CDATA #REQUIRED type %DisplayElementType; #IMPLIED jspName CDATA #IMPLIED extends CDATA #IMPLIED modelClassname CDATA #IMPLIED roles CDATA #IMPLIED useContainerNaming %Boolean; #IMPLIED !ELEMENT set-property (#PCDATA) !ATTLIST set-property name CDATA #REQUIRED value CDATA #REQUIRED !ELEMENT attribute (set-property*) !ATTLIST attribute attName CDATA #IMPLIED displayName CDATA #IMPLIED displayElementId CDATA #REQUIRED requiredField %Boolean; #IMPLIED sequence CDATA #REQUIRED roles CDATA #IMPLIED useContainerNaming %Boolean; #IMPLIED This is an example of building a change password page. The changePasswdForm is the root component. !-- The crudForm definition serves as a base layout for an add or update page -- display-element displayElementId=crudForm !-- will always be placed on the bottom of the form, sequence=99 -- attribute displayElementId=Message displayName=message.required.legend sequence=99/ /display-element !-- The changePasswdForm definition only allows you to change your password. It inherits the required message legend from the crudForm -- display-element displayElementId=changePasswdForm extends=crudForm !-- include the user password fields also used by the addUserWidget -- attribute displayElementId=userPasswdWidget sequence=1/ !-- The rest of the user information is cached in the html form allowing the update handler to be reused for the change password page -- attribute attName=cmManagerId displayElementId=Text sequence=10 set-property name=isHidden value=true/ /attribute attribute attName=cmFname displayElementId=Text sequence=11 set-property name=isHidden value=true/ /attribute attribute attName=cmMname displayElementId=Text sequence=12 set-property name=isHidden value=true/ /attribute attribute attName=cmLname displayElementId=Text sequence=13 set-property name=isHidden value=true/ /attribute /display-element !-- The userPasswordWidget is included by the userAddWidget and The changePasswdForm. -- display-element displayElementId=userPasswdWidget attribute attName=cuPassword displayElementId=Text displayName=cuPassword.display sequence=1 requiredField=true set-property name=size value=15/ set-property name=maxlength value=15/ set-property name=isPassword value=true/ /attribute attribute attName=retypePassword displayElementId=Text displayName=retypePassword.display sequence=2 requiredField=true set-property name=size value=15/ set-property name=maxlength value=15/ set-property name=isPassword value=true/ /attribute /display-element At 3:47 PM + 12/19/03, PILGRIM, Peter, FM wrote: Having spoken with Don Brown, I can see the benefits now of the BeanWrapper and the [Xml]BeanFactory in Spring. Creating a graph of objects from an XML file is pretty handy for certain situations. I can see the light of the joke. Objects just Spring into life from literal paper. I guess the decision here will be political. Can we just take or borrow the org.springframework.beans.* of your framework? Hmmm. The thing that looks attractive to me in Spring is the ability to make a graph of objects more complicated than a tree. It would be possible to do this in Digester, without necessarily even writing custom rule classes. As for PicoContainer, if someone could just show me how you write an external configuration file that wires together objects through their constructors, I might buy it, but it just doesn't seem to match up. As soon as you had one new collaborator that you hadn't planned for, you'd have to rewrite some java code somewhere, wouldn't you? That's another facet of Spring that appeals to me -- it's orientation towards JavaBean conventions -- but we can achieve that with homegrown processes using (or at least inspired by) Digester if we're reluctant to pile on Spring. If Spring uses an Apache license, then politics or not we can use the code just about anyway we like, but I don't know that we need to read the Spring code to achieve the few things that seem most useful to me. I still haven't found the time to really dig into the various microkernel/IoC type frameworks yet, so I hope I'm not just blowing
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 11:00 AM To: Struts Developers List Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) Quoting [EMAIL PROTECTED]: We have a solution for dynamic page content that is component based. I wouldn't say that it stands up to JSF but it's similar in concept. The content of the page is defined using xml metadata. However, I suppose that you could argue, why not use JSF? I would be interested in hearing what advantage you would have using struts with JSF when JSF handles both the view layer and controller? Fair question. In the long run, we (Struts) are definitely going to have to compete with this combination. The easiest way is to focus on features that are not present in JSF -- one approach would be to build on top of the JSF controller infrastructure. Besides the UI components, there are some very useful foundational things there (such as managed beans, which generalize the way that Struts auto-creates form beans on demand, fine-grained navigation rules, and the ability to programmatically evaluate EL-ish expressions, including the ability to plug in new evaluators for the . operator) that would be nice to use in a controller tier. I have been struggling to correlate the notion of a struts formbean with a jsf UI component. Under struts, a single action can be associated with only one formbean. If the form is a composition of many components, should each component have its own formbean? It sounds as each jsf component would pull values on its own behalf from the request parameters thru a converter. To achieve visual component reuse, it sounds like jsf introduces the notion of a client id. We have used an underscore as our component delimiter because the beanutils handles the . for nested components. It seems that if you had a single form bean to map to a graph of UI components, the form bean might get kind of ugly. form-bean name=AboutForm type=com.rustts.action.DynaRusttsForm form-property name=aboutForm_BorderLayout_west_dateWidget_selDate type=java.lang.String/ form-property name=aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year type=java.lang.String/ form-property name=aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month type=java.lang.String/ /form-bean It would be nice if the behavior of the formbean to an aciton could also be associated with a UI component. It sounds like the struts chains will be similar to the jsf component tree? Could a chain command be associated with a individual formbean and a command be corrolated to a UI component? Consider the following DTD and XML snippet: !ELEMENT display-element (attribute*, set-property*) !ATTLIST display-element displayElementId CDATA #REQUIRED type %DisplayElementType; #IMPLIED jspName CDATA #IMPLIED extends CDATA #IMPLIED modelClassname CDATA #IMPLIED roles CDATA #IMPLIED useContainerNaming %Boolean; #IMPLIED !ELEMENT set-property (#PCDATA) !ATTLIST set-property name CDATA #REQUIRED value CDATA #REQUIRED !ELEMENT attribute (set-property*) !ATTLIST attribute attName CDATA #IMPLIED displayName CDATA #IMPLIED displayElementId CDATA #REQUIRED requiredField %Boolean; #IMPLIED sequence CDATA #REQUIRED roles CDATA #IMPLIED useContainerNaming %Boolean; #IMPLIED This is an example of building a change password page. The changePasswdForm is the root component. !-- The crudForm definition serves as a base layout for an add or update page -- display-element displayElementId=crudForm !-- will always be placed on the bottom of the form, sequence=99 -- attribute displayElementId=Message displayName=message.required.legend sequence=99/ /display-element !-- The changePasswdForm definition only allows you to change your password. It inherits the required message legend from the crudForm -- display-element displayElementId=changePasswdForm extends=crudForm !-- include the user password fields also used by the addUserWidget -- attribute displayElementId=userPasswdWidget sequence=1/ !-- The rest of the user information is cached in the html form allowing the update handler to be reused for the change password page -- attribute attName=cmManagerId displayElementId=Text sequence=10 set-property name=isHidden value=true/ /attribute attribute attName=cmFname displayElementId=Text sequence=11 set-property name=isHidden value=true/ /attribute attribute attName=cmMname displayElementId=Text sequence=12 set-property name=isHidden value=true/ /attribute attribute attName=cmLname displayElementId=Text sequence=13 set-property name=isHidden value=true/ /attribute /display-element !-- The
Re: Context attributes (was: Struts 2.0 Discussion Forum)
I like the idea of making the parameters/arguments passed between
actions declarative verses programmatic. This makes it very easy to
define interfaces between pages. The following code shows our
solution using the extendibility of struts metadata but it would be
slick if it was a feature of the baseline.
In the event that the forward is not a redirect, we just stage the data
in request scope for the target page in a Map collection. This allows
data to be staged in the formbean that was not in the request
parameters. The target action just uses the populate method of beanutils
to move corresponding from the map cached in the request to the target
formbean. A redirect is easy because the request processor does the
dirty work. It would be fun if this kind processing could be moved up
in the framework.
Maybe both options of encoding arguments (declarative, programmatic)
could complement each other and both redirect and forward could have
similar behavior?
Gary
action
path=/viewResultsetI
type=com.rustts.action.RusttsDispatchAction
className=com.rustts.action.RusttsActionMapping
input=.dynaPage
name=ResultsetDynaForm
scope=session
parameter=cmd
set-property property=pageId
value=viewResultsetIPage /
forward name=quit path=/viewPage.do redirect=true
className=com.rustts.action.RusttsForwardAction
!-- values pulled from the from bean that interface
with
the target page --
set-property property=arg0 value=year /
set-property property=arg1 value=month /
/forward
/action
// action execute method stages the form and request. You might have //
parameters in the form bean not in the request.
if (mapping instanceof IRusttsActionMapping) {
((IRusttsActionMapping) mapping).setState(form, request);
}
package com.rustts.action;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
/**
* @author Gary VanMatre
*
* Extended the base action mapping to add custom properties
* use the set-property element in the XML mapping to associate
* a page with an action.
*/
public class RusttsActionMapping
extends ActionMapping
implements IRusttsActionMapping {
private String pageId = null;
// make sure that these values will not be persisted in a
// distributed deployment. I believe that struts caches it's
// metadata in application scope which is not replicated (only
session)
private transient ActionForm form = null;
private transient HttpServletRequest request = null;
/**
* Returns the pageId.
* @return String
*/
public String getPageId() {
return pageId;
}
/**
* Sets the pageId.
* @param pageId The pageId to set
*/
public void setPageId(String pageId) {
this.pageId = pageId;
}
/**
* This method's purpose is to stage date for the custom action
forward class codeRusttsForwardAction/code.
* The reference should be effective only for the dialog
duration of a method call.
* The method is invoked by @see
com.rustts.action.RusttsDispatchAction#execute(ActionMapping, ActonForm,
HttpServletRequest, HttpServletResponse).
*/
public void setState(ActionForm form, HttpServletRequest
request) {
this.form = form;
this.request = request;
}
/**
* This method has been overridden to initiate the propagation
* of arguments on an action forward.
* If the mapping class realizes interface
* codeIRusttsForwardAction/action, the specified properties
* in the struts configuration file will be pulled from the form bean
and
* staged for the next page.
* The method of staging depends on if the action forward is a redirect.
*/
public ActionForward findForward(String name) {
ActionForward forward = super.findForward(name);
if ((forward != null)
(forward instanceof IRusttsForwardAction)
(request != null)
(form != null)) {
forward =
((IRusttsForwardAction)
forward).stageForward(form, request);
}
return forward;
}
protected void finalize() {
pageId = null;
form = null;
request = null;
}
}
package com.rustts.action;
import java.net.URLEncoder;
import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap;
import java.util.TreeSet;
import javax.servlet.http.HttpServletRequest;
import
