Re: Tags creating Tags
Lukas Bradley wrote: Hi all, Maybe I'm just tired, but the answer to this is not to be found. I could me making this harder than it is, or something might be right in front of me, and I don't see it. What I want is a custom tag that creates other custom tags. Here is a simple example: lukas:myTag lang=en / Should produce something like this: table trtdEnglish/td/tr trtdhtml:file property=formFile styleClass=FormField//td/tr !-- Imagine a lot more custom tags here -- /table Which should then evaluate to: table trtdEnglish/td/tr trtdinput type=file name=formFile value= class=FormField/td/tr !-- Imagine a lot more custom tags rendering here. -- /table I've thought about trying to extend BodyTagSupport, return EVAL_BODY_BUFFERED in doStartTag(), modify the bodyContent in doAfterBody(), then return EVAL_PAGE() in doEndTag(). However, BodyContent has a protected constructor, and no way to set its content. I want to maintain the functionality gained from Struts-like custom tags, while extracting the creation of them in a super-duper momma tag. Any help? It's not much help, except in the sense that it will put your search for the answer out of it's misery :-). What you are trying to do is not supported by JSP -- the reason is that custom tags are converted into appropriate method calls at page compile time. After that, they are just executed. To accomplish what you are after, you would need another layer of compilation. You'll need to come up with a different approach to accomplish what you are after. Lukas Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tags creating Tags
Lukas Bradley wrote: Ruth, Craig, and lurkers, I think what I'm after boils down to a method like this: public String renderTag(PageContext pPageContext, Tag pTagToRender) throws JspException A look at the JSP Specification will tell you that this would not work at all for a classic tag handler (i.e. implements Tag or implements BodyTag). After creating the tag manually, you could pass it to this method, and have it rendered. The return value of a String should be the final output of the Tag. The method would check for BodyTag, IterationTag, etc support, and react to it. This way, the user could embed custom tags (Struts or otherwise) within their own custom tags. I'm surprised a method like this doesn't already exist. This wouldn't be recursive, nor would it recompile on each shot. You may be right in calling this a tad hackish, but it would be useful, no? I can even think of another method that would be the incredi-hack: public String renderTag(PageContext pPageContext, Tag pTagToRender) throws JspException Where you pass in html:file / instead of the Tag object itself. Now that would be aggressive. For another approach, the JspFragment interface looks promising. However, I'm stuck with Tomcat 4.1 for now, so JSP 2.0 is out. I think the approach you suggest is problematic, for many of the reasons that Action chaining is problematic. The most serious issue is that you're trying to use a JSP artifact (a custom tag implementation class) for something it was never designed to do (be a reusable output generator outside the context of the very strict and complex lifecycle for tag instances described in the JSP specfiication). Hackish does not begin to describe how much trouble this kind of anti-object-oriented approach will lead you to in the long run. The right answer would be to create your own tag class that does exactly what you want. If your tag wants to leverage functionality from existing tag classes (and you don't want to cut-n-paste), either make your class a subclass of the existing one (presuming the stuff you need is already abstracted into useful protected methods), or abstract the stuff you need into utility classes that can be shared between your tag and the standard ones, and then lobby to have the same factoring done in the standard classes. This is the foundational basis on which all Struts tag classes are organized, and has proven to support a pretty rich library of tag class implementations that (in many cases) reuse or specialize protected methods in their subclasses. In no case was a generate a tag type of hack considered, because it's not necessary. All that's necessary is applying sound design practices for factoring reusable code into reusable chunks. I won't try to claim that we've done a perfect job at the current factoring, but the existence of something like struts-el (which was basically built on top of the existing tags, without having to rip them apart) is pretty good evidence that we're on the right track. Trying to interfere with the tag instance lifecycle that the JSP page compiler assumes pretty much guarantees you'll end up with disaster. Lukas Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form validation
Sam, One option for you to look at is the way that the Struts Framework http://jakarta.apache.org/struts deals with this issue -- it is one of the central organizing principles. Basically, it goes like this: * You define a form bean (an instance of ActionForm) that has properties matching the fields on your form. * The form bean has a validate() method, which can be used to return a set of error messages to the user. * The controller servlet automatically calls your validate() method and, if any errors are returned, the user is redirected back to the input page. (If there were no errors, the controller servlet would go ahead and call your business logic action.) * The input page redisplays, with your error messages and the previously entered values (so that the user only has to fix what is wrong). Because Struts uses JSP custom tags heavily, it plays nice with many of the Taglibs libraries (although there is some overlap in functionality with several of them). You might want to check it out. Craig McClanahan Sam Newman wrote: Hi all. I'm in the process of writing a web application to validate new users signing up to a service we provide. What I want to do is to take user input via a standard HTML form, validate the information on the client side, and if there are any errors redisplay the original page and inform the user of the problems. I am currently thinking of the following way to do this: 1.) Use the input-taglib to construct the form elements to create a form on form.jsp. 2.) Using the session-taglib, check the session when the form.jsp is loaded.If the session contains alternative values for the defaults specfied for the form, use them instead. 3.) Validation of the form will be carried out using a Servlet. One problem I have with this is that I'm going to have to pass back information to the page if there is an error to tell the user what they didn't do correctly. I could simply pass a string in I guess and display that in a pre-defined area on the jsp, but ideally I wanted to be able to issue an input-by-input report on the problems, and have the error message be displayed next to the incorrectly filled out form element. Do you think this is feasible? Does anyone have any comments on this proposed system? Also, any ideas on the best way to report errors to the user? I really want to keep the .jsp file as simple as possible, so I could easily get a web designer to change and edit the pages look and feel - that is I want as little java code as possible in the page. Ideally I'd like them to be ableto completely change the look of the page without having to touch the non-html stuff. sam p.s. Having just seen the article on form validation on javaworld, I would like to of used that instead, but it doen't allow usage in a commerical product :-(
Re: colName should be case insensitive?
Morgan Delagrange wrote:
Craig, is there a message here?
No, sorry ... I have to moderate messages onto TAGLIBS-USER (because of the idiot who
was broadcasting all the
spam on it a while back), and I accidentally did a reply on an actual message rather
than the moderation
request.
Craig
On Mon, 23 Apr 2001, Craig R. McClanahan wrote:
Nick Christopher wrote:
Newer sybase's are case sensitive with regards to object names (i.e.
tables/cols/indexes).
Morgan Delagrange wrote:
Good catch, I believe you are correct. I'll patch it up today.
- Morgan
On Thu, 19 Apr 2001, Dave Dribin wrote:
Hello,
I was just playing around with the 04/19 version of the JDBC tag
library and trying to run the example pages. I am using Oracle as a
back-end database and using a JNDI named datasource under Resin 1.2.3.
I am getting the following exception while running the jndijdbc.jsp
page:
javax.servlet.jsp.JspTagException: Could not find column named id
at
org.apache.taglibs.jdbc.resultset.BaseGetterTag.getColumnNumber(BaseGetterTag.java:245)
at
org.apache.taglibs.jdbc.resultset.BaseGetterTag.getPosition(BaseGetterTag.java:111)
at
org.apache.taglibs.jdbc.resultset.GetNumberTag.doStartTag(GetNumberTag.java:149)
I tracked down the problem to this line in the JSP:
tdsql:getNumber colName=id format=CURRENCY locale=en_GB//td
Now, it turns out that if I use all caps for the column name like ID
rather than id it works. I think this is due to the fact that I am
running Oracle and it is probably passing back the column names in all
caps regardless of how the table was created. However, colName should
probably be doing a case insensitive compare. I narrowed it down to
this bit of code in BaseGetterTag.java:
236for (int i = 1; i = cntColumn; i++) {
237 if (strName.equals (meta.getColumnName (i))) {
238return i;
239 }
240}
Changing line 237 to use String.equalsIgnoreCase() should fix it. SQL
is not case sensitive, right?
-Dave
Re: AW: How to use Connection Tag in JDBC
Stefan Riegel wrote:
Hi Jean,
I wondered too about DataSources and JNDI. I found a tutorial about JNDI on
the java.sun.com Site. I looked briefly through the Tutorial. It looks fine
for me. When I find time, I will try to learn the stuff. Perhaps an idea for
You too?
An additional place to learn about this would be in the Java2 Enterprise Edition
(J2EE) Specification, which you can download via http://java.sun.com/j2ee.
This specification defines (among other things) how data sources are made
available to applications in a portable way, across all J2EE-compatible
application servers, using the resource-ref element in the deployment
descriptor and using a JNDI context in your servlet.
For example, you might declare a resource reference like this in web.xml:
resource-ref
res-ref-namejdbc/EmployeeDatabase/res-ref-name
res-typejavax.sql.DataSource/res-type
res-authContainer/res-auth
/resource-ref
Then (assuming the system administrator has configured your server to provide an
appropriate connection pool (implementation of javax.sql.DataSource), you can
use this approach in your application:
javax.naming.Context ic = new InitialContext();
DataSource ds = (DataSource)
ic.lookup("java:comp/env/jdbc/EmployeeDatabase");
Connection conn = ds.getConnection();
... use this java.sql.Connection to do stuff ...
conn.close();
Note that your application does not have to mess with all of the details of
setting up the connection pool -- that is done for you by the server
adminstrator (using the deployment tools specific to that particular server).
Good luck
Stefan
Craig McClanahan
Re: Taglibs Plans?
On Tue, 10 Apr 2001, Dana Kaufman wrote: Pierre, Thank you for responding to my inquirary. I guess the root of these question come from a statement someone made to me. They mentioned that they read somewhere that Struts was going to be included in the next Sun J2EE specification. I could be wrong on this point as I have not read anything about it myself. That statement goes quite a ways beyond anything that *I* (as primary author of Struts) understand to be the case :-). Also, you can see the "Proposed Final Draft" version of the J2EE Specification (which qualifies as the "next" version in my book) by following the documentation links at http://java.sun.com/j2ee What you will see over time is some synching up between the web layer described in the J2EE Blueprints documents and the model suggested by Struts. But that is different from being part of the specification itself. It naturally brought up the question about future planning. What will be avaliable via all containers in the future, how do the various tag libs interact, what effect on one project does the inclusion of the other technologies in the specifications, etc? I believe you can count on the following: * At some point in time, all containers will support the "JSP Standard Tag Library" (or whatever the result of the JSR-052 effort is called) out of the box. Because the APIs for these tags will be standardized, you will likely see advanced containers make their JSP page compilers smart about the code they generate for these tags (in the same way that most containers understand things like jsp:useBean. But this will not make any difference to what the page author is free to use. * All custom tags that conform to the JSP 1.1 specification (which includes, but is not limited to, the tags that available in both Struts and Taglibs) will work on *all* JSP 1.1 containers. The compatibility story is fairly good already, and getting better all the time. Web applications will simply include the tag libraries they need (TLD and JAR files), and will work with no problems. * Custom tag libraries based on the JSP 1.1 specification will also work correctly on containers that implement the JSP 1.2 specification (currently in Proposed Final Draft statius), such as Tomcat 4.0 beta 3. The spec requires backwards compatibility for this, as well as for servlet 2.2 (JSP 1.2 goes hand in hand with Servlet 2.3). I see some overlap between Struts and the Taglibs project. I also saw the Standard Tag Libraries and wondered if it was the same project as Taglibs (or the intent to make the Taglibs project the standard). If Struts is truly going to be part of the new speifiations, it seems to make sense to sync up the two projects. Struts and Taglibs started at roughly the same time, but with different goals. Struts was aimed at being an "all in one" framework solution, while Taglibs was aimed at being a repository for libraries with (possibly) overlapping functionality. As Pierre mentions, there have been some discussions of abstracting out the non-framework-dependent tags in Struts, and migrating them to Taglibs. My personal view is that I'd rather migrate Struts users to the ultimately approved standard tags (in one move) rather than migrating to Taglibs and then to the standard -- but that decision is certainly open to the community for discussion. Both the Taglibs tags and the Struts tags are being examined in the JSR-052 process (along with other submissions). My personal belief is that the standard tags will end up being a synthesis of the best ideas from all sources, so they won't look precisely like any particular existing library. But, of course, the compatibility of custom tags across containers means that a developer can pick and choose what they want to use now, and migrate later if they want to. Regards, Dana Scott Kaufman Craig McClanahan
Re: SIGN OFF
Oleg Rostanin wrote: How can I sign off ? As has been repeated many times (including in the message you received confirming your subscription to this list, and on the Jakarta web site), you unsubscribe by sending an empty message to: [EMAIL PROTECTED] Craig McClanahan
Re: How to unsubscribe - because VIRUS around
Maya Muchnik wrote: For example, a virus with subjects "www.tomcat.com..." and or "multithreading ...", "Problem with Multithreading...". Inside email a text is starting with: Technically, what has been happening is not actually a virus -- but more on that after a status report. Current Status: no mail addressed to any apache.org list from the network domain that is the source of all of these messages is being accepted for delivery to any apache.org email address or mailing list. In addition, the TAGLIBS-USER list is being moderated so that we can ensure that the filtering is working correctly. Because of this, there might be a short delay before your postings to the list are actually visible. What appears to be going on is a single perpetrator (who isn't particularly smart, given the audit trail left in the message headers), who is doing the following: * Accumulating the addresses of list subscribers (easy to do if you just look at who has ever posted). * For each such subscriber, testing the mail server for that subscriber's access to see if it allows "relaying" -- a common technique that spam posters use to make other servers do the broadcasting of such messages. * For servers that allow relaying, sends forged messages to the mailing list that appear to be from the victims's mail address (so that the list will accept them). If your own email address is listed as the source of one or more of these messages, I would suggest that you consult the administrators of your mail domain to improve protection against relaying. Craig McClanahan
Re: Is it legal to have multiple taglib setter methods for the same property
IIRC, having two setters with different argument types violates the JavaBeans
specification. In addition, it seems to cause the Java reflection APIs to think that
there
is no setter method at all, so you will get complaints about a read-only property from
any
JSP implementation that uses this technique.
Craig McClanahan
Alex Tang wrote:
Hi folks. (My apologies for crossposting, I wasn't sure if this is a
taglib question or a tomcat question/problem)
I'm writing a taglib using the JSP 1.1 spec (currently Tomcat 3.x). I'm
having a problem with a property "set" method.
I have a taglib tag which takes one parameter: "index". This index can
be either the string "all" or a number representing which CLE object to
show.
I have the following defined in my tld file:
tag
namedisplayCLE/name
tagclasscom.funkware.DisplayCLETag/tagclass
teiclasscom.funkware.DisplayCLEExtraInfo/teiclass
infoDisplay a CLE/info
attribute
nameindex/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
/tag
In my "DisplayCLETag.java" file, I have the following:
/**
* !-- setIndex--
*
*Called when the taglib encounters an int for the index field...
*This form takes an int which happens when a jsp expression is
*evaluated on the right side of the "index=".
*
* @param nIndex
*The index
*/
public void setIndex ( int nIndex ) {
m_nIndex = nIndex;
}
/**
* !-- setIndex--
*
*Called when the taglib encounters the "index" parameter. This
*form takes an object. We try to convert and Integer and a
*String. Anything else we barf on.
*
* @param o
*An object which we'll try to convert.
*/
public void setIndex ( String s ) {
if ( SHOWELEMENT_ALL_STRING.equalsIgnoreCase ( s ) ) {
m_nIndex = SHOWELEMENT_ALL;
return;
}
try {
m_nIndex = Integer.parseInt ( s );
} catch ( NumberFormatException e ) {
Dispatcher.log ( Log.NOTICE, "DisplayListElementTag.setElement",
"The element: '" + s +
"' is invalid, it should be a number" );
m_nIndex = SHOWELEMENT_UNDEF;
}
}
The reason I have two setter methods for Index is that doing:
af:displayCLE index="1"/
is different than
af:displayCLE index="%= i %"/ !-- where i is an int and == 1 --
Is this a legal way of doing this?
I ask because when I run tomcat using the SunJDK1.3, it works fine,
however when I run tomcat with the SunJDK1.3 with Hotspot, it fails with
java.lang.NumberFormatException: all
at java.lang.Integer.parseInt(Integer.java:405)
at java.lang.Integer.(Integer.java:540)
at org.apache.jasper.runtime.JspRuntimeLibrary.convert \
(JspRuntimeLibrary.java:125)
at org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper \
(JspRuntimeLibrary.java:201)
at
ui.html._0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3._jspService \
(_0002fui_0002fhtml_0002fSList_0002ejspSList_jsp_3.java:274)
...
I don't actually think that is hotspot related. I think i'm doing
something wrong. I've looked through the tomcat code, however not too
particularly closely. I was hoping someone would know what's wrong.
In a somewhat unrelated question, I tried having my setIndex() method
defined as:
public void setIndex ( Object o )
and then doing internal "instanceof" calls and casting to proper
objects. This works in Tomcat 3.1, however it fails in Tomcat 4.0.
Did something change in JSP/Taglib 1.2 that makes that type of
declaration invalid?
Thanks very much.
...alex...
