You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@struts.apache.org by Tan Siow Boon <si...@cls.uob.com.sg> on 2000/11/21 04:15:20 UTC

Cannot find tag class: 'org.apache.struts.taglib.form.RewriteTag'

Hi,

I encounterd the following error when trying out the Struts example
using nightly build 20001119. It seems like the struts-form.tld contains
a "RewriteTag" referencing a class
'org.apache.struts.taglib.form.RewriteTag' that does not exist. I
managed to get the example working by removing the "RewriteTag". I
should have reported this problem thru http://znutar.cortextity.com:8888
but I just couldn't access it.


Regards, SiowBoon

Tue Nov 21 10:11:20 GMT+08:00 2000:<I>
<WebAppServletContext-strutsExample> reso
lving taglib uri '/WEB-INF/struts-form.tld' to taglib-location
/WEB-INF/struts-f
orm.tld:
Tue Nov 21 10:11:22 GMT+08:00 2000:<E>
<WebAppServletContext-strutsExample> Serv
let failed with Exception
weblogic.servlet.jsp.JspException: (line -1): Error in tag library at:
'form': c
annot find tag class: 'org.apache.struts.taglib.form.RewriteTag'
        at
weblogic.servlet.jsp.StandardTagLib.jspException(StandardTagLib.java:
138)
        at
weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:22
9)
        at
weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib
.java:146)
        at
weblogic.servlet.jsp.StandardTagLib.<init>(StandardTagLib.java:125)
        at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:87)
        at
weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:37
39)
        at
weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3495)
        at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3356)
        at
weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1694)
        at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1535)
        at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1425)
        at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:825)
        at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69)
        at weblogic.servlet.jsp.JspParser.parse(JspParser.java:116)
        at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:97)
        at
weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242
)
        at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:265)
        at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:180)

        at
weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.
java:181)
        at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:118)
        at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm
pl.java:141)
        at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletCon
textImpl.java:761)
        at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletCon
textImpl.java:708)
        at
weblogic.servlet.internal.ServletContextManager.invokeServlet(Servlet
ContextManager.java:252)
        at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.jav
a:346)
        at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)

        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)

Re: thought on design

Posted by Jim Richards <gr...@cyber4.org>.


> The server-side enhancement is that the validate() method is now called with the request and
> the current mapping so that you have more context for making your validation decisions --
> for example, you can go retrieve the user's session and get state information you've stored
> there.

Oh, I thought that was there from v0.5. That'd make sense.

> Support for auto-generating client side validation JavaScript is not there, and is unlikely
> to be in the final 1.0 release.

Well, perhaps I should to learn how the tags are built
so I can start doing this then. I have an itch. I had
a look at them, they don't seem too hard.

> I agree with using client-side validation where you can, to improve the UI by catching
> errors earlier.  My caution is that you should plan on re-performing these checks as
> appropriate on the server side.  Don't assume that your JavaScript validation actually took
> place.

Oh, not at all. But different people prefer different
things for their validation. Server side validation
should be for things like, "does the user exist?"
where as client should be, "is a user name entered?"

It's a balance and trade between the two. We need to
work out a good way of doing this. I don't want to
see struts become too bloated with functionality.

> This would worsen performance (handling exceptions is not particularly cheap) versus the
> current approach.

> 
> Also, there are also many sorts of error checks that depend on more than one field ("field B
> is required if field A is present, otherwise it must be blank").  The HTTP and servlet specs
> provide no guarantees on what order the request parameters are presented, so where do you
> put the checks for this?  In many cases, you are going to need a global validate() method of
> some sort anyway.

Um, yes. Good point. I didn't think of that.

I'll try and get my JavaScript validation library together,
clean it up and put it on my web site (which needs a good clean
up anyway).

And then write some stuff about how we could look at a client
side validation, that works with a server side one.

Re: thought on design

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.

Jim Richards wrote:

> > In 1.0, the validation model for the server side has been significantly enhanced.  The
> > idea of auto-generating JavaScript validation code for the things you can check on the
> > client side is attractive, but won't make Struts 1.0 (unless someone really hurries
> > and creates it :-).
>
> Hmm ... I am using a nightly build from about a week ago,
> I'll have to dig into it to see how this enhanced validation
> works (or is it not in there yet).
>

Looking at my sentence above, I see that I wasn't clear.

The server-side enhancement is that the validate() method is now called with the request and
the current mapping so that you have more context for making your validation decisions --
for example, you can go retrieve the user's session and get state information you've stored
there.

Support for auto-generating client side validation JavaScript is not there, and is unlikely
to be in the final 1.0 release.

>
> > I would caution you that, even if you implement client-side JavaScript validations,
> > your server side logic should not rely on them.  After all, the user can easily turn
> > off JavaScript, and/or write an application that simulates a browser's interactions
> > with the server but tries to bypass your edits.
>
> The client side validation is only for simple things,
> that validate() would do, such as checking for number
> format, empty strings, valida credit card number, post
> code and so on. The action bean would still need to check
> that, say a credit card was valid (rather then just a number).
>

