RE: XDoclet
Tim, > From: Tim Christopher [mailto:[EMAIL PROTECTED] > What does everyone think of using XDoclet to build > Struts / Tiles / Validator configuration files? I like using XDoclet for creating the struts-config.xml file. For permanent items that are not in your .java files or which need to be constant, XDoclet allows for "merge" files for each section with obvious names such as struts-forms.xml, global-exceptions.xml, struts-actions.xml and struts-controller.xml. On using XDoclet to create tiles, to my knowledge it cannot be done. Please post any URLs since my quick web search pulled up nothing (for me) that seemed relevant. Finally, I have some personal issues with the XDoclet's support for Struts validation files. If you map one .java file to multiple paths such as "/edit" and "/create", the XDoclet validation considers all validation rules in that .java class file to be for ONE form validation. You can't say some rules to go one path for this action class while some rules go to the other path for this same action. It is best in that case for validation for ActionForms/beans only. Regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
Wendy Smoak wrote:
From: "Erik Weber" <[EMAIL PROTECTED]>
I see now that the problem appears to be that the c tag is assuming
"org.foo.ATTRIBUTE" means org.getFoo(), etc. How can I tell the c tag
that "org.foo.ATTRIBUTE" is the name of the request attribute, not
"org"?
What is the JSTL equivalent of this logic tag?
Since you know it's in request scope, try this:
${requestScope["org.foo.ATTRIBUTE"]}
Dotted names become a problem when you want JSTL to do its usual "find
this in any scope" process. But as long as you know where your
attribute is (or that it's a request parameter) you can use the
implicit objects.
Appendix A of JSTL in Action is available here:
http://www.manning.com/catalog/view.php?book=bayern&item=chapters
Thanks Wendy! Just what I needed.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
Good stuff! Thanks for the post :-) It actually reminded me of a couple of things I had forgotten ... or mislearned ;-P On Sat, 29 Jan 2005 20:29:54 -0700, Wendy Smoak <[EMAIL PROTECTED]> wrote: > Appendix A of JSTL in Action is available here: > http://www.manning.com/catalog/view.php?book=bayern&item=chapters > > -- > Wendy Smoak -- Eddie Bush Thank you for removing unnecessary dialog when posting a response! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XDoclet
I think there's been some movement to do this in the past. You might try searching on sourceforge ... or even Google. On Sun, 30 Jan 2005 03:28:27 +, Tim Christopher <[EMAIL PROTECTED]> wrote: > Hi, > > What does everyone think of using XDoclet to build Struts / Tiles / > Validator configuration files? -- Eddie Bush Thank you for removing unnecessary dialog when posting a response! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
From: "Erik Weber" <[EMAIL PROTECTED]>
I see now that the problem appears to be that the c tag is assuming
"org.foo.ATTRIBUTE" means org.getFoo(), etc. How can I tell the c tag that
"org.foo.ATTRIBUTE" is the name of the request attribute, not "org"?
What is the JSTL equivalent of this logic tag?
Since you know it's in request scope, try this:
${requestScope["org.foo.ATTRIBUTE"]}
Dotted names become a problem when you want JSTL to do its usual "find this
in any scope" process. But as long as you know where your attribute is (or
that it's a request parameter) you can use the implicit objects.
Appendix A of JSTL in Action is available here:
http://www.manning.com/catalog/view.php?book=bayern&item=chapters
--
Wendy Smoak
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
XDoclet
Hi, What does everyone think of using XDoclet to build Struts / Tiles / Validator configuration files? Is it likely to make life seem like it's worth living, or is a few hours spent trying to learn it going to drive me mad? :o) Cheers for your feedback! Tim Christopher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: JSTL vs logic:present
Eddie Bush wrote: I thought that's what you were getting at! ;-) Please trim unnecessary dialog from your response when posting :-) And now, here are the complete lyrics to "The Song That Never Ends" . . . Just messin' with ya! :-P On Sat, 29 Jan 2005 21:57:26 -0500, Erik Weber <[EMAIL PROTECTED]> wrote: I see now that the problem appears to be that the c tag is assuming "org.foo.ATTRIBUTE" means org.getFoo(), etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
Thanks Eddie. That did the trick.
Erik
Eddie Bush wrote:
Erik,
Maybe I'm missing something, but do you have a bean in-scope named
org, which has a property named foo, which has a property named
ATTRIBUTE?
Maybe:
or
Tried that? I could totally be missing your point ... but, if the
"name" of the bean is "org.foo.ATTRIBUTE", you're probably going to
have to reference it in a fashion similar to what I've shown here.
Unless there's something I don't know about JSTL that enables you to
reference it the way you've said (which, I'll grant you, is beyond
conceivable!).
It's that complex name that's throwing you off, I'll bet ...
On Sat, 29 Jan 2005 21:46:56 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
What is the JSTL equivalent of this logic tag?
I tried this:
but it didn't work. Neither did "${!empty org.foo.ATTRIBUTE}".
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
I thought that's what you were getting at! ;-) Please trim unnecessary dialog from your response when posting :-) On Sat, 29 Jan 2005 21:57:26 -0500, Erik Weber <[EMAIL PROTECTED]> wrote: > I see now that the problem appears to be that the c tag is assuming > "org.foo.ATTRIBUTE" means org.getFoo(), etc. -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
Erik,
Maybe I'm missing something, but do you have a bean in-scope named
org, which has a property named foo, which has a property named
ATTRIBUTE?
Maybe:
or
Tried that? I could totally be missing your point ... but, if the
"name" of the bean is "org.foo.ATTRIBUTE", you're probably going to
have to reference it in a fashion similar to what I've shown here.
Unless there's something I don't know about JSTL that enables you to
reference it the way you've said (which, I'll grant you, is beyond
conceivable!).
It's that complex name that's throwing you off, I'll bet ...
On Sat, 29 Jan 2005 21:46:56 -0500, Erik Weber <[EMAIL PROTECTED]> wrote:
> What is the JSTL equivalent of this logic tag?
>
>
>
> I tried this:
>
>
>
> but it didn't work. Neither did "${!empty org.foo.ATTRIBUTE}".
>
> Erik
--
Eddie Bush
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL vs logic:present
I see now that the problem appears to be that the c tag is assuming
"org.foo.ATTRIBUTE" means org.getFoo(), etc. How can I tell the c tag
that "org.foo.ATTRIBUTE" is the name of the request attribute, not "org"?
Thanks,
Erik
Erik Weber wrote:
What is the JSTL equivalent of this logic tag?
I tried this:
but it didn't work. Neither did "${!empty org.foo.ATTRIBUTE}".
Erik
-
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]
JSTL vs logic:present
What is the JSTL equivalent of this logic tag?
I tried this:
but it didn't work. Neither did "${!empty org.foo.ATTRIBUTE}".
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
Dang, Kishore, you are relentless! I like that!
You have the option of setting each tag with the value you want for
these and programming them in, if you like.
On Sat, 29 Jan 2005 14:40:26 -0600, Kishore Senji <[EMAIL PROTECTED]> wrote:
> >response.setContentType(type);
> >response.setHeader("Cache-Control", "");
> >response.setHeader("Pragma", "");
> >response.setHeader("Expires", "");
> >response.addHeader("Content-Disposition","filename=" + name);
>
> With the above headers, is caching turned on or off. Cache-Control is
> set to empty string. If the browsers intrepret this as "no-cache" then
> fetching the same image, js or a css file (through the resource
> action) over and again might a performance drawback as apposed to
> getting those files only once (which is what I guess most browsers do,
> cache the images, js, css with static links to resources). Isn't it?
Here is something you could do, for example.
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file= request.getParameter("file");
String ext = file.substring(file.lastIndexOf('.') + 1);
String type= null;
String path= null;
if ("gif".equals(ext)) {
type = "image/gif";
path = path("gif");
} else if ("jpg".equals(ext)) {
type = "image/jpeg";
path = path("jpeg");
} else if ("css".equals(ext)) {
type = "text/css";
path = path("css");
} else if ("flash".equals(ext)) {
type = "application/x-shockwave-flash";
path = path("flash");
} else if ("text".equals(ext)) {
type = "text/plain";
path = path("text");
} else if ("js".equals(ext)) {
type = "text/javascript";
path = path("js");
} else if ("png".equals(ext)) {
type = "image/png";
path = path("png");
} else if ("html".equals(ext)) {
type = "text/html";
path = path("html");
} else if ("applet".equals(ext)) {
type = "application/x-java-applet";
path = applet();
}
String fileName = "filename=" + Classpath.WEB_INF + path + file;
response.setContentType(type);
/* E.g. cache = "post-check=120,pre-check=240",
= "max-age=86400,private"
post-checks are the time after the initial cache at which you
have an immediate view without any update. The time from the
post to the pre-check is the time whem you get an immediate
view but an update. The time after the pre-check time is when
you get an update prior to a view.
Cf.
http://msdn.microsoft.com/workshop/author/perf/perftips.asp#Use_Cache-Control_Extensions
*/
String cache = request.getParameter("cache"); /* HTTP 1.1:
Numbers are seconds for cache. */
String pragma = request.getParameter("pragma"); /* HTTP 1.0:
Numbers are seconds for pragma. */
String expires = request.getParameter("expires");/* HTTP 1.0:
Numbers are minutes for expires. */
response.setHeader("Cache-Control", ((cache == null) ?
"no-check" : cache));
response.setHeader("Pragma", ((pragma == null) ?
"no-check" : pragma));
response.setHeader("Expires",((expires == null) ?
"1440" : expires));
response.addHeader("Content-Disposition",(fileName));
try {
FileInputStream fis = new FileInputStream(fileName);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
is: " + fileName + "\n" + StackTrace.trace(ioe) + "\n" +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return "resource" + File.separator + "content_type" +
File.separator + fileType + File.separator;
}
private String applet() {
return "classes" + File.separator + "com" + File.separator +
"crackwillow" + File.separator + "applet";
}
} ///;-)
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you ha
Re: Blocking direct access to JSPs
>response.setContentType(type);
>response.setHeader("Cache-Control", "");
>response.setHeader("Pragma", "");
>response.setHeader("Expires", "");
>response.addHeader("Content-Disposition","filename=" + name);
With the above headers, is caching turned on or off. Cache-Control is
set to empty string. If the browsers intrepret this as "no-cache" then
fetching the same image, js or a css file (through the resource
action) over and again might a performance drawback as apposed to
getting those files only once (which is what I guess most browsers do,
cache the images, js, css with static links to resources). Isn't it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts, XHTML, DOCTYPES, and EL (several newbie questions)
Have you tried examining the source? ;-) Let's do: If you set the code is going to set a PageContext variable indicating XHTML should be used to true. You can find an identical line of code in the XhtmlTag class. I'd say, based off the code, that they're functionally equivalent. For you DOCTYPE question: I don't believe you'll find one. You could keep this in a XHTML.inc file - somewhere - and use the @include directive or to place it into pages where you wanted to use it. The @include directive does a static include (includes the content at compile time) and includes the content dynamically at the time of the request. Struts current "production-quality" code-base is 1.2.4. Using the EL-tags are more of a convenience than a "right way" to do things. They can be indespensible for removing run-time expressions from your pages though, since they allow EL-expressions for attribute values. For your javadoc concerns ... you should have a struts-documentation.war file that came with your distribution (look under webapps). You should be able to extract the api docs from there. You might want to jar them up - been a while since I used NetBeans, so I don't recall. NetBeans knows about the tag attributes because of the TLD files. You can get better descriptions of the tags' attributes from the struts-documentation.war app (you might just install it in your container so you'll have it for reference). Good Luck! -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create dynamic form ?
At 5:29 PM +0800 1/29/05, Eric Chow wrote: How can I not use the struts-config.xml but I can use my own config to generate a HTML form and use a standard validator to validate the form data ?? When Struts goes to get you a form bean (based on the "name" attribute of an mapping, it goes to the current ModuleConfig object and calls "findFormBeanConfig(String name)". You can call "addFormBeanConfig" on a ModuleConfig object any time before the Servlet init process is done; probably the best place to do this is in a PlugIn class, whose init method gets handed the ModuleConfig. In the example I cited, we looked up "form" information from a database schema representing a survey, and created FormBeanConfig objects based on that data, and added them to the Module's set of available forms. If I recall, the PlugIn was designed to take as config properties the unique ID of the survey config database record and a form bean name; if we had needed more than one per app, I probably would have just set up a series of PlugIns, each with the responsibility of instantiating one FormBeanConfig. This is not extremely complicated, but at this point if you still have questions, I'd suggest getting a copy of the Struts source code and tracing this through. (In general, I'd suggest this for anyone with the slightest curiosity. It's really not so complicated, and it will give you a much broader idea about how you can make Struts do what you want it to do.) Joe On Fri, 28 Jan 2005 10:12:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: At 8:03 AM -0700 1/28/05, Wendy Smoak wrote: >From: "Eric Chow" <[EMAIL PROTECTED]> > >>How can I create forms without defining it in the struts-config.xml? >>I mean I want o use my own config and generate a HTML form with Struts >>action handling. > >Take a look at LazyDynaBean and LazyValidatorForm. There's some >information on the wiki: >http://wiki.apache.org/struts/StrutsCatalogLazyList section 2.4 . A developer on my team developed a system to retrieve survey configuration data from a database and present it to users in Struts. This involved dynamic form creation and validation. The gist was that a PlugIn, when initialized, used database data to create and register DynaForms. I believe it was a subclass of DynaActionValidatorForm which could interact with this same PlugIn to do the Survey specific validation (where the rules came from the database) while delegating validation for any standard fields (like contact info) to normally configured validator XML. As Wendy points out, now that there are LazyValidatorForms, this would probably be simpler, because you would only need to extend the validation method, and could probably skip defining new form classes. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - 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] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatch with ??
http://www.michaelmcgrady.com/button/ Jack On Sat, 29 Jan 2005 21:25:44 +0200, Nils Liebelt <[EMAIL PROTECTED]> wrote: > Hi everybody, > > I am using a LookupDispatch action to add and delete stuff to a form. It > works fine but it seems like quite a hustle to change my add and delete > buttons into linked images. Is there a way of html:image tag in this > particular situation? > > Any suggestions? > > Regards, > > Nils > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LookupDispatch with ??
Hi everybody, I am using a LookupDispatch action to add and delete stuff to a form. It works fine but it seems like quite a hustle to change my add and delete buttons into linked images. Is there a way of html:image tag in this particular situation? Any suggestions? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LookupDispatch with ??
Hi everybody, I am using a LookupDispatch action to add and delete stuff to a form. It works fine but it seems like quite a hustle to change my add and delete buttons into linked images. Is there a way of html:image tag in this particular situation? Any suggestions? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BANDWIDTH CONCERNS and SNIPPING POSTS
I really do think that "Smart Questions" should have a counterpart "Smart Answers". By this I mean that I notice that a lot of the bandwidth is taken up by people who jump in before reading a question carefully and begin to give irrelevant advice and sometimes bad demands (wrong list, etc.) because they did not bother to read things carefully or to assume that the poster had a brain too. I am really surprised how much committers do this thing, and I do not mean to isolate anyone in particular or only committers. Sometimes we all read things too fast. Prior to making demands or even making "demeans", however, it would be especially good to make sure one understands what a question or a problem is. This is advisable just because it is curtious on the one hand but also because it sure could make a lot of long threads short ones too. Jack On Sat, 29 Jan 2005 12:12:22 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > Struts has a large number of international users, so bandwidth on the mailing > list is always a concern. A lot of us have broadband, and extra paragraphs > get lost in the rounding. But for others, longer posts means more > finger-tapping, and maybe even a higher ISP bill. :( > Of course, the best way to conserve list bandwidth, human and digital, is (as > mentioned) to observe [http://www.catb.org/~esr/faqs/smart-questions.html]. > > -Ted. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
On Sat, 29 Jan 2005 12:40:21 -0500, William Stranathan <[EMAIL PROTECTED]> wrote: > Don't put your html resources, CSS, etc. under WEB-INF - just put the > JSP's there. If your images or CSS or .js files have anything you need > to protect from direct access (passwords - perish the thought! > Proprietary information?), put them under WEB-INF and use DownloadAction > to send them. > While protection is a good reason to be under WEB-INF there is another reason to access assets or resources directly, as I indicated in my posts, viz. to avoid the mess of the serverside having to take account of where a browser assumes a file is. Using a class to access the assets or resources avoids this unfortunately part of the browser protocol because you use a protocol (Struts .do) rather than a URL. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
lastly, I think, notice that 'resource.do?file=Whatever.jpg' in is merely text, and so can be "nested" all you like. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
Perhaps I should have added that you access the resources as follows: The rest should be obvious. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows. We are poor . . . but we are free." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
Don't put your html resources, CSS, etc. under WEB-INF - just put the JSP's there. If your images or CSS or .js files have anything you need to protect from direct access (passwords - perish the thought! Proprietary information?), put them under WEB-INF and use DownloadAction to send them. w Tim Christopher wrote: I've read that if you store your JSP files under the WEB-INF folder it blocks access to html resources (CSS etc).. What's the work around to ensure the JSP has access to all the resources it still needs? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
On Sat, 29 Jan 2005 16:28:42 +, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> I've read that if you store your JSP files under the WEB-INF folder it
> blocks access to html resources (CSS etc).. What's the work around to
> ensure the JSP has access to all the resources it still needs?
>
> Tim
The problem with access to HTML resources is that you are dependent on
the browser read of a path, relative or absolute, but have to locate
the resource serverside. The way I do this is to avoid any use of the
browser at all for this purpose and use a Struts Action class to
deliver all assets/resources including CSS, JS, GIFs, etc. to the HTML
page. Here is the essentials of the class I use to do that, with
apologies to people that don't like anything more than a code snippet
on this list ;-) :
public final class ResourceAction
extends Action {
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException,
ServletException {
String file = request.getParameter("file");
String ext = file.substring(file.lastIndexOf('.') + 1);
String type = null;
String path = null;
if ("gif".equals(ext)) {
type = "image/gif";
path = path("gif");
} else if ("jpg".equals(ext)) {
type = "image/jpeg";
path = path("jpeg");
} else if ("css".equals(ext)) {
type = "text/css";
path = path("css");
} else if ("flash".equals(ext)) {
type = "application/x-shockwave-flash";
path = path("flash");
} else if ("text".equals(ext)) {
type = "text/plain";
path = path("text");
} else if ("js".equals(ext)) {
type = "text/javascript";
path = path("js");
} else if ("png".equals(ext)) {
type = "image/png";
path = path("png");
} else if ("html".equals(ext)) {
type = "text/html";
path = path("html");
} else if ("applet".equals(ext)) {
type = "application/x-java-applet";
path = "classes" + File.separator + "com" + File.separator +
"crackwillow" + File.separator + "applet";
}
String name = Classpath.WEB_INF + path + file;
response.setContentType(type);
response.setHeader("Cache-Control", "");
response.setHeader("Pragma", "");
response.setHeader("Expires", "");
response.addHeader("Content-Disposition","filename=" + name);
try {
FileInputStream fis = new FileInputStream(name);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStreamos= response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
} catch (IOException ioe) {
StdOut.log(SiteConstant.ERROR_LOG,"ResourceAction: problem file
is: " + name + "\n" + StackTrace.trace(ioe) + "\n" +
ioe.getMessage());
}
return null;
}
private String path(String fileType) {
return "resource" + File.separator + "content_type" +
File.separator + fileType + File.separator;
}
}
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: BANDWIDTH CONCERNS and SNIPPING POSTS
On Fri, 28 Jan 2005 13:18:29 -0800, Dakota Jack wrote: > Hopefully, if there is a bandwidth problem, we can all cut down the > repeating of unnecessary matter in our posts. Struts has a large number of international users, so bandwidth on the mailing list is always a concern. A lot of us have broadband, and extra paragraphs get lost in the rounding. But for others, longer posts means more finger-tapping, and maybe even a higher ISP bill. :( Something to keep in mind is that every second you can save people when they review your post is multiplied by the 2000+ subscribers to the list today (2000 seconds is 33 minutes), and also by the thousands of others who read posts through the archives later. Of course, the best way to conserve list bandwidth, human and digital, is (as mentioned) to observe [http://www.catb.org/~esr/faqs/smart-questions.html]. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blocking direct access to JSPs
I've read that if you store your JSP files under the WEB-INF folder it
blocks access to html resources (CSS etc).. What's the work around to
ensure the JSP has access to all the resources it still needs?
Tim
On Sat, 29 Jan 2005 10:20:25 -0500, David G. Friedman
<[EMAIL PROTECTED]> wrote:
> Frank,
>
> I agree with you when a JSP is just a template. However, may people mix
> JSP's with scriplets and other code nibblets. Having items such as those as
> publicly accessible can cause security and functionality issues. Luckily, I
> myself haven't needed to put scriptlets in my JSP's though I still put my
> JSP's, used as (tiles) display templates, under /WEB-INF/pages.
>
> Regards,
> One "David"'s $0.02 worth
>
> -Original Message-
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 29, 2005 9:07 AM
> To: Struts Users Mailing List
> Subject: Re: Blocking direct access to JSPs
>
> My argument against it is that WEB-INF is meant to be configuration
> information and "support files", and while I agree with viewing JSPs as
> templates, I don't view them as support files either. Let me put it
> another way... WEB-INF should be things that are not
> application-specific, except for configuration files and libraries.
>
> Also, if a JSP is just a template, surely it won't work without
> something on the server having been executed, right? Therefore, what's
> the harm if it's exposed anyway? I suppose you could argue you wouldn't
> even want to expose a stack trace, but it depends how far you want to
> carry the argument. Of course, you could always do:
>
> <% if (request.getAttribute("cameFromServer") != null) { %>
> // The page here
> <% } %>
>
> Sure, it requires two lines in all JSPs, but it should solve the problem.
>
> Anyway, it's just my feeling on it.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> William Stranathan wrote:
> > We had this discussion a lot last week, and it seems to be somewhat
> > divided on whether JSP's belong in WEB-INF. What was your compelling
> > argument AGAINST it?
> >
> > My compelling argument FOR it has always been that WEB-INF is where
> > application artifacts that are not complete web artifacts belong. When
> > writing in Struts (pseudo-MVC er Model II or whatever you like to call
> > it), JSP is NOT web-ready - it's only template data - just like if you
> > had an email template that had the blanks filled in.
> >
> > Of course, I don't put my JSP's DIRECTLY under WEB-INF - usually have
> > them broken out by the type of template - web, mobile, email, etc.
> >
> > w
> >
> > Tim Christopher wrote:
> >
> >> Hi,
> >>
> >> I would like to block direct access to jsp files, and from what I've
> >> read the best practice appears to be setting a security-constraint
> >> within the web.xml file. (As opposed to storing all *.jsp files
> >> within the WEB-INF folder, though please correct me if that's wrong).
> >>
> >
> > -
> > 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts, XHTML, DOCTYPES, and EL (several newbie questions)
I have another question. I seem to only get the JavaDoc help for Struts in the source of JSP files where I have the reference to the tag's via an <[EMAIL PROTECTED] ...%> scriplet. In Java I receive the error "JavaDoc not installed" from Netbeans so I was wondering where the docs folder for struts is (or where I can get a copy)? I could use the online version, but I'd rather have a local copy integrated into NB. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm problem (newbie probably :)
The reason for the error is that the beanutils package cannot convert
the date string into a Date object. You can either populate the form
with the formatted date or register a Converter to handle the
conversion appropriately. I haven't yet used Converter but this problem
has been answer many times over on the list.
This link may help:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg45982.html
/robert
Robin Ericsson wrote:
Hi,
This is my form:
This is how I populate it:
List days = new ArrayList();
--fill list--
form.set("days", (MyClass[]) days.toArray(new MyClass[days.size()]));
This is my jsp-code:
The generated html seems correct as it finds the actual data in the
MyClass property.
However, when I post the form, I get an IllegalArgumentException:
java.lang.IllegalArgumentException: argument type mismatch
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:796)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1192)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:430)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
startTime is of type java.util.Date with respective getter and setter.
Any ideas what I've done wrong?
regards,
Robin
-
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: Blocking direct access to JSPs
Frank,
I agree with you when a JSP is just a template. However, may people mix
JSP's with scriplets and other code nibblets. Having items such as those as
publicly accessible can cause security and functionality issues. Luckily, I
myself haven't needed to put scriptlets in my JSP's though I still put my
JSP's, used as (tiles) display templates, under /WEB-INF/pages.
Regards,
One "David"'s $0.02 worth
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 29, 2005 9:07 AM
To: Struts Users Mailing List
Subject: Re: Blocking direct access to JSPs
My argument against it is that WEB-INF is meant to be configuration
information and "support files", and while I agree with viewing JSPs as
templates, I don't view them as support files either. Let me put it
another way... WEB-INF should be things that are not
application-specific, except for configuration files and libraries.
Also, if a JSP is just a template, surely it won't work without
something on the server having been executed, right? Therefore, what's
the harm if it's exposed anyway? I suppose you could argue you wouldn't
even want to expose a stack trace, but it depends how far you want to
carry the argument. Of course, you could always do:
<% if (request.getAttribute("cameFromServer") != null) { %>
// The page here
<% } %>
Sure, it requires two lines in all JSPs, but it should solve the problem.
Anyway, it's just my feeling on it.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
William Stranathan wrote:
> We had this discussion a lot last week, and it seems to be somewhat
> divided on whether JSP's belong in WEB-INF. What was your compelling
> argument AGAINST it?
>
> My compelling argument FOR it has always been that WEB-INF is where
> application artifacts that are not complete web artifacts belong. When
> writing in Struts (pseudo-MVC er Model II or whatever you like to call
> it), JSP is NOT web-ready - it's only template data - just like if you
> had an email template that had the blanks filled in.
>
> Of course, I don't put my JSP's DIRECTLY under WEB-INF - usually have
> them broken out by the type of template - web, mobile, email, etc.
>
> w
>
> Tim Christopher wrote:
>
>> Hi,
>>
>> I would like to block direct access to jsp files, and from what I've
>> read the best practice appears to be setting a security-constraint
>> within the web.xml file. (As opposed to storing all *.jsp files
>> within the WEB-INF folder, though please correct me if that's wrong).
>>
>
> -
> 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: Blocking direct access to JSPs
My argument against it is that WEB-INF is meant to be configuration
information and "support files", and while I agree with viewing JSPs as
templates, I don't view them as support files either. Let me put it
another way... WEB-INF should be things that are not
application-specific, except for configuration files and libraries.
Also, if a JSP is just a template, surely it won't work without
something on the server having been executed, right? Therefore, what's
the harm if it's exposed anyway? I suppose you could argue you wouldn't
even want to expose a stack trace, but it depends how far you want to
carry the argument. Of course, you could always do:
<% if (request.getAttribute("cameFromServer") != null) { %>
// The page here
<% } %>
Sure, it requires two lines in all JSPs, but it should solve the problem.
Anyway, it's just my feeling on it.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
William Stranathan wrote:
We had this discussion a lot last week, and it seems to be somewhat
divided on whether JSP's belong in WEB-INF. What was your compelling
argument AGAINST it?
My compelling argument FOR it has always been that WEB-INF is where
application artifacts that are not complete web artifacts belong. When
writing in Struts (pseudo-MVC er Model II or whatever you like to call
it), JSP is NOT web-ready - it's only template data - just like if you
had an email template that had the blanks filled in.
Of course, I don't put my JSP's DIRECTLY under WEB-INF - usually have
them broken out by the type of template - web, mobile, email, etc.
w
Tim Christopher wrote:
Hi,
I would like to block direct access to jsp files, and from what I've
read the best practice appears to be setting a security-constraint
within the web.xml file. (As opposed to storing all *.jsp files
within the WEB-INF folder, though please correct me if that's wrong).
-
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: Blocking direct access to JSPs
We had this discussion a lot last week, and it seems to be somewhat divided on whether JSP's belong in WEB-INF. What was your compelling argument AGAINST it? My compelling argument FOR it has always been that WEB-INF is where application artifacts that are not complete web artifacts belong. When writing in Struts (pseudo-MVC er Model II or whatever you like to call it), JSP is NOT web-ready - it's only template data - just like if you had an email template that had the blanks filled in. Of course, I don't put my JSP's DIRECTLY under WEB-INF - usually have them broken out by the type of template - web, mobile, email, etc. w Tim Christopher wrote: Hi, I would like to block direct access to jsp files, and from what I've read the best practice appears to be setting a security-constraint within the web.xml file. (As opposed to storing all *.jsp files within the WEB-INF folder, though please correct me if that's wrong). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DynaActionForm problem (newbie probably :)
Hi,
This is my form:
This is how I populate it:
List days = new ArrayList();
--fill list--
form.set("days", (MyClass[]) days.toArray(new MyClass[days.size()]));
This is my jsp-code:
The generated html seems correct as it finds the actual data in the
MyClass property.
However, when I post the form, I get an IllegalArgumentException:
java.lang.IllegalArgumentException: argument type mismatch
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:324)
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789)
org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.java:1684)
org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java:1713)
org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019)
org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:493)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:796)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1192)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:430)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
startTime is of type java.util.Date with respective getter and setter.
Any ideas what I've done wrong?
regards,
Robin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Create dynamic form ?
How can I not use the struts-config.xml but I can use my own config to generate a HTML form and use a standard validator to validate the form data ?? On Fri, 28 Jan 2005 10:12:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 8:03 AM -0700 1/28/05, Wendy Smoak wrote: > >From: "Eric Chow" <[EMAIL PROTECTED]> > > > >>How can I create forms without defining it in the struts-config.xml? > >>I mean I want o use my own config and generate a HTML form with Struts > >>action handling. > > > >Take a look at LazyDynaBean and LazyValidatorForm. There's some > >information on the wiki: > >http://wiki.apache.org/struts/StrutsCatalogLazyList section 2.4 . > > A developer on my team developed a system to retrieve survey > configuration data from a database and present it to users in Struts. > This involved dynamic form creation and validation. The gist was > that a PlugIn, when initialized, used database data to create and > register DynaForms. I believe it was a subclass of > DynaActionValidatorForm which could interact with this same PlugIn to > do the Survey specific validation (where the rules came from the > database) while delegating validation for any standard fields (like > contact info) to normally configured validator XML. > > As Wendy points out, now that there are LazyValidatorForms, this > would probably be simpler, because you would only need to extend the > validation method, and could probably skip defining new form classes. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > - > 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]
