You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Stephane Bailliez <sb...@apache.org> on 2002/03/20 07:51:57 UTC
[PATCH] T3 - DynamicURI
Patch offers some refactoring of DynamicURI to decrease a little bit the number of objects created via toString()/getA().
- changed Vector to ArrayList
- removed the boolean hasXXX in favor of !XXX.isEmpty()
- allocate initially some room for the StringBuffer rather than the default 16
- extracted renderQueryString and renderPathInfo into a renderPairs method
- couple of javadoc fixes.
I also replaced URLEncoder by URIUtil from commons-httpclient since URLEncoder is somewhat a performance killer (you will need a more recent version than the one that update-jars grab. 2.0rc is fine). A quick snapshot differencing via JProbe 4.0 beta reports that URIUtil is twice faster and creates 20% less objects.
Use at your own discretion.
Testcase is of course not complete...but hey, it's better than nothing :)
Re: [PATCH] T3 - DefaultResolver
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-03-21 at 13:29, Gareth Coltman wrote:
> All,
>
> Here is the patch for the default resolver to allow use of any template
> extension.
>
> In tr.props specify as:
>
> template.default.extension = myext
In T3 this is more a property of the view mechanism, so I'm not sure
this is the best place ... but i understand the problem. Will look into
it.
> i.e. NO period.
>
> Gareth
>
>
>
> cvs diff DefaultResolver.java (in directory
> C:\jakarta-turbine-3\src\java\org\apache\turbine\pipeline\)
> Index: DefaultResolver.java
> ===================================================================
> RCS file:
> /home/cvspublic/jakarta-turbine-3/src/java/org/apache/turbine/pipeline/Defau
> ltResolver.java,v
> retrieving revision 1.13
> diff -r1.13 DefaultResolver.java
> 232c232
> < String extension = ".vm";
> ---
> > String extension =
> Turbine.getConfiguration().getString("template.default.extension");
> 262c262
> < pckage.append("Default").append(extension);
> ---
> > pckage.append("Default").append(".").append(extension);
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] T3 - DefaultResolver
Posted by Gareth Coltman <ga...@majorband.co.uk>.
All,
Here is the patch for the default resolver to allow use of any template
extension.
In tr.props specify as:
template.default.extension = myext
i.e. NO period.
Gareth
cvs diff DefaultResolver.java (in directory
C:\jakarta-turbine-3\src\java\org\apache\turbine\pipeline\)
Index: DefaultResolver.java
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-3/src/java/org/apache/turbine/pipeline/Defau
ltResolver.java,v
retrieving revision 1.13
diff -r1.13 DefaultResolver.java
232c232
< String extension = ".vm";
---
> String extension =
Turbine.getConfiguration().getString("template.default.extension");
262c262
< pckage.append("Default").append(extension);
---
> pckage.append("Default").append(".").append(extension);
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] T3 - DynamicURI
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-03-21 at 11:44, Daniel Rall wrote:
> "Stephane Bailliez" <sb...@apache.org> writes:
>
> > Patch offers some refactoring of DynamicURI to decrease a little bit the number
> > of objects created via toString()/getA().
> >
> >
> >
> > - changed Vector to ArrayList
> >
> > - removed the boolean hasXXX in favor of !XXX.isEmpty()
> >
> > - allocate initially some room for the StringBuffer rather than the default 16
> >
> > - extracted renderQueryString and renderPathInfo into a renderPairs method
> >
> > - couple of javadoc fixes.
> >
> >
> >
> > I also replaced URLEncoder by URIUtil from commons-httpclient since URLEncoder
> > is somewhat a performance killer (you will need a more recent version than the
> > one that update-jars grab. 2.0rc is fine). A quick snapshot differencing via
> > JProbe 4.0 beta reports that URIUtil is twice faster and creates 20% less
> > objects.
>
> This sounds good to me. Thoughts from the rest of you?
+1
Add tests if you can stephane, that would be very much appreciate I
think it is extremely important to test the changes we're making in t3
to make sure the groundwork is solid.
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] T3 - DynamicURI
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephane Bailliez" <sb...@apache.org> writes:
> Patch offers some refactoring of DynamicURI to decrease a little bit the number
> of objects created via toString()/getA().
>
>
>
> - changed Vector to ArrayList
>
> - removed the boolean hasXXX in favor of !XXX.isEmpty()
>
> - allocate initially some room for the StringBuffer rather than the default 16
>
> - extracted renderQueryString and renderPathInfo into a renderPairs method
>
> - couple of javadoc fixes.
>
>
>
> I also replaced URLEncoder by URIUtil from commons-httpclient since URLEncoder
> is somewhat a performance killer (you will need a more recent version than the
> one that update-jars grab. 2.0rc is fine). A quick snapshot differencing via
> JProbe 4.0 beta reports that URIUtil is twice faster and creates 20% less
> objects.
This sounds good to me. Thoughts from the rest of you?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
T3 - FileResource Loader problem
Posted by Gareth Coltman <ga...@majorband.co.uk>.
I have a problem using the classic pipeline under T3, that I can't seem to
fix.
I want to change the file extension for my templates. I have found a number
of strange things:
After chaning the extensions from vm to my extension in the Turbine and
Fulcrum properties files, my first result was a null pointer error when the
TemplateService called templateExists.
Strange said I. I then tried adding the vm extention back to the list, i.e.
default.extention = myext,vm
Everything seemed to work great - templates with my extension were no
loading perfectly.
Then I noticed that while the classloader was successfully finding the
appropriate associated screen class, the fileresourceloader, was always
using the default layout (ie the one in the root layout dir) rather than the
one the corresponding directory. e.g.
If a requested: /template/test/test.myext
which corresponded on the filesystem to:
/templates/screens/test/test.myext
then I would expect the layouts to be searched in the following order:
1. /templates/layout/test/test.myext
2. /templates/layout/test/default.myext
3. /templates/layout/default.myext
but it always loads 3 even in 1 and 2 exist.
Has anyone else experienced this behaviour?
Gareth