You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Hensley, Richard" <Ri...@McKesson.com> on 2004/06/23 18:27:02 UTC
Using Groovy to implement pages
I've been goofing around with using Groovy to implement pages for Tapestry.
I've created an extension of DefaultResourceResolver that loads Groovy
scripts dynamically and returns the classes. I've called this
GroovyResourceResolver.
I also implemented an extension to ApplicationServlet called
GroovyApplicationServlet that overrides createResourceResolver and creates
an instance of GroovyResourceResolver.
The basic premise is that anywhere you provide a class name, you can provide
a groovy script. So, a page could be something like:
<page-specification class="SignInPage.groovy">
</page-specification>
The GroovyResourceResolver does the following:
finds the script on the class path
If the script has been compiled and is not stale, return it
Else compile the script, return it
A basic groovy script in this context looks something like:
import org.apache.tapestry.html.BasePage
import org.apache.tapestry.IRequestCycle
class SignInPage extends BasePage {
String userId
String password
public void doLogin(IRequestCycle cycle) {
user = global.security.authenticate(userId, password);
visit.setUser(user);
}
}
The doLogin is viewed as a listener by Tapestry. The userId and password are
viewed as full on bean properties by Tapestry. All in all, it works out
pretty good. As far as I can tell, the class is not enhanced by Tapestry,
however I don't think it would make a difference.
Now I have a couple of questions.
I would like to load the .groovy script from the same place as the
specification that referenced it, but I don't seem to have the right
information in the IResourceResolver. What would be the best way to
implement this?
Is anybody else interested in this code?
Where should I post the code? Does this list accept .tar.gz files? It's not
much code.
Richard Hensley
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Using Groovy to implement pages
Posted by Adam Greene <ag...@iq-2000.com>.
I would be interested in the code.
----- Original Message -----
From: "Hensley, Richard" <Ri...@McKesson.com>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Wednesday, June 23, 2004 1:27 PM
Subject: Using Groovy to implement pages
> I've been goofing around with using Groovy to implement pages for
Tapestry.
> I've created an extension of DefaultResourceResolver that loads Groovy
> scripts dynamically and returns the classes. I've called this
> GroovyResourceResolver.
>
> I also implemented an extension to ApplicationServlet called
> GroovyApplicationServlet that overrides createResourceResolver and creates
> an instance of GroovyResourceResolver.
>
> The basic premise is that anywhere you provide a class name, you can
provide
> a groovy script. So, a page could be something like:
>
> <page-specification class="SignInPage.groovy">
>
> </page-specification>
>
> The GroovyResourceResolver does the following:
>
> finds the script on the class path
> If the script has been compiled and is not stale, return it
> Else compile the script, return it
>
> A basic groovy script in this context looks something like:
>
> import org.apache.tapestry.html.BasePage
> import org.apache.tapestry.IRequestCycle
>
> class SignInPage extends BasePage {
>
> String userId
> String password
>
> public void doLogin(IRequestCycle cycle) {
> user = global.security.authenticate(userId, password);
> visit.setUser(user);
> }
> }
>
> The doLogin is viewed as a listener by Tapestry. The userId and password
are
> viewed as full on bean properties by Tapestry. All in all, it works out
> pretty good. As far as I can tell, the class is not enhanced by Tapestry,
> however I don't think it would make a difference.
>
> Now I have a couple of questions.
>
> I would like to load the .groovy script from the same place as the
> specification that referenced it, but I don't seem to have the right
> information in the IResourceResolver. What would be the best way to
> implement this?
>
> Is anybody else interested in this code?
>
> Where should I post the code? Does this list accept .tar.gz files? It's
not
> much code.
>
> Richard Hensley
>
>
> ---------------------------------------------------------------------
> 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: Using Groovy to implement pages
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Might be possible to create a wrapper bean that implements IActionListener and delegates to a Groovy
script.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Michael Henderson [mailto:mhinca@mac.com]
> Sent: Wednesday, June 23, 2004 12:52 PM
> To: Tapestry users
> Subject: Re: Using Groovy to implement pages
>
>
> Hi,
>
>
> I would like to see it. I experimented with Groovy for scripting
> listeners (with <listener-binding>)
>
> I used a Context Listener to add groovy as a language to BSF Manager
> and wrote a simple groovy script
> for a listener binding.
>
> I'd like to be able to declare
> listener="script:someScriptFileName.groovy" in implicit components
> and never have to write a java class for components. With a suite of
> sufficiently rich Spring or HiveMind services
> to I should be able to keep listeners pretty simple.
>
>
> Mike
>
>
> ---------------------------------------------------------------------
> 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: Using Groovy to implement pages
Posted by Michael Henderson <mh...@mac.com>.
Hi,
I would like to see it. I experimented with Groovy for scripting
listeners (with <listener-binding>)
I used a Context Listener to add groovy as a language to BSF Manager
and wrote a simple groovy script
for a listener binding.
I'd like to be able to declare
listener="script:someScriptFileName.groovy" in implicit components
and never have to write a java class for components. With a suite of
sufficiently rich Spring or HiveMind services
to I should be able to keep listeners pretty simple.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Using Groovy to implement pages
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El mié, 23-06-2004 a las 13:27, Hensley, Richard escribió:
> A basic groovy script in this context looks something like:
>
> import org.apache.tapestry.html.BasePage
> import org.apache.tapestry.IRequestCycle
>
> class SignInPage extends BasePage {
>
> String userId
> String password
>
> public void doLogin(IRequestCycle cycle) {
> user = global.security.authenticate(userId, password);
> visit.setUser(user);
> }
> }
>
> The doLogin is viewed as a listener by Tapestry. The userId and password are
> viewed as full on bean properties by Tapestry. All in all, it works out
> pretty good. As far as I can tell, the class is not enhanced by Tapestry,
> however I don't think it would make a difference.
What if userId or password are persistent properties?
If Tapestry don't enhance this class then we'll have to write in groovy
the necessary maintenance code: Tapestry.fireObservedChange(...) in the
setters, implement an initialize(), etc...
> Is anybody else interested in this code?
I'm certainly interested!