I agree with using client-side validation where you can, to improve the UI by catching
errors earlier.  My caution is that you should plan on re-performing these checks as
appropriate on the server side.  Don't assume that your JavaScript validation actually took
place.

>

>
> >> Also, I couldn't work out how to get the request attributes
> >> to be sticky between the next and previous pages (think CGI.pm
> >> and it's param() functions). It's probably something to do
> >> with the response, but I don't have the docs handy.
> >>
> >
> > Sticky checkboxes have been fixed in 1.0 by adding a reset() method to the ActionForm
> > class.  You should reset any boolean properties to false in the reset() method, which
> > is called before the property populator -- which will set the checkbox back to true if
> > it was indeed checked.
>
> Hmm, I was thinking more about text fields and so on
> between multipage forms, not rebuilding the current
> form with the previous data.
>
> > I will take a look at your example, but there is a subtle philosophical issue that has
> > affected the way ActionForm beans are specified in Struts.
> >
> > Basically, an ActionForm is part of the presentation layer, not the model layer.
> > Their primary purpose is to encapsulate the current set of inputs that a user last
> > entered -- whether or not they are valid -- so that you can create an error page that
> > faithfully represents what *was* entered, and points out what needs to be changed
> > (just like GUI apps do).  Otherwise, you're going to force the user to have to
> > re-enter some of the fields, and that will not make you a popular person with your
> > user community.
>
> I suppose what I'd like is rather then having validate()
> being called, when each property has it's setXXX method
> called, the setXXX method does the simple validation, and
> throws a ProperyVetoException with the error message
> text as part of the Exception. Then if a try block
> cathces this, stacks up the error messages and calls
> the page again with these errors. It seems that from
> what I've seen, most validate() methods are the same.

This would worsen performance (handling exceptions is not particularly cheap) versus the
current approach.

Also, there are also many sorts of error checks that depend on more than one field ("field B
is required if field A is present, otherwise it must be blank").  The HTTP and servlet specs
provide no guarantees on what order the request parameters are presented, so where do you
put the checks for this?  In many cases, you are going to need a global validate() method of
some sort anyway.

Craig

Re: thought on design

Posted by Jim Richards <gr...@cyber4.org>.

> In 1.0, the validation model for the server side has been significantly enhanced.  The
> idea of auto-generating JavaScript validation code for the things you can check on the
> client side is attractive, but won't make Struts 1.0 (unless someone really hurries
> and creates it :-).

Hmm ... I am using a nightly build from about a week ago,
I'll have to dig into it to see how this enhanced validation
works (or is it not in there yet).

> I would caution you that, even if you implement client-side JavaScript validations,
> your server side logic should not rely on them.  After all, the user can easily turn
> off JavaScript, and/or write an application that simulates a browser's interactions
> with the server but tries to bypass your edits.

The client side validation is only for simple things,
that validate() would do, such as checking for number
format, empty strings, valida credit card number, post
code and so on. The action bean would still need to check
that, say a credit card was valid (rather then just a number).

>> Also, I couldn't work out how to get the request attributes
>> to be sticky between the next and previous pages (think CGI.pm
>> and it's param() functions). It's probably something to do
>> with the response, but I don't have the docs handy.
>> 
> 
> Sticky checkboxes have been fixed in 1.0 by adding a reset() method to the ActionForm
> class.  You should reset any boolean properties to false in the reset() method, which
> is called before the property populator -- which will set the checkbox back to true if
> it was indeed checked.

Hmm, I was thinking more about text fields and so on
between multipage forms, not rebuilding the current
form with the previous data.

> I will take a look at your example, but there is a subtle philosophical issue that has
> affected the way ActionForm beans are specified in Struts.
> 
> Basically, an ActionForm is part of the presentation layer, not the model layer.
> Their primary purpose is to encapsulate the current set of inputs that a user last
> entered -- whether or not they are valid -- so that you can create an error page that
> faithfully represents what *was* entered, and points out what needs to be changed
> (just like GUI apps do).  Otherwise, you're going to force the user to have to
> re-enter some of the fields, and that will not make you a popular person with your
> user community.

I suppose what I'd like is rather then having validate()
being called, when each property has it's setXXX method
called, the setXXX method does the simple validation, and
throws a ProperyVetoException with the error message
text as part of the Exception. Then if a try block
cathces this, stacks up the error messages and calls
the page again with these errors. It seems that from
what I've seen, most validate() methods are the same.

Re: thought on design

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.

Jim Richards wrote:

> Having had a look at struts for few weeks now, I have
> some thoughts based on other work I've done and what I'd
> like to see/do implemented.
>
> Just to start with, I do like it. It'll make development
> cleaner and easier. I would have done something similar
> based on Cold Fusion's fusebox model probably.
>
> The validation method in ActionForm.validate seems to me to
> being too simple. I'm used to JavaScript validation that is
> fairly similar (see attached html file). I do notice that
> there is some mention of this in the TODO list.
>

In 1.0, the validation model for the server side has been significantly enhanced.  The
idea of auto-generating JavaScript validation code for the things you can check on the
client side is attractive, but won't make Struts 1.0 (unless someone really hurries
and creates it :-).

I would caution you that, even if you implement client-side JavaScript validations,
your server side logic should not rely on them.  After all, the user can easily turn
off JavaScript, and/or write an application that simulates a browser's interactions
with the server but tries to bypass your edits.

>
> The main problem I see so far with validate is how it will
> work for mulitpage forms. The only way I can see that
> it'd work is by having a hidden field (or form submit value
> that would specify the page number and an if statement
> in the validate method that would check just the required
> values. This would tie the validate too closely to the HTML
> page.
>

Multipage forms are going to be pretty messy under most scenarios.  I generally
suggest a single ActionForm bean for the entire multipage form, but you are correct
that the validator needs to have some way to know what fields are on what pages.

>
> If you look at the example I've attached, you'll see that
> there are references to the pages in MultipageForm and
> MultipageAction, as well as validation that is tied to the
> pages. (The code could be cleaner, eg. more messages
> from the .properties file, better error checking,
> and cleaning out unused beans, formatting of the code ;-)
>
> I could write the code so it checks that a parameter is
> specified, but this will cause problems with check boxes and
> multiple select.

> Also, I couldn't work out how to get the request attributes
> to be sticky between the next and previous pages (think CGI.pm
> and it's param() functions). It's probably something to do
> with the response, but I don't have the docs handy.
>

Sticky checkboxes have been fixed in 1.0 by adding a reset() method to the ActionForm
class.  You should reset any boolean properties to false in the reset() method, which
is called before the property populator -- which will set the checkbox back to true if
it was indeed checked.

>
> What I'd like to see is better use of the Bean style, where
> we use PropertyVetoException and similar. It does mean
> writing a more stubborn bean container. But it'll be useful
> when it comes to using Beans developed for instant graphical
> interfaces. Since all my work has been back end work, I've
> only just got into Beans now after a long time in Servlets,
> EJB and Java 1.0 AWT programming.
>

I will take a look at your example, but there is a subtle philosophical issue that has
affected the way ActionForm beans are specified in Struts.

Basically, an ActionForm is part of the presentation layer, not the model layer.
Their primary purpose is to encapsulate the current set of inputs that a user last
entered -- whether or not they are valid -- so that you can create an error page that
faithfully represents what *was* entered, and points out what needs to be changed
(just like GUI apps do).  Otherwise, you're going to force the user to have to
re-enter some of the fields, and that will not make you a popular person with your
user community.

>
> Have fun ...
>
>   --------------------------------------------------------------------------------
>
>    validate.htmlName: validate.html
>                 Type: Hypertext Markup Language (text/html)
>
>                        Name: multipage.tar.gz
>    multipage.tar.gz    Type: VRML 2.0 (model/vrml)
>                    Encoding: base64
>
>   --------------------------------------------------------------------------------
> --
> Kumera - a new Open Source Content Management System
> for small to medium web sites written in Perl and using XML
> http://www.cyber4.org/kumera/index.html

Craig

thought on design

Posted by Jim Richards <gr...@cyber4.org>.

Having had a look at struts for few weeks now, I have
some thoughts based on other work I've done and what I'd
like to see/do implemented.

Just to start with, I do like it. It'll make development
cleaner and easier. I would have done something similar
based on Cold Fusion's fusebox model probably.

The validation method in ActionForm.validate seems to me to
being too simple. I'm used to JavaScript validation that is
fairly similar (see attached html file). I do notice that
there is some mention of this in the TODO list.

The main problem I see so far with validate is how it will
work for mulitpage forms. The only way I can see that
it'd work is by having a hidden field (or form submit value
that would specify the page number and an if statement
in the validate method that would check just the required
values. This would tie the validate too closely to the HTML
page.

If you look at the example I've attached, you'll see that
there are references to the pages in MultipageForm and
MultipageAction, as well as validation that is tied to the
pages. (The code could be cleaner, eg. more messages
from the .properties file, better error checking,
and cleaning out unused beans, formatting of the code ;-)

I could write the code so it checks that a parameter is
specified, but this will cause problems with check boxes and
multiple select.

Also, I couldn't work out how to get the request attributes
to be sticky between the next and previous pages (think CGI.pm
and it's param() functions). It's probably something to do
with the response, but I don't have the docs handy.

What I'd like to see is better use of the Bean style, where
we use PropertyVetoException and similar. It does mean
writing a more stubborn bean container. But it'll be useful
when it comes to using Beans developed for instant graphical
interfaces. Since all my work has been back end work, I've
only just got into Beans now after a long time in Servlets,
EJB and Java 1.0 AWT programming.

Have fun ...