You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Shawn Church <sh...@boxity.com> on 2004/09/21 00:28:56 UTC
Server side includes
Is there anything built into Tapestry or OGNL to allow for a simple
SSI? I know I could write something with the help of Velocity
(exercising #parse or #include), although it would be nice if I could
specify an absolute URI.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Shawn Church <sh...@boxity.com>.
Sitemesh looks interesting; I will definitely check it out. I don't
see a way off-hand to include static files outside of the webapp
context (with an absoulte URI), but I may have overlooked something.
Has anyone using Tapestry had good results with SiteMesh? I noticed a
report of a SiteMesh bug related to Tapestry URLs.
Thanks for the suggestion,
Shawn
Quoting Erik Hatcher <er...@ehatchersolutions.com>:
> Give SiteMesh a try. It may be just the solution you're looking
> for.
>
> http://www.opensymphony.com/sitemesh/
>
> Erik
>
>
> On Sep 21, 2004, at 11:15 AM, Shawn Church wrote:
>
> > Kurt,
> >
> > Yes, we unfortunately have quite a mix. I've inherited a couple
> of
> > old .asp-based sites/apps, we use Net.Data (if you've ever heard
> of
> > that), which is a cgi-based scripting language running on an
> > iSeries/AS/400, and we have a half-dozen or so separate static
> sites.
> > My designer who works mainly on the static sites has cleaned them
> up
> > quite a lot so they now all use SSI, and he has only three or so
> > source include areas (providing headers, footers, and left
> navigation).
> >
> > With Velocity I tended to run uncached, since the performance
> penalty
> > is insignificant. However, with Tapestry, uncached template
> > performance is unacceptable, and it is silly to have to redeploy
> all
> > my Tapestry apps every time every time my designer changes a nav
> link.
> >
> > I really like Tapestry, and it has worked very well for me, but my
> > biggest disappointment is in the area of page caching. My primary
> > reason for moving away from Velocity in favor of Tapestry was that
> the
> > Velocity templates were not legal HTML, and my designer who uses
> > Dreamweaver exclusively had a hard time editing Velocity
> templates.
> > Unfortunately, even though Tapestry uses pure HTML, my designer
> has
> > never touched any of these pages because he really has no clean way
> of
> > deploying them.
> >
> > The Tapestry framework provides a nice SoC model, where Velocity
> is
> > just a templating system, but I've written enough code (and have
> > developed enough of my own reusable implementations) that dealing
> with
> > forms, security, internalization and localization, etc. is not a
> big
> > deal. The view layer itself has always been the area I spend the
> most
> > time dinking around, and it would be nice to let other people have
> > some responsibility for presentation.
> >
> > So, the need for a brain-dead (ie - static, no
> Tapestry-page-caching
> > required) SSI-implementation which can pull from one of our
> existing
> > SSI locations is very important. Not all of my Tapestry-based
> apps
> > will need to include the general nav stuff, and I suppose I could
> run
> > those that do in a frame, but yuck. I don't mind extending
> Tapestry
> > myself, but I would be surprised if this doesn't already exist
> > somewhere (if not in the core).
> >
> > My goal is to eventually migrate all the .asp and Net.Data stuff
> to
> > Java, but I need to be able to slot in many relatively small
> Tapestry
> > apps as seamlessly as possible and to ensure I am not locked in
> > forever to babysitting design changes myself. This will become
> more
> > of an issue going forward since in addition to English, we are
> having
> > everything translated into Spanish and Russian.
> >
> > Thanks,
> > Shawn
> >
> >
> > Quoting Kurt Zoglmann <zo...@yahoo.com>:
> >
> >> Out of curiosity, why do you need to have a server side include?
> I've
> >>
> >> used simple server side includes before (never used Velocity) and
> I
> >> haven't had a need for them using Tapestry. Are you in some kind
> of
> >> mixed web app environment?
> >>
> >> On Sep 20, 2004, at 5:28 PM, Shawn Church wrote:
> >>
> >>> Is there anything built into Tapestry or OGNL to allow for a
> >> simple
> >>> SSI? I know I could write something with the help of Velocity
> >>> (exercising #parse or #include), although it would be nice if I
> >> could
> >>> specify an absolute URI.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >> tapestry-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Give SiteMesh a try. It may be just the solution you're looking for.
http://www.opensymphony.com/sitemesh/
Erik
On Sep 21, 2004, at 11:15 AM, Shawn Church wrote:
> Kurt,
>
> Yes, we unfortunately have quite a mix. I've inherited a couple of
> old .asp-based sites/apps, we use Net.Data (if you've ever heard of
> that), which is a cgi-based scripting language running on an
> iSeries/AS/400, and we have a half-dozen or so separate static sites.
> My designer who works mainly on the static sites has cleaned them up
> quite a lot so they now all use SSI, and he has only three or so
> source include areas (providing headers, footers, and left navigation).
>
> With Velocity I tended to run uncached, since the performance penalty
> is insignificant. However, with Tapestry, uncached template
> performance is unacceptable, and it is silly to have to redeploy all
> my Tapestry apps every time every time my designer changes a nav link.
>
> I really like Tapestry, and it has worked very well for me, but my
> biggest disappointment is in the area of page caching. My primary
> reason for moving away from Velocity in favor of Tapestry was that the
> Velocity templates were not legal HTML, and my designer who uses
> Dreamweaver exclusively had a hard time editing Velocity templates.
> Unfortunately, even though Tapestry uses pure HTML, my designer has
> never touched any of these pages because he really has no clean way of
> deploying them.
>
> The Tapestry framework provides a nice SoC model, where Velocity is
> just a templating system, but I've written enough code (and have
> developed enough of my own reusable implementations) that dealing with
> forms, security, internalization and localization, etc. is not a big
> deal. The view layer itself has always been the area I spend the most
> time dinking around, and it would be nice to let other people have
> some responsibility for presentation.
>
> So, the need for a brain-dead (ie - static, no Tapestry-page-caching
> required) SSI-implementation which can pull from one of our existing
> SSI locations is very important. Not all of my Tapestry-based apps
> will need to include the general nav stuff, and I suppose I could run
> those that do in a frame, but yuck. I don't mind extending Tapestry
> myself, but I would be surprised if this doesn't already exist
> somewhere (if not in the core).
>
> My goal is to eventually migrate all the .asp and Net.Data stuff to
> Java, but I need to be able to slot in many relatively small Tapestry
> apps as seamlessly as possible and to ensure I am not locked in
> forever to babysitting design changes myself. This will become more
> of an issue going forward since in addition to English, we are having
> everything translated into Spanish and Russian.
>
> Thanks,
> Shawn
>
>
> Quoting Kurt Zoglmann <zo...@yahoo.com>:
>
>> Out of curiosity, why do you need to have a server side include? I've
>>
>> used simple server side includes before (never used Velocity) and I
>> haven't had a need for them using Tapestry. Are you in some kind of
>> mixed web app environment?
>>
>> On Sep 20, 2004, at 5:28 PM, Shawn Church wrote:
>>
>>> Is there anything built into Tapestry or OGNL to allow for a
>> simple
>>> SSI? I know I could write something with the help of Velocity
>>> (exercising #parse or #include), although it would be nice if I
>> could
>>> specify an absolute URI.
>>>
>>> Thanks,
>>> Shawn
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Shawn Church <sh...@boxity.com>.
Kurt,
This looks like a good way to handle it using an existing (@Insert)
component. I wonder if it would be worth writing a custom component
(eg - @Include).
I will also check out SiteMesh.
Thanks,
Shawn
Quoting Kurt Zoglmann <zo...@yahoo.com>:
> If your need is for something really simple, you could probably
> implement it yourself without too much work. What's below is the
> first
> idea that came to me.
>
> include.html
> <span jwcid="@Insert" value="ognl:content" raw="true"/>
>
> include.jwc
> <component-specification class="package.Include" allow-body="yes"
> allow-informal-parameters="no">
> <parameter name="name" type="java.lang.String" required="true"/>
>
> <property-specification name="content" type="java.lang.String"/>
> </component>
>
> Include.java
>
> //use JCS or EHcache to store/cache stuff
>
> protected void prepareForRender() {
> String content;
> //check if in cache
> //load from filesystem if not in cache and place in cache
> setContent(content);
> }
>
> public abstract void setContent(String content);
> public abstract String getName();
>
> I'm no expert, but that's my two cents. :)
>
> On Sep 21, 2004, at 10:15 AM, Shawn Church wrote:
>
> > Kurt,
> >
> > Yes, we unfortunately have quite a mix. I've inherited a couple
> of
> > old .asp-based sites/apps, we use Net.Data (if you've ever heard
> of
> > that), which is a cgi-based scripting language running on an
> > iSeries/AS/400, and we have a half-dozen or so separate static
> sites.
> > My designer who works mainly on the static sites has cleaned them
> up
> > quite a lot so they now all use SSI, and he has only three or so
> > source include areas (providing headers, footers, and left
> navigation).
> >
> > With Velocity I tended to run uncached, since the performance
> penalty
> > is insignificant. However, with Tapestry, uncached template
> > performance is unacceptable, and it is silly to have to redeploy
> all
> > my Tapestry apps every time every time my designer changes a nav
> link.
> >
> > I really like Tapestry, and it has worked very well for me, but my
> > biggest disappointment is in the area of page caching. My primary
> > reason for moving away from Velocity in favor of Tapestry was that
> the
> > Velocity templates were not legal HTML, and my designer who uses
> > Dreamweaver exclusively had a hard time editing Velocity
> templates.
> > Unfortunately, even though Tapestry uses pure HTML, my designer
> has
> > never touched any of these pages because he really has no clean way
> of
> > deploying them.
> >
> > The Tapestry framework provides a nice SoC model, where Velocity
> is
> > just a templating system, but I've written enough code (and have
> > developed enough of my own reusable implementations) that dealing
> with
> > forms, security, internalization and localization, etc. is not a
> big
> > deal. The view layer itself has always been the area I spend the
> most
> > time dinking around, and it would be nice to let other people have
> > some responsibility for presentation.
> >
> > So, the need for a brain-dead (ie - static, no
> Tapestry-page-caching
> > required) SSI-implementation which can pull from one of our
> existing
> > SSI locations is very important. Not all of my Tapestry-based
> apps
> > will need to include the general nav stuff, and I suppose I could
> run
> > those that do in a frame, but yuck. I don't mind extending
> Tapestry
> > myself, but I would be surprised if this doesn't already exist
> > somewhere (if not in the core).
> >
> > My goal is to eventually migrate all the .asp and Net.Data stuff
> to
> > Java, but I need to be able to slot in many relatively small
> Tapestry
> > apps as seamlessly as possible and to ensure I am not locked in
> > forever to babysitting design changes myself. This will become
> more
> > of an issue going forward since in addition to English, we are
> having
> > everything translated into Spanish and Russian.
> >
> > Thanks,
> > Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Kurt Zoglmann <zo...@yahoo.com>.
If your need is for something really simple, you could probably
implement it yourself without too much work. What's below is the first
idea that came to me.
include.html
<span jwcid="@Insert" value="ognl:content" raw="true"/>
include.jwc
<component-specification class="package.Include" allow-body="yes"
allow-informal-parameters="no">
<parameter name="name" type="java.lang.String" required="true"/>
<property-specification name="content" type="java.lang.String"/>
</component>
Include.java
//use JCS or EHcache to store/cache stuff
protected void prepareForRender() {
String content;
//check if in cache
//load from filesystem if not in cache and place in cache
setContent(content);
}
public abstract void setContent(String content);
public abstract String getName();
I'm no expert, but that's my two cents. :)
On Sep 21, 2004, at 10:15 AM, Shawn Church wrote:
> Kurt,
>
> Yes, we unfortunately have quite a mix. I've inherited a couple of
> old .asp-based sites/apps, we use Net.Data (if you've ever heard of
> that), which is a cgi-based scripting language running on an
> iSeries/AS/400, and we have a half-dozen or so separate static sites.
> My designer who works mainly on the static sites has cleaned them up
> quite a lot so they now all use SSI, and he has only three or so
> source include areas (providing headers, footers, and left navigation).
>
> With Velocity I tended to run uncached, since the performance penalty
> is insignificant. However, with Tapestry, uncached template
> performance is unacceptable, and it is silly to have to redeploy all
> my Tapestry apps every time every time my designer changes a nav link.
>
> I really like Tapestry, and it has worked very well for me, but my
> biggest disappointment is in the area of page caching. My primary
> reason for moving away from Velocity in favor of Tapestry was that the
> Velocity templates were not legal HTML, and my designer who uses
> Dreamweaver exclusively had a hard time editing Velocity templates.
> Unfortunately, even though Tapestry uses pure HTML, my designer has
> never touched any of these pages because he really has no clean way of
> deploying them.
>
> The Tapestry framework provides a nice SoC model, where Velocity is
> just a templating system, but I've written enough code (and have
> developed enough of my own reusable implementations) that dealing with
> forms, security, internalization and localization, etc. is not a big
> deal. The view layer itself has always been the area I spend the most
> time dinking around, and it would be nice to let other people have
> some responsibility for presentation.
>
> So, the need for a brain-dead (ie - static, no Tapestry-page-caching
> required) SSI-implementation which can pull from one of our existing
> SSI locations is very important. Not all of my Tapestry-based apps
> will need to include the general nav stuff, and I suppose I could run
> those that do in a frame, but yuck. I don't mind extending Tapestry
> myself, but I would be surprised if this doesn't already exist
> somewhere (if not in the core).
>
> My goal is to eventually migrate all the .asp and Net.Data stuff to
> Java, but I need to be able to slot in many relatively small Tapestry
> apps as seamlessly as possible and to ensure I am not locked in
> forever to babysitting design changes myself. This will become more
> of an issue going forward since in addition to English, we are having
> everything translated into Spanish and Russian.
>
> Thanks,
> Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Shawn Church <sh...@boxity.com>.
Kurt,
Yes, we unfortunately have quite a mix. I've inherited a couple of
old .asp-based sites/apps, we use Net.Data (if you've ever heard of
that), which is a cgi-based scripting language running on an
iSeries/AS/400, and we have a half-dozen or so separate static sites.
My designer who works mainly on the static sites has cleaned them up
quite a lot so they now all use SSI, and he has only three or so
source include areas (providing headers, footers, and left navigation).
With Velocity I tended to run uncached, since the performance penalty
is insignificant. However, with Tapestry, uncached template
performance is unacceptable, and it is silly to have to redeploy all
my Tapestry apps every time every time my designer changes a nav link.
I really like Tapestry, and it has worked very well for me, but my
biggest disappointment is in the area of page caching. My primary
reason for moving away from Velocity in favor of Tapestry was that the
Velocity templates were not legal HTML, and my designer who uses
Dreamweaver exclusively had a hard time editing Velocity templates.
Unfortunately, even though Tapestry uses pure HTML, my designer has
never touched any of these pages because he really has no clean way of
deploying them.
The Tapestry framework provides a nice SoC model, where Velocity is
just a templating system, but I've written enough code (and have
developed enough of my own reusable implementations) that dealing with
forms, security, internalization and localization, etc. is not a big
deal. The view layer itself has always been the area I spend the most
time dinking around, and it would be nice to let other people have
some responsibility for presentation.
So, the need for a brain-dead (ie - static, no Tapestry-page-caching
required) SSI-implementation which can pull from one of our existing
SSI locations is very important. Not all of my Tapestry-based apps
will need to include the general nav stuff, and I suppose I could run
those that do in a frame, but yuck. I don't mind extending Tapestry
myself, but I would be surprised if this doesn't already exist
somewhere (if not in the core).
My goal is to eventually migrate all the .asp and Net.Data stuff to
Java, but I need to be able to slot in many relatively small Tapestry
apps as seamlessly as possible and to ensure I am not locked in
forever to babysitting design changes myself. This will become more
of an issue going forward since in addition to English, we are having
everything translated into Spanish and Russian.
Thanks,
Shawn
Quoting Kurt Zoglmann <zo...@yahoo.com>:
> Out of curiosity, why do you need to have a server side include? I've
>
> used simple server side includes before (never used Velocity) and I
> haven't had a need for them using Tapestry. Are you in some kind of
> mixed web app environment?
>
> On Sep 20, 2004, at 5:28 PM, Shawn Church wrote:
>
> > Is there anything built into Tapestry or OGNL to allow for a
> simple
> > SSI? I know I could write something with the help of Velocity
> > (exercising #parse or #include), although it would be nice if I
> could
> > specify an absolute URI.
> >
> > Thanks,
> > Shawn
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Server side includes
Posted by Kurt Zoglmann <zo...@yahoo.com>.
Out of curiosity, why do you need to have a server side include? I've
used simple server side includes before (never used Velocity) and I
haven't had a need for them using Tapestry. Are you in some kind of
mixed web app environment?
On Sep 20, 2004, at 5:28 PM, Shawn Church wrote:
> Is there anything built into Tapestry or OGNL to allow for a simple
> SSI? I know I could write something with the help of Velocity
> (exercising #parse or #include), although it would be nice if I could
> specify an absolute URI.
>
> Thanks,
> Shawn
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org