You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by "V. Cekvenich" <vi...@users.sourceforge.net> on 2002/09/17 16:48:29 UTC
X: Transform Performance
X Transform is very nice. But it could scale better.
One approach is browser side XSLT, such as
http://www.oroad.com/opencode/stxx/using_stxx_1.0.0.pdf.
Browser side XSLT would be fast since if you have 800 concurrent users,
each would have it's own xslt.
Any ideas on potential features in this direction of X: transform tag?
Thanks,
Vic
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: X: Transform Performance
Posted by Shawn Bayern <ba...@essentially.net>.
On Tue, 17 Sep 2002, V. Cekvenich wrote:
> It is very simple and very good, the X: transform! I use it quite a bit.
> (basicportal.sf.net of course X: transform + DAO + Struts)
>
> However, it is rendered on the server. Some of my clients have more than
> 1000 concurrent users, so I.... avoid XML, as much as I like it. Caching
> makes no sense in this case.
Caching might help if the input and stylesheet are often similar. See the
Jakarta Taglibs "Cache Taglib" for ways to cache transformations on the
server side. (JSTL implementations are also allowed to cache
transformations as aggressively as they like, presuming they still notice
changes to input documents and stylesheets.)
> What I have done before X: transform is used Netscape, Mozzila or IE
> to do XSLT. (Similar in design to HTML and CSS). I just sent the
> browser XML and reference to XSLT. It did the rest. (Older Browsers
> needed some JavaScript to do XSLT, mail archives have scripts).
> [...]
> What I would like to do is have 1000 clients each do it on their own
> browser. This way I of load processing to client. If a site gets more
> users, they also get more browsers, hence salability.
Indeed; this model makes sense. But this model is still available to you;
how do you think that JSTL can help, given that it runs on the server?
> (Ps. I also wish for standard tags in future to emit more javascript
> like javascript menus, javascript trees, javascript drop downs, etc.
> similar to struts menu or commons validator. )
JSTL has tended to avoid becoming dependent on particular browsers,
rendering models, and client-side logic. You might be interested in
following the JavaServer Faces specification, which moves closer to this
kind of rich client rendering.
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: X: Transform Performance
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
It is very simple and very good, the X: transform! I use it quite a bit.
(basicportal.sf.net of course X: transform + DAO + Struts)
However, it is rendered on the server. Some of my clients have more than
1000 concurrent users, so I.... avoid XML, as much as I like it. Caching
makes no sense in this case.
What I have done before X: transform is used Netscape, Mozzila or IE to
do XSLT. (Similar in design to HTML and CSS). I just sent the browser
XML and reference to XSLT. It did the rest. (Older Browsers needed some
JavaScript to do XSLT, mail archives have scripts).
To make the long story short... I can now use X: transform to have 1000
clients execute a XSLT on the server. Very Good!
What I would like to do is have 1000 clients each do it on their own
browser. This way I of load processing to client. If a site gets more
users, they also get more browsers, hence salability.
thanks ,
Vic
(Ps. I also wish for standard tags in future to emit more javascript
like javascript menus, javascript trees, javascript drop downs, etc.
similar to struts menu or commons validator. )
Shawn Bayern wrote:
> On Tue, 17 Sep 2002, V. Cekvenich wrote:
>
>
>>X Transform is very nice. But it could scale better.
>>
>>One approach is browser side XSLT, such as
>>http://www.oroad.com/opencode/stxx/using_stxx_1.0.0.pdf.
>>
>>Browser side XSLT would be fast since if you have 800 concurrent
>>users, each would have it's own xslt.
>>
>>Any ideas on potential features in this direction of X: transform tag?
>
>
> Interesting paper. What support for client-side transformations do you
> see as appropriate for a server-side technology like JSTL? To put it
> another way, how do you see JSTL simplifying what's already a fairly
> straightforward manual process to request that a client perform a
> transformation of XML it receives?
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by peter lin <pe...@labs.gte.com>.
glad to have you back from the conference :)
peter
Shawn Bayern wrote:
>
> On Fri, 11 Oct 2002, peter lin wrote:
>
> > Just wondering, when will the patch be released?
>
> I'm planning a new dot release for the Standard Taglib this weekend.
> Sorry for the delays -- I was away at a conference until yesterday.
>
> Shawn
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by Shawn Bayern <ba...@essentially.net>.
On Fri, 11 Oct 2002, peter lin wrote:
> Just wondering, when will the patch be released?
I'm planning a new dot release for the Standard Taglib this weekend.
Sorry for the delays -- I was away at a conference until yesterday.
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by peter lin <pe...@labs.gte.com>.
Just wondering, when will the patch be released?
thanks.
peter lin
Shawn Bayern wrote:
>
> On Mon, 30 Sep 2002, peter lin wrote:
>
> > any word on a possible release of 1.0.2 with the patch?
>
> Yeah, it's coming; I still have one bugfix I'd like to apply to the EL
> before then. Expect a 1.0.2 release sometime this week.
>
> --
> Shawn Bayern
> "JSTL in Action" http://www.jstlbook.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[info for tag users] - quirs with tomcat 4.1.x jspc
Posted by peter lin <pe...@labs.gte.com>.
I discovered a quirk with tomcat 4.1.x and jsp 1.1 tags and thought
others might find the information useful.
If you're using jakarta jsp 1.1 tags and plan on using tomcat 4.1.x jspc
to precompile your pages, you will need to remove the .tld file from the
jar. If you do not, it will cause tomcat/bin/jspc to throw a NPE.
peter lin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by Shawn Bayern <ba...@essentially.net>.
On Mon, 30 Sep 2002, peter lin wrote:
> any word on a possible release of 1.0.2 with the patch?
Yeah, it's coming; I still have one bugfix I'd like to apply to the EL
before then. Expect a 1.0.2 release sometime this week.
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by peter lin <pe...@labs.gte.com>.
any word on a possible release of 1.0.2 with the patch?
peter
Shawn Bayern wrote:
>
> Thanks for the suggestion, Peter. I'll review with the team and get back
> to you.
>
> Shawn
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: fmt tag patches on july 29?
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 26 Sep 2002, peter lin wrote:
> Does anyone know when a patch release will be tag with the patches
> commited by Jan Leuhe on the 29th? the date on 1.0.1 was 27, so it
> would be nice to get a patch released?
>
> I know there's a work around by turning off tag pooling in jasper2,
> but since the patch is already in cvs it's just a matter of tagging
> it.
Thanks for the suggestion, Peter. I'll review with the team and get back
to you.
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
fmt tag patches on july 29?
Posted by peter lin <pe...@labs.gte.com>.
Does anyone know when a patch release will be tag with the patches
commited by Jan Leuhe on the 29th? the date on 1.0.1 was 27, so it would
be nice to get a patch released?
I know there's a work around by turning off tag pooling in jasper2, but
since the patch is already in cvs it's just a matter of tagging it.
:)
peter lin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: X: Transform Performance
Posted by Shawn Bayern <ba...@essentially.net>.
On Tue, 17 Sep 2002, V. Cekvenich wrote:
> X Transform is very nice. But it could scale better.
>
> One approach is browser side XSLT, such as
> http://www.oroad.com/opencode/stxx/using_stxx_1.0.0.pdf.
>
> Browser side XSLT would be fast since if you have 800 concurrent
> users, each would have it's own xslt.
>
> Any ideas on potential features in this direction of X: transform tag?
Interesting paper. What support for client-side transformations do you
see as appropriate for a server-side technology like JSTL? To put it
another way, how do you see JSTL simplifying what's already a fairly
straightforward manual process to request that a client perform a
transformation of XML it receives?
--
Shawn Bayern
"JSTL in Action" http://www.jstlbook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>