You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Joel Trunick <Jo...@SmartPrice.com> on 2003/08/07 23:45:39 UTC
Practically Static Tapestry Pages
I have a bunch of practically static pages (about 70) that I would like to
turn into Tapestry pages (for click tracking, common header/footer
components, skinning). However, I don't really want the overhead of a Java
class and .page file for every single page.
Is there a way I can just have an .html file for each file (with no
.page/.class files)? I also would want every page to have a unique "static"
URL.
I'm guessing this may be possible with Tapestry 3.0, but wanted to make sure
it can be done before diving in.
Joel
Re: Practically Static Tapestry Pages
Posted by John Meredith <ps...@t-online.de>.
Hi Joel,
I'd probably attempt it this way: Write a little script to process each
HTML file, changing the static links to @PageLink, and generate a page
specification file which needn't be more than:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE page-specification PUBLIC "-//Apache Software
Foundation//Tapestry Specification 3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
<page-specification/>
Tapestry uses a the BasePage component as default (I belive) so this
should suffice.
I'd use perl as it's great for processing text files and has the best
HTML parser library I've come across: HTML::Parser, HTML::TreeBuilder
etc.
Click monitoring could conceivably be done via Tapestry's Monitor
functionality I guess - it's something that's one my todo list, but I
haven't gotten that far yet. I just use the Monitor to close my
Hibernate sessions at the moment.
As the it's "practically" a static site, I guess you won't be able to
avoid some manual input - but that depends on the structure of the site
in question, and how you parse the pages.
Skinning is something that I'm dearly wanting a solution to - I've made
a very embarrassing public attempt at trying to implement skinning (a
few days ago), and failed miserably - I think it may be possible with
3.1, but I'm not sure.
Anyway, just some thoughts. Best of luck.
- John
On Thu, 2003-08-07 at 23:45, Joel Trunick wrote:
> I have a bunch of practically static pages (about 70) that I would like to
> turn into Tapestry pages (for click tracking, common header/footer
> components, skinning). However, I don't really want the overhead of a Java
> class and .page file for every single page.
>
> Is there a way I can just have an .html file for each file (with no
> .page/.class files)? I also would want every page to have a unique "static"
> URL.
>
> I'm guessing this may be possible with Tapestry 3.0, but wanted to make sure
> it can be done before diving in.
>
> Joel
--
John Meredith <ps...@t-online.de>
Linking back to current page
Posted by Shantanu Deo <sh...@elixir-it.com>.
Hi,
We are using Paypal in our business process, and one of the things that
paypal allows is to specify a return url's, one to return to after a
successful transaction and another to return if he user cancels the
transaction while on PayPal's site.
My question is what do my pages's which have the PayPal button link have
to implement so I can have the user return back to the same place from where
he initiated the transaction.
Thanks in advance,
SD
Re: Do I really need to clear the validationDelegate?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
The default value for lifecycle is "request". Another doc-snippet from
the dtd.
Beans that have the "request" lifecycle may be stored into a pool
for later re-use (in the same or different page).
-Harish
Harish Krishnaswamy wrote:
> Beans have a lifecycle in Tapestry and it is configurable via the
> lifecycle attribute of the <bean.../> element. The following is a
> doc-snippet from the dtd.
>
> Attributes:
> name: the name of the bean
> class: the Java class to instantiate
> lifecycle: when the reference to the bean should be discard
> "none" no lifecycle, the bean is created and returned, but not
> stored
> "request" the bean is retained until the end of the request cycle
> "page" the bean is retained for the lifespan of the page
> "render" the bean is retained until the end of the current page
> render
>
> -Harish
>
> Bryan Lewis wrote:
>
>> I have a simple form including a date field, a ValidField.
>> (Page specification shown below.)
>>
>> It starts out fine... if the user enters a date with a syntax error,
>> we stay
>> on the same page. The user sees the red asterisks, corrects the data
>> and re-submits. The problem is, the page remembers the previous
>> error...
>> delegate.getHasErrors() still returns true.
>>
>> I've worked around the problem by doing delegate.clear() in detach(),
>> but that doesn't feel right. I've searched the list, source, and
>> docs, and
>> nobody else seems to need that... I suspect I'm missing something.
>>
>> .page:
>> <bean name="delegate"
>> class="org.apache.tapestry.valid.ValidationDelegate"/>
>>
>> <bean name="dateValidator"
>> class="org.apache.tapestry.valid.DateValidator">
>> <set-property name="required" expression="false"/>
>> <set-property name="maximum" expression="new
>> java.util.Date()"/>
>> </bean>
>>
>> <component id="dateField" type="ValidField">
>> <binding name="value" expression="data.lastPasswordDate"/>
>> <binding name="validator" expression="beans.dateValidator"/>
>> </component>
>>
>> .java:
>> public void detach()
>> {
>> validationDelegate.clear(); // forget previous error
>> super.detach();
>> }
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Do I really need to clear the validationDelegate?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> The more ya know, the easier it gets. Pretty soon I won't
> have any code left, just bindings. :-)
>
Tapestry: Java-less Web Components :-)
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
Re: Do I really need to clear the validationDelegate?
Posted by Bryan Lewis <br...@maine.rr.com>.
Thanks, I wasn't aware of that. But the problem turned out to be my misundertanding of how to allocate the delegate... I didn't need to bother with that in my code. I was doing:
public IValidationDelegate getValidationDelegate()
{
if (validationDelegate == null) { // doh! reusing the old one
validationDelegate = new ValidationDelegate();
}
return validationDelegate;
}
The Workbench's Fields example showed me the light -- call getBeans().getBean("delegate") when I need it, and let Tapestry handle the lifecycle for me.
The more ya know, the easier it gets. Pretty soon I won't have any code left, just bindings. :-)
----- Original Message -----
From: "Harish Krishnaswamy" <hk...@comcast.net>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Sunday, August 17, 2003 10:47 PM
Subject: Re: Do I really need to clear the validationDelegate?
> Beans have a lifecycle in Tapestry and it is configurable via the
> lifecycle attribute of the <bean.../> element. The following is a
> doc-snippet from the dtd.
>
> Attributes:
> name: the name of the bean
> class: the Java class to instantiate
> lifecycle: when the reference to the bean should be discard
> "none" no lifecycle, the bean is created and returned, but not stored
> "request" the bean is retained until the end of the request cycle
> "page" the bean is retained for the lifespan of the page
> "render" the bean is retained until the end of the current page render
>
> -Harish
>
> Bryan Lewis wrote:
>
> >I have a simple form including a date field, a ValidField.
> >(Page specification shown below.)
> >
> >It starts out fine... if the user enters a date with a syntax error, we stay
> >on the same page. The user sees the red asterisks, corrects the data
> >and re-submits. The problem is, the page remembers the previous error...
> >delegate.getHasErrors() still returns true.
> >
> >I've worked around the problem by doing delegate.clear() in detach(),
> >but that doesn't feel right. I've searched the list, source, and docs, and
> >nobody else seems to need that... I suspect I'm missing something.
> >
> > .page:
> > <bean name="delegate"
> >class="org.apache.tapestry.valid.ValidationDelegate"/>
> >
> > <bean name="dateValidator"
> >class="org.apache.tapestry.valid.DateValidator">
> > <set-property name="required" expression="false"/>
> > <set-property name="maximum" expression="new java.util.Date()"/>
> > </bean>
> >
> > <component id="dateField" type="ValidField">
> > <binding name="value" expression="data.lastPasswordDate"/>
> > <binding name="validator" expression="beans.dateValidator"/>
> > </component>
> >
> > .java:
> > public void detach()
> > {
> > validationDelegate.clear(); // forget previous error
> > super.detach();
> > }
> >
> >
> >
> >---------------------------------------------------------------------
> >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: Do I really need to clear the validationDelegate?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Beans have a lifecycle in Tapestry and it is configurable via the
lifecycle attribute of the <bean.../> element. The following is a
doc-snippet from the dtd.
Attributes:
name: the name of the bean
class: the Java class to instantiate
lifecycle: when the reference to the bean should be discard
"none" no lifecycle, the bean is created and returned, but not stored
"request" the bean is retained until the end of the request cycle
"page" the bean is retained for the lifespan of the page
"render" the bean is retained until the end of the current page render
-Harish
Bryan Lewis wrote:
>I have a simple form including a date field, a ValidField.
>(Page specification shown below.)
>
>It starts out fine... if the user enters a date with a syntax error, we stay
>on the same page. The user sees the red asterisks, corrects the data
>and re-submits. The problem is, the page remembers the previous error...
>delegate.getHasErrors() still returns true.
>
>I've worked around the problem by doing delegate.clear() in detach(),
>but that doesn't feel right. I've searched the list, source, and docs, and
>nobody else seems to need that... I suspect I'm missing something.
>
> .page:
> <bean name="delegate"
>class="org.apache.tapestry.valid.ValidationDelegate"/>
>
> <bean name="dateValidator"
>class="org.apache.tapestry.valid.DateValidator">
> <set-property name="required" expression="false"/>
> <set-property name="maximum" expression="new java.util.Date()"/>
> </bean>
>
> <component id="dateField" type="ValidField">
> <binding name="value" expression="data.lastPasswordDate"/>
> <binding name="validator" expression="beans.dateValidator"/>
> </component>
>
> .java:
> public void detach()
> {
> validationDelegate.clear(); // forget previous error
> super.detach();
> }
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
Do I really need to clear the validationDelegate?
Posted by Bryan Lewis <br...@maine.rr.com>.
I have a simple form including a date field, a ValidField.
(Page specification shown below.)
It starts out fine... if the user enters a date with a syntax error, we stay
on the same page. The user sees the red asterisks, corrects the data
and re-submits. The problem is, the page remembers the previous error...
delegate.getHasErrors() still returns true.
I've worked around the problem by doing delegate.clear() in detach(),
but that doesn't feel right. I've searched the list, source, and docs, and
nobody else seems to need that... I suspect I'm missing something.
.page:
<bean name="delegate"
class="org.apache.tapestry.valid.ValidationDelegate"/>
<bean name="dateValidator"
class="org.apache.tapestry.valid.DateValidator">
<set-property name="required" expression="false"/>
<set-property name="maximum" expression="new java.util.Date()"/>
</bean>
<component id="dateField" type="ValidField">
<binding name="value" expression="data.lastPasswordDate"/>
<binding name="validator" expression="beans.dateValidator"/>
</component>
.java:
public void detach()
{
validationDelegate.clear(); // forget previous error
super.detach();
}
RE: Practically Static Tapestry Pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Just put the HTML files into the context, as normal. Tapestry assumes that any HTML file in the
context is a Tapestry page, even if it doesn't have a .page file. You can still put implicit
components ("@Whatever") into place.
However, http://.../Foo.html will return the raw template to the browser, you'll need
http://.../app?service=page/Foo to access a particular page as a Tapestry page.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Joel Trunick [mailto:Joel@SmartPrice.com]
> Sent: Thursday, August 07, 2003 5:46 PM
> To: 'Tapestry users'
> Subject: Practically Static Tapestry Pages
>
>
>
> I have a bunch of practically static pages (about 70) that I
> would like to turn into Tapestry pages (for click tracking,
> common header/footer components, skinning). However, I don't
> really want the overhead of a Java class and .page file for
> every single page.
>
> Is there a way I can just have an .html file for each file
> (with no .page/.class files)? I also would want every page to
> have a unique "static" URL.
>
> I'm guessing this may be possible with Tapestry 3.0, but
> wanted to make sure it can be done before diving in.
>
> Joel
>