Re: HTML special characters
i think i'll add my $.02 here...
what craig says on this matter is perfectly reasonable [i previously
felt this was an issue, but not a big enough one for me to raise a
flag about].
something that i would like to see though is a hook into this mechanism
so that if a developer desires or requires, they could easily install
their own "filter" which does more or special encoding not handled
by the ResponseUtil.filter() method. since all the struts tags use
this centralized method before spitting out HTML, what better place
to locate such functionality [transparently]?
of course, such a mechanism should also be available for use outside
of the struts tags in case one is inclined to not use them...
On Tuesday, April 24, 2001, at 09:52 AM, Peter Alfors wrote:
> Oops... I wasn't thinking... :)
> Yep, I agree it shouldn't be an encoding mechanism.
>
> Pete
>
> "Craig R. McClanahan" wrote:
>
>> On Fri, 20 Apr 2001, Peter Alfors wrote:
>>
>>> Hello all,
>>>
>>> Is there any plan to update the ResponseUtil.filter() method to
>>> handle more (or all) of the HTML special characters?
>>> It looks like right now only 4 are being handled.
>>>
>>> Thanks,
>>> Pete
>>>
>>
>> What other characters are you concerned about? The purpose of
>> filtering
>> was to avoid problems where user data had HTML markup in it, but it
>> wasn't
>> designed to be a general purpose encoding mechanism.
>>
>> Craig
begin:vcard
n:;
x-mozilla-html:FALSE
org:http://www.irista.com/logo/irista.gif";>Bringing Vision to Your Supply Chain
adr:;;
version:2.1
end:vcard
>
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: a "_blank" target
Maya Muchnik wrote:
>
> Hi,
> I think struts tag has a target attribute, right? Netscape uses
> a "_blank" target in anchor. And it "hide" a HREF itself from a
> user. But in IE it does not work (I can see HREF). Is this Netscape
> specific? How I can do similar in IE? (Sorry, Craig T., I do not know, how
> implement what you have suggested).
>
the target attribute indicates to the browser which _named_ window
or frame to place the results of a request into. it has nothing to
do with whether the URL is shown in the status bar. there are certain
special target values recognized by browsers:
_top
replace the top window/frameset with the results of the request
_blank
place request results into a new window
_self
replace the contents of the window/frame in which the link resides
with the results of the request
_parent
places the result of the request in the parent of the one
displaying the current document.
all other values of the TARGET attribute indicate a window/frame name.
if no window or frame of that particular name exists, the the results
are place in a _new_ window (given the specified name).
the target attribute is now part of the HTML 4 spec. (i
don't have the spec handy, but the attribute has been around and in use
since the dawn of time (or at least netscape :))
hope this answers your question (at least partially)
e
--
_______
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Iterate an indexed property?
> Katarina Nelson wrote:
>
> Hi,
>
> I try on my jsp page iterate an indexed property.
> I get this exception:
> "javax.servlet.ServletException: Invalid indexed property
> 'routingData[<%=s%>]'"
>
> My code:
> <%
> int counter = 0;
> String s = null
> s.valueOf(counter);
> for (int i = 0; i < myRoutingList.getRouteElements().size(); i++) {
> %>
>
>
>
> size="6"/>
>
>
>
> <%
> counter++;
> s = s.valueOf(counter);
> }
> %>
>
> I tried both with counter as an int and a string . No one seems work.
> Do somebody know what´s is the problem?
>
> Thanks,
> Katarina
>
>
> <%=s%>
>
jsp RTE expressions are an all or nothing gig when specifying
attribute values for a tag, so the following is illegal:
try this instead:
(NOTE the single quotes around the RTE to prevent the JSP parser from
getting terminall confused by the embedded double quotes within the
RTE)
hope that helps,
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Minimizing Action class proliferation
Niall Pemberton wrote:
>
> Donnie,
>
> How about this as an alternative. I have created a subclass of Action called
> StandardAction which uses reflection to invoke a method with the same name
> as the "actions" path (defined in the struts-config.xml file). So all you
> have to do is extend the Standard action and implement methods that
> correspond to the paths that use it.
>
> For example if you define three actions in your struts-config.xml file of
> /saveOrder, /editOrder and /deleteOrder that all use a class OrderAction
> which extends StandardAction and then create a OrderAction class as shown
> below:
>
> I hope this is of use.
>
> Niall
>
now, this is an intriguing idea...i like...thank you. :)
e
--
_______
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: question on errors, how to handle
i posted a suite of tags for improved handling/dealing with ActionErrors
to the struts-dev list some time ago. maybe these would be of use
in some or all of these cases. feel free to pilfer...
they may require some tweaks to work with the current build of struts
(i haven't tested it since i submitted the code)
the jar file can be retrieved from:
<
http://anthrax.itfais.com/pub/struts-errtag.jar
>
e
Shamdasani Nimmi-ANS004 wrote:
>
> Craig,
>
> Is there a way that only the error message(e.g., username is required) appears next
>to the error field instead of the headings:
>
> VALIDATION ERROR
> You must correct the following error(s) before proceeding
>
> also appearing with it. It will be good if the heading could be at the top of the
>page and the actual message next to the culprit field.
>
> -Nimmi
>
> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 31, 2001 6:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: question on errors, how to handle
>
> Mike Campbell wrote:
>
> > I want to be able to have a set of errors returned to an input page
> > such that I can spit out an error of a particular TYPE next to a
> > particular input, to indicate something in particular was wrong with
> > this particular field. I'm a bit lost on how to accomplish this.Take
> > your typical login screen consisting of user name and password. If
> > the login fails, I want the screen to be redrawn with errors that
> > pertain to the user name field next to the user name field, and the
> > errors associated with the password next to the password field.
> > (Ignoring formatting), if my login screen looked
> > like:---Login:
> > ___Password:
> > _---...and
> > I typed in "foo9" in user name and nothing in password and given some
> > contrived validation rules which will be obvious from the example
> > below, I want something like the following to be
> > shown:---Login:
> > foo9* The user name must be over 8 characters long* The user
> > name must only consist of alphabetic characters.Password:
> > _* The password was left blank, it must be
> > provided.---Figuring
> > out all these conditions, constructing the ActionError class with the
> > ApplicationResources.properties key and adding the ActionErrors to the
> > request is pretty simple, but I'm lost on the "how to assign an error
> > to a particular input field" concept.Is this covered in the
> > example?Thanks. --
> >
>
> Mike Campbell Email: [EMAIL PROTECTED]
> S1 Corporationvoice: 678.421.4641
> Software Engineer fax: 678.421.4865
> R & D web: http://www.s1.com/
> Black Knight
> >
>
> When you store an error in the ActionErrors collection, you have the
> option to associate it with a particular field:
>
> ActionErrors errors = new ActionErrors();
> String username = formBean.getUsername();
> String password = formBean.getPassword();
> if ((username == null) || (username.length() < 1)
> errors.add(new ActionError("username",
> "error.username.required"));
> ... and so on ...
>
> Although the example app does not do so, you can utilize a recently
> added feature of the tag to place the messages where you
> want:
>
> ... prompt and field for the "username" field ...
>
>
> ... prompt and field for the "password" field ...
>
>
> Craig McClanahan
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: strut html tags
"Craig R. McClanahan" wrote:
>
> Daniel Ostermeier wrote:
>
> > What is the point of the strut html tags when all they
> > appear to do is print out there corresponding raw html?
> > Why not just use the raw html?
> >
> > Daniel
>
> Consider the case where the user made some errors, and you wish to
> redisplay the input form -- but already filled out with the values that
> the user entered last time, along with one or more error messages (i.e.
> the way that GUI programs behave).
>
> The Struts tags do this automatically for you. Otherwise, you will have
> to do it yourself somehow. They also do other convenient things:
> * Automatically filter for characters like "<" that are significant in
> HTML
> * Automatically call response.encodeURL() to maintain session state
> when you are not using cookies.
> * Automatically recognize what Locale is in use, and select message
> strings in the corresponding language.
> * Automatically include a transactional control token to guard against
> duplicate submits of the same form.
>
> All of this can obviously be done with raw HTML, or HTML plus some
> scriptlets in a JSP page - but it is substantially more convenient to
> take advantage of the intelligence in the custom tags that generate
> different HTML depending upon the precise circumstances.
>
my only issue with this is that it's hard to prototype the form layout
without running the whole environment. generally, i'm not to big on
custom tags generating markup (unless it's really really complicated
boiler plating) -- it's difficult and tedious to correct the HTML in
the java code. and i'm not too thrilled about the idea of adding
another layer into the development process for recognizing
the custom tags in order to render them (i'm not sure how far this can
go and be successful). i guess i'm just an "old-timer" happy with
my vi text editor eschewing all these fancy schmancy gui IDEs
that end up getting in my way more often than not.
IMHO
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Post/re-post problems
Bear wrote:
>
> Craig,
>
> At 10:28 AM 1/24/2001 -0800, you wrote:
> >* Tell my users "deal with it -- this is a web application, not a
> > web site, and the URL that you see is totally irrelevant."
>
> I'm perfectly comfortable with this regarding the displayed URL. But what
> about the refresh problem? Is there anyway to elegantly handle that?
>
> thanks
> bear
see the following post in the archives for another view/solution
to this issue:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01823.html
e
--
_______
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: HtmlTag - locale
[EMAIL PROTECTED] wrote:
>but is it correct that in the HtmlTag the attribute locale is a boolean?
>
> My IPLANET6.0-Jsp-Engine tries to set a STRING and fails compiling my
> JSP-page.
>
> I thought every attribute in a Tag should be a STRING !?
>
> Oliver
>
> HtmlTag:
>
> protected boolean locale = false;
>
> public boolean getLocale() {
> return (locale);
> }
>
> public void setLocale(boolean locale) {
> this.locale = locale;
> }
>
> My JSP
>
>
likewise behavior for JRun3.0 and JRun3.0sp1 resulting in a page
compilation exception.
rather irritating...
e
--
_______
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Directions of digester?
"Craig R. McClanahan" wrote:
> Craig McClanahan
>
> PS: For those interested in understanding more about how to use the Digester
> module, I recently enhanced the Digester Developer's Guide in the Javadocs. You
> can read it inside the Struts documentation application, or online at:
>
>
>http://jakarta.apache.org/struts/api/org/apache/struts/digester/packagesummary.html#package_description
something i noticed about these docs when i first originally tried
coding up some digester work was that use of "*/a" type of patter
wasn't clearly described. In particular, no mention was made that
it only works as a suffix. it's not all that clear whether something
like "a/b/*/d" should work at all (i don't believe it does even though
i think it should. it was a while ago when i tried this). also, no
mention is made of the fact that there can only be one wildcard
specified. so, something like "*/a/b/*/c" won't work. once again,
multiple wildcards would be extremely useful. at a minimum, a
wildcard located somewhere other than at the beginning of the pattern
_should_ be supported.
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Any way to dynamically change flow-of-control?
see interspersed comments below...
"Laird J. Nelson" wrote:
>
> - Original Message -
>
> I like to think of this as the "dialog box problem" that web UIs face.
> That is, each case above, in a "traditional" client-server program,
> would be implemented, usually, as a dialog box. What's unique about a
> dialog box? It pops up and gets in the way of where you (a) are or (b)
> were trying to go. Only when you dismiss it are you "returned" to
> either (a) or (b). On the web, of course, with our primitive HTML-based
> UIs, there are no such things as dialog boxes (unless you use
> javascript). So "screen flow" becomes all important.
>
> I bring this up because struts seems to have gone partway--better than
> any other framework I've seen--but not all the way in its support of
> this dialog box metaphor (it uses form beans). What is now needed is a
> navigation stack of some kind--perhaps even something that is
> written/phrased in terms of "traditional" UI metaphors. I'm thinking
> about some kind of stack--and believe me, I haven't thought this all the
> way through yet--that can be accessed by Actions, but any given Action
> would typically say something like "OK, go to the next screen that I'm
> being told to go to, or if I'm not being told to go anywhere, go to this
> default location". Or the Action might be able to say "oops, conditions
> aren't right to advance; pop the stack and go back to where we were a
> moment ago but display the following message". Things on the stack
> would be *roughly* equivalent to screens--though I hesitate to use
> "screen" as I think that's one of the major shortcomings of the Turbine
> framework, because a "screen" on the web often exists as a separate
> entity only because the marketing department said it has to.
Actually, I've implemented just such a construct at work for the struts
based prototype of a significant financial web-application shell. There
was some discussion on this list some time ago about something called a
StateManager, which is essentially what this is. And yes, the concept
of
"screen" is fuzzy -- in my situation, a "screen" is really a [at times]
complicated and changing frameset.
The app/shell's flow follows a (process/state update/redraw) pattern
in a [con]federation of sub-applications (and thus, controllers).
See my attached diagram with numbered steps as follows:
1) Application Request
Client-side user triggers a request to the server.
2) Sub-application Controller Dispatch
Dispatches the request to the appropriate action handler.
3) Action Request Processing
The actions process the request, invokes relevant business logic,
sets up data and state beans.
4) Redirect Response
Initial request response is _always_ a redirect to a single URL
to redraw the application window.
5) Window Redraw Request
There is one global window redraw request handled by the main
controller servlet. This request "repaints" the entire browser
window based on the current state of the application.
6) Main Controller Dispatch
Dispatches the request to the appropriate action handler.
7) Action Request Processing
This sets up the request object and determines the correct views to
"forwards" to based on what's on top of the page stack.
8) Request Forwarded (dispatched) to Views
9) JSP Views Render Response
10) Final Result Response
Response to the redraw request.
(apologies for the detail level in these steps -- I lifted this diagram
and description from the system overview documentation I'm working on
at work (geared towards newbie developers in my group))
one side benefit of this indirected approach is that the application
has _total_ control over what the user sees...because all requests
_always_ result in a redirect to the same _global_ repaint action,
the browser's navigation buttons are effectively disabled; the user always
gets presented what is currently at the top of the pagestack -- be it
error page, form, interjected "dialog" window, etc. The framework
effectively hides the implementing JSP views from the browser's URL
location making it more difficult for the user to bookmark intermediate
pages or the browser to track page history (something which is usually
not desirable, especially with sensitive apps/sites).
I hope this was helpful...
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Unknown Document
RE: Problem with Digester used "standalone" (REF: BugRat report #692)
NullPointerException using CallMethodRule in Digester. This occurs if the
parameters to the method call are specified as being primitive types. For
example, the following excerpt from the Digester init:
digester.addCallMethod(
"quickmenu-config/entry/visibility",
//"setAppIDSense", 1, new String[] {"java.lang.Boolean"});
"setAppIDSense", 1, new String[] {"boolean"});
digester.addCallParam(
"quickmenu-config/entry/visibility", 0, "sense");
In this case, configuring the CallMethodRule to invoke a method with a
primitive data type as a parameter fails. The commented out version
using the Boolean wrapper object succeeds. (NOTE: The destination
object has the method with both signatures).
Stack trace from my code:
=
End event threw exception
java.lang.NullPointerException:
at org.apache.struts.util.BeanUtils.convert(BeanUtils.java:131)
at org.apache.struts.digester.CallMethodRule.end(CallMethodRule.java:226)
at org.apache.struts.digester.Digester.endElement(Digester.java:373)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1413)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:77)
at org.apache.struts.digester.Digester.parse(Digester.java:708)
at loadQuickmenu.readConfig(loadQuickmenu.java:32)
at loadQuickmenu.main(loadQuickmenu.java:41)
To correct this issue in struts, add new method to BeanUtils.java [Class
forName(String classname)] which defers to/mirrors the version in Class
but
also handles primitive data types. Modify constructor in
org/apache/struts/digester/CallMethodRule.java to call
BeanUtils.forName(String) rather than Class.forName(String) to convert
the className to a Class Object.
The updated files are attached.
e
--
_______
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
/*
* $Header:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/util/BeanUtils.java,v 1.18
2000/12/31 04:26:37 craigmcc Exp $
* $Revision: 1.18 $
* $Date: 2000/12/31 04:26:37 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* O
Re: Problem with Digester used "standalone"
Martin Cooper wrote:
>
> I've been trying to use the Digester module on its own (i.e. no other Struts
> code, no servlets, no JSP), and have been having problems. At first, I
> thought it must be my application code, but then I tried copying the code
> from the Struts example DatabaseServlet into my own Java application and
> came across the same problem.
>
> The problem happens when addSetProperties() is used. The call itself
> succeeds, but later on, when Digester.parse() is called, I get the following
> error and call stack:
>
> java.lang.NullPointerException
> at
> org.apache.struts.digester.SetPropertiesRule.begin(SetPropertiesRule.java,
> Compiled Code)
> at org.apache.struts.digester.Digester.startElement(Digester.java,
> Compiled Code)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
> at com.sun.xml.parser.Parser.parse(Parser.java:284)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:77)
> at org.apache.struts.digester.Digester.parse(Digester.java:708)
> at mfnc.TryDigester.TryDatabase(TryDigester.java:92)
> at mfnc.TryDigester.main(TryDigester.java:18)
> org.xml.sax.SAXException
>
> If I comment out the calls to addSetProperties(), everything works just fine
> (except that I don't have the property values I wanted :-) ).
>
> Anyone have any ideas about what I might be doing wrong? I know this isn't
> how the Digester is expected to be used, but, well, it just seemed like a
> handy class for parsing simple XML files...
>
i had a similar problem a while back relating to dealing with method
calls that had primitive data type parameters (in my case, boolean).
i don't remember the specifics as this was over a month ago. i'll see
if i can dredge up the problem again at work today.
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
PROPOSAL: public method in ActionErrors to iterate across properties
all,
i would like to propose that a public method be added to the
ActionErrors class to retrieve an enumeration of all the property
names that have errors associated with them. additionally, a size
method should be added to return the count of the number of properties
that have errors associated with them.
there currently is no way to associate an ActionError with a particular
property unless you a priori know the property name in question. this
is particularly troublesome when trying to use a generic error page
to display validation errors. typically, in such a page, one needs to
display the field/property name associated with its errors.
See, for example, this rendition of an error page:
Validation Failure:
property1 - some error message1
- some error message2
property2 - some error message3
property3 - some error message4
- some error message5
Additionally, when the user goes back to the page with the relevant
form, it is useful to somehow visually highlight the labels for the form
entry fields in question. without being able to get at the property
names with errors, it's extremely difficult to accomplish this.
the _errors_ tag certainly provides no help in any of these situations.
perhaps create some new error tags that allow you to iterate
errors grouped by property and to get at the property and error
messages independently (embedded in HTML markup in JSP).
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
