RE: Does anyone know of a good file manager...
Hey Jim, There's nothing exactly like this at Apache. I know of two taglib that might be capable of what you want: http://www.xephyrus.com/taglibs/ http://www.windgazer.nl/projects/FileTagLib/ In my opinion the windgazer taglib is more suited to your needs, since Xephyrus' taglib is intended mainly at modifying files. Contact the author of the windgazer taglibs for a download. Good luck, Martin -Original Message- From: Jim Kennedy [mailto:[EMAIL PROTECTED] Sent: maandag 9 februari 2004 4:15 To: 'Tag Libraries Users List' Subject: Does anyone know of a good file manager... JSP tag lib? I want to display a list of files to the end user much like MS explorer. The files will be located in a directory on the server. The user will only be able to read and download the files. They will not be able to navigate, delete or edit. Thanks - 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: taglibs i/o or jstl core library
when i tested the c:import tag on my machine, it didn't work when pulled in the include page. i also tested it on the jsp page itself (not from the include page) and still got the same problem. this was on a unix sever so i then tested it on my local server (on a test app on win2000 pro), and still the images were broken. i cant figure it out because if i simply enter the url into my browser then it comes back with relative images etc no problem ??? i think the page is an html page created from a content managment system. its url (not the real one) is http://intranet.company.co.uk/sites/topnav/topnavheader?view=Administration so its creating html on the fly there is a section in the jstl documentation (section 7-64) that states some absolute URL resources may be incaccessible when using c:import. To provide access the JVM of the container should be started with the proper networking properties, eg proxyHost and proxyPort i've tested on both apps local windows and unix server though they're both running as stand alone tomcat 4.1 - do you know how i set the proxyhost and proxyPort in the jvm ? (so that i can tell the network people as they wont buy it otherwise - they operate an invisible proxy server and claim that it wont be this ) cheers chris At 16:18 07.02.2004 -0800, you wrote: On Thu, 5 Feb 2004, Chris Daly wrote: yes. i have an application with an include header.jsp file, and its using the c:redirect/ tag to go to the remote site then nothing happens in terms of header.jsp tag, this is missing from the browser page and appears to return nothing. That's not surprising. The redirect goes back to the browser, which will then request that page directly. Any output from the original request will be discarded, and replaced by the response from the redirected-to URL. in terms of the c:import tag it works ok if the url is simply entered into teh browser but if teh url is in an include tag then any relative image references are not to the imported url (which would be ok), but to the header include it seems. Is the page you're trying to include plain HTML, or is it also a JSP page? I'm wondering if there's something going on in a JSP page related to the original request URL that might be confusing things. -- Martin Cooper cheers At 08:19 05.02.2004 -0500, you wrote: Hang on, you lost me with the redirect problem. Are you saying that a JSP with something like: c:redirect url=http://java.sun.com// isn't working for you? I don't understand what you mean by, the app doesn't recognise it. Quoting Chris Daly [EMAIL PROTECTED]: thanks, i tried this on opera 6 for windows and it does not compute the base URI of the document per Section 14.14 of rfc2616. i tried using the jstl redirect tag but the app doesn't recognise it the header returns a blank and whats within the body tags takes up the space. it looks like a frameset within the header.jsp page is the only option. any other ideas ? cheers chris At 12:14 04.02.2004 -0500, you wrote: I've never used the IO taglib so I can't comment on it's abilities. The quick test I performed with JSTL's c:import failed to do what I think you're asking for (even when setting the Content-Location header). If you have access to either the Amaya or Opera browsers (as pointed to in the link I provided), you can verify if this is a browser issue. As for base: http://www.htmlhelp.com/reference/html40/head/base.html Quoting Chris Daly [EMAIL PROTECTED]: hi what i've done is imprt teh i/o tag library from http://jakarta.apache.org/taglibs/doc/io-doc/intro.htmland and am trying to use an existing include jsp to pull in the remote url and all relative image links using the io:request tag. I'm now looking at the jstl and url related actions and the c:import tag - would this work where io:request hasn't ? what do you mean by a resource that uses a base element - can you give an example ? cheers chris At 09:10 04.02.2004 -0500, you wrote: In theory, you might be able to do this by setting the Content-Location header to match the resource you're importing. In practice, however, this doesn't seem to be too well supported: http://jigsaw.w3.org/HTTP/CL/ Have you tried imorting a resource that uses a base element to see if that works? -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
RE: escapeXml() optimizations
The simplest optimization would be to create the 'sb' buffer
at least as big as the 'input' string. After all, even if
there were no actual substitutions, the 'sb' would be as big,
and this would avoid StringBuffer doing a lot of
reallocations, especially if 'input' is more than the 16
characters, the default capacity of a StringBuffer. This
could be accomplished with just something like:
Smart, and doesn't require much effort. Does this save a lot of time?
A more sophisticated optimization would require two loops.
The first would look very much like the existing loop, but no
'sb' StringBuffer would be created until one of the special
characters was found. The gamble is that the string
contains no characters to be escaped, no extra objects would
be created. It would look something like:
public static String escapeXml(String input) {
StringBuffer sb = null;
int length = input.length();
int currentPos;
for (int currentPos = 0; currentPos length; currentPos++) {
char c = input.charAt(currentPos);
if (c == '') {
sb = new StringBuffer(length+4);
sb.append(input.substring(0,currentPos)); //
copy over the string up until we found this char
sb.append(amp;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+3);
sb.append(input.substring(0,currentPos)); //
copy over the string up until we found this char
sb.append(lt;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+3);
sb.append(input.substring(0,currentPos)); //
copy over the string up until we found this char
sb.append(gt;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+5);
sb.append(input.substring(0,currentPos)); //
copy over the string up until we found this char
sb.append(#034;);
break;
}
else if (c == '\'') {
sb = new StringBuffer(length+5);
sb.append(input.substring(0,currentPos)); //
copy over the string up until we found this char
sb.append(#039;);
break;
}
}
// If we didn't create a new buffer, then the input
string didn't need any escaping so we win big time
// and we can just return the same string they gave
us (no object creation, no copying).
if ( sb == null )
return input;
// Oh well, we did have some escaping to do, so let's
check the rest to see if there are any more to do.
for ( ++currentPos; currentPos length; ++currentPos) {
char c = input.charAt(currentPos);
if (c == '')
sb.append(amp;);
else if (c == '')
sb.append(lt;);
else if (c == '')
sb.append(gt;);
else if (c == '')
sb.append(#034;);
else if (c == '\'')
sb.append(#039;);
else
sb.append(c);
}
return sb.toString();
}
Try it simpler:
public static String escapeXml(String input) {
StringBuffer sb = null;
int length = input.length();
int currentPos;
//Check if there are any special characters to escape
for (currentPos = 0; currentPos length; currentPos++) {
char c = input.charAt(currentPos);
if (c == '' || c == '' || c == '' || c == '' || c ==
'\'') {
sb = new StringBuffer(length);
sb.append(input.substring(0,currentPos)); // copy over
the string up until we found this char
break;
}
}
// If we didn't create a new buffer, then the input string
didn't need any escaping so we win big time
// and we can just return the same string they gave us (no
object creation, no copying).
if ( sb == null )
return input;
// Oh well, we did have some escaping to do, so let's check the
rest to see if there are any more to do.
for (; currentPos length;++currentPos) {
char c = input.charAt(currentPos);
if (c == '')
sb.append(amp;);
else if (c == '')
sb.append(lt;);
else if (c == '')
sb.append(gt;);
else if (c == '')
sb.append(#034;);
else if (c == '\'')
sb.append(#039;);
else
sb.append(c);
}
return sb.toString();
}
Martin
-
To unsubscribe, e-mail: [EMAIL
RE: xml parsing difference 1.1 vs 1.0
I suppose the main thing that needs to be determined is whether the performance
issue is with the way Standard is using Xalan or with Xalan itself. One
alternative approach you might take is to see if you can use XSLT instead. So,
you'd do something like:
c:import url=/WEB-INF/xslt/country.xsl var=xslt/
x:transform doc=${requestScope['jx.result']} xslt=${xslt}/
And then come up with the appropriate country.xsl stylesheet to do what you need.
I'm not sure why the switch was made from jaxen/SAXPath to Xalan though...
Quoting Wim Goossens [EMAIL PROTECTED]:
After changing the taglib URIs (and changing my web.xml),
I still got the same behaviour.
I put a timestamp before the x:parse ...
and before the x:forEach ... and after the /x:forEach
Indeed, it is not the parsing that takes the time, it is the
forEach loop.
I looked for a more recent version of Xalan, but could only find
version 2.5.2 (26/10/2003). Putting that xalan.jar in my lib directory
did not help (perhaps I should do more, but I am new to java and would not
know what to do else)
We are going in production with our software, 1/may/2004.
Is it wise to continue developping with 1.1 (what i want to do) and
expect everything to be ok by the time we go in production ???
(I consider this as a major bug and think it will be solved soon)
Would you advise another way to handle the xml data ???
Regards,
Wim
-Oorspronkelijk bericht-
Van: Kris Schneider [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 6 februari 2004 16:19
Aan: Tag Libraries Users List
Onderwerp: Re: xml parsing difference 1.1 vs 1.0
The taglib URIs are not the same for 1.0 and 1.1.
JSTL 1.0:
http://java.sun.com/jstl/core
http://java.sun.com/jstl/xml
JSTL 1.1:
http://java.sun.com/jsp/jstl/core
http://java.sun.com/jsp/jstl/xml
AFAIK, 1.0 and 1.1 parse XML the same way. What may have changed is the way
x:forEach is handled. For example, I think 1.1 uses Xalan as its XPath
engine
whereas 1.0 uses Jaxen/SAXPath. If possible, I guess you could try a more
recent
version of Xalan.
Quoting Wim Goossens [EMAIL PROTECTED]:
When I use the 1.1 standard and jstl jars, it takes ages to
complete an xml parsing. With standard 1.0 I get an
immediate result (for 300 records, for 20 records there is no problem).
What could i be doing wrong ?
(i am using tomcat 5.0.18 , j2sdk1.4.2_03)
This is my jsp code :
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%@ taglib prefix=x uri=http://java.sun.com/jstl/xml; %
(jx.result is a string containing the xml to parse)
x:parse varDom=dom xml=${requestScope['jx.result']} /
x:forEach var=country select=$dom/countrys/country
x:set var=id select=string($country/id/text())/
x:set var=description select=string($country/description/text())/
x:set var=countrycode select=string($country/countrycode/text())/
..
/x:forEach
c:remove var=dom/
Regards,
Wim
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: escapeXml() optimizations
Try it simpler: Yes, that's much nicer. See what happens when I tried to fit a solution in to the previous coding paradigm? wink This was better refactored and it certainly does the job much nicer. The only change I'd make is to make the StringBuffer size length+5 to ensure we can at least handle the largest substitution for the first escaping. That way, if there's only one escape to be done, you are positive the buffer is big enough, and you only have to fret about the buffer reallocations within StringBuffer if there are multiple such instances. I'm sure other techniques could be done, but they are probably overkill, like once one substition is found to be needed, the software could determine how many such substitutions are in the remaining input string to determine how much fudge to add to handle all escaping using something like length + (numberOfEscapableCharacters * 5). As to faster, much depends on your data input. For example, if your output strings tend to be 16 or fewer characters (unlikely in my book), then there's no improvement on the buffer side and a little extra processing would add some time. But for just about every other case, the benefits can be huge since a single buffer reallocation requires a new object to be created and the old buffer to be copied into the new buffer. Nice touch and I hope this gets added to the taglibs code so that we can all benefit.. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using input tag with sql
Hi I'm Andi, student of UF, new comer in apache tag library, and just try input tag (it's interesting ! ) i want to display list of items from database so user can select one of them. How to combine input:select with JSTL sql ? without need to write scriplet that retrieve items from database, put on Hashmap then use in options. Thanks Andi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with JSTL 1.1 and Tomcat 5 : UnresolvableException: $prefix:javax.servlet.include.query_string
The problem manifests itself when you have a c:import/c:import with a c:param that in turn has a c:import/ i.e. a c:import with parameters,in which the imported file has an empty tag c:import. an example : file : xml_test1.jsp %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % c:import url=/test/xml_test2.jspc:param name=test value=test//c:import file : xml_test2.jsp %@ taglib uri=http://java.sun.com/jstl/core; prefix=c % c:import url=/test/xml_test3.jsp/ file : xml_test3.jsp %@ taglib uri=http://java.sun.com/jsp/jstl/xml; prefix=x % x:parse var=xmlTest scope=request aaa id=a bbb id=b ccc id=c/ /bbb /aaa /x:parse x:set var=aaaId select=$xmlTest/aaa/@id scope=page/ Thanks, -a Kris Schneider wrote: Can you post a small example of a JSP that fails? Quoting Aadi Deshpande [EMAIL PROTECTED]: The latest build of Tomcat still has this problem, if anyone was following along. Thanks again for the help ; I'll try grepping the tomcat-users mailing list for some help. -a Aadi Deshpande wrote: See, I _knew_ I was overlooking something ( like a basic understanding of Bugzilla) ! Thanks, I'll check it out.. -a Kris Schneider wrote: The jakarta-tomcat-5-bin-20040203.zip build seems to work for me. The bug was reported *against* 5.0.18. Quoting Aadi Deshpande [EMAIL PROTECTED]: I've just upgraded to TC 5.0.18 and J2SDK 1.4.2_03. The problem persists in this environment as well, though the Bug ID that Kris gave was marked as resolved for 5.0.18, so maybe something more that I'm overlooking here? Thanks, -aadi Pierre Delisle wrote: To make things easier, make sure you run Tomcat using J2SE 1.4.2. You can find the details at: http://jakarta.apache.org/taglibs/doc/standard-doc/standard/GettingStarted.html -- Pierre Aadi Deshpande wrote: Hi, I'm tryin to use Tomcat 5 and the newly released JSTL 1.1 and I get the following error whenever I try to do a x:anything? I've gotten this same error under the Beta 1 running under Tomcat 5. Does anyone have any insight into why I would be getting this error? I thought the JSTL was tested under Tomcat 5, so I'm not sure what I am doing wrong. Thanks in advance for any help, -a org.apache.taglibs.standard.tag.common.xml.UnresolvableException: $prefix:javax.servlet.include.query_string org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.notull(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.getVariableValue(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil$JstlVariableContext.getVariableOrParam(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil.fillVarStack(Unknown Source) org.apache.taglibs.standard.tag.common.xml.XPathUtil.selectNodes(Unknown Source) org.apache.taglibs.standard.tag.common.xml.ForEachTag.prepare(Unknown Source) javax.servlet.jsp.jstl.core.LoopTagSupport.doStartTag(Unknown Source) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspx_meth_x_forEach_0(mom_005frewards_005fcallout_jsp.java:2138) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspx_meth_cms_randomSet_0(mom_005frewards_005fcallout_jsp.java:2113) org.apache.jsp.core.skeleton.mom_005frewards_005fcallout_jsp._jspService(mom_005frewards_005fcallout_jsp.java:134) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) org.apache.taglibs.standard.tag.common.core.ImportSupport.acquireString(Unknown Source) org.apache.taglibs.standard.tag.common.core.ImportSupport.doEndTag(Unknown Source) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_import_0(index_005fgrocerycardform_005fcallout_jsp.java:579) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_otherwise_0(index_005fgrocerycardform_005fcallout_jsp.java:555) org.apache.jsp.account.callouts.index_005fgrocerycardform_005fcallout_jsp._jspx_meth_c_choose_0(index_005fgrocerycardform_005fcallout_jsp.java:284)
RE: xml parsing difference 1.1 vs 1.0
Kris,
Thank you for the help.
I appreciate it a lot.
Using your XSLT approach indeed did solve my problem.
I am new to all this and have to study xslt now, but I think
I can do everything with it for writing the presentation layer.
Thank you very much
Regards
Wim
-Oorspronkelijk bericht-
Van: Kris Schneider [mailto:[EMAIL PROTECTED]
Verzonden: maandag 9 februari 2004 15:18
Aan: Tag Libraries Users List
Onderwerp: RE: xml parsing difference 1.1 vs 1.0
I suppose the main thing that needs to be determined is whether the
performance
issue is with the way Standard is using Xalan or with Xalan itself. One
alternative approach you might take is to see if you can use XSLT instead.
So,
you'd do something like:
c:import url=/WEB-INF/xslt/country.xsl var=xslt/
x:transform doc=${requestScope['jx.result']} xslt=${xslt}/
And then come up with the appropriate country.xsl stylesheet to do what you
need.
I'm not sure why the switch was made from jaxen/SAXPath to Xalan though...
Quoting Wim Goossens [EMAIL PROTECTED]:
After changing the taglib URIs (and changing my web.xml),
I still got the same behaviour.
I put a timestamp before the x:parse ...
and before the x:forEach ... and after the /x:forEach
Indeed, it is not the parsing that takes the time, it is the
forEach loop.
I looked for a more recent version of Xalan, but could only find
version 2.5.2 (26/10/2003). Putting that xalan.jar in my lib directory
did not help (perhaps I should do more, but I am new to java and would not
know what to do else)
We are going in production with our software, 1/may/2004.
Is it wise to continue developping with 1.1 (what i want to do) and
expect everything to be ok by the time we go in production ???
(I consider this as a major bug and think it will be solved soon)
Would you advise another way to handle the xml data ???
Regards,
Wim
-Oorspronkelijk bericht-
Van: Kris Schneider [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 6 februari 2004 16:19
Aan: Tag Libraries Users List
Onderwerp: Re: xml parsing difference 1.1 vs 1.0
The taglib URIs are not the same for 1.0 and 1.1.
JSTL 1.0:
http://java.sun.com/jstl/core
http://java.sun.com/jstl/xml
JSTL 1.1:
http://java.sun.com/jsp/jstl/core
http://java.sun.com/jsp/jstl/xml
AFAIK, 1.0 and 1.1 parse XML the same way. What may have changed is the
way
x:forEach is handled. For example, I think 1.1 uses Xalan as its XPath
engine
whereas 1.0 uses Jaxen/SAXPath. If possible, I guess you could try a more
recent
version of Xalan.
Quoting Wim Goossens [EMAIL PROTECTED]:
When I use the 1.1 standard and jstl jars, it takes ages to
complete an xml parsing. With standard 1.0 I get an
immediate result (for 300 records, for 20 records there is no problem).
What could i be doing wrong ?
(i am using tomcat 5.0.18 , j2sdk1.4.2_03)
This is my jsp code :
%@ taglib prefix=c uri=http://java.sun.com/jstl/core; %
%@ taglib prefix=x uri=http://java.sun.com/jstl/xml; %
(jx.result is a string containing the xml to parse)
x:parse varDom=dom xml=${requestScope['jx.result']} /
x:forEach var=country select=$dom/countrys/country
x:set var=id select=string($country/id/text())/
x:set var=description select=string($country/description/text())/
x:set var=countrycode select=string($country/countrycode/text())/
..
/x:forEach
c:remove var=dom/
Regards,
Wim
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
--
Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech http://www.dotech.com/
-
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]
