Explicit page URL's, AKA Tapestry vs RIFE

[Marcus Brito <pa...@pazu.com.br>]

(This might be a little too long. I have no thing to do at work, I'm
bored, and this usually leads to large chunks of incomprehensible
text)

First, some background: I'm current developing an application with a
common backend accessed by both a Tapestry and a RIFE front layers.
The IDEA here is to make a direct comparision of the effort and
development experience of the two frameworks.

RIFE has many good points about it, but since this mailing list isn't about it,
I'll shorten the list to one golden point: nice, explicit URL's. The user is
able to specify a URL for each element (page) in the site, and how to map URL
parameters to the element's inputs. Just a quick example:

<element id="details" file="category/details.xml" url="/category/*">
  <pathinfo mapping="$id"/>
</element>

This would map all URL's starting with "/category" to the "details" element, and
the URL's pathinfo (what comes after /category) will be translated to an input
parameter called "id". This way, a URL like "http://example.com/category/10"
directly maps to that element, using 10 as the id parameter. I can't overstate
how nice this is, specially when developing RESTful API's.

I know how Tapestry stress that "developers shouldn't worry about URL's", but
IMHO this couldn't be far from the truth. Sure, the way Tapestry relieves the
developer from the drudging URL mapping and query parameters processing is nice,
but the way the developer completely surrenders control over URL mapping isn't
that nice.

By now you're probably screaming "mod_rewrite!" or "UrlRewriteFilter!". These
two guys could solve the problem, but in a somewhat hackish way: the devoloper
would have to write down the tapestry-generated URL's, and by definition these
shouldn't be tampered with. It would be a lot nicer if Tapestry itself could
take user-specified URL's, and redirect them to the correct page, even if it's
just an internal redirect to the generated URL.

One other thing I miss in Tapestry are templateless pages -- a page where all
output is rendered programatically, and no template is needed. I know, I could
write a whole new service, but isn't that a little too much? Specially if you
have only a couple of these pages in an otherwise big application.

Ok, this message is getting too long (but a lot shorter than it's sister message
in RIFE's mailing list). Let's see if I can get some replies, and pick up from
them. 

-- Marcus Brito


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Explicit page URL's, AKA Tapestry vs RIFE

[Kent Tong <ke...@cpttm.org.mo>]

Marcus Brito <pazu <at> pazu.com.br> writes:

> ... This way, a URL like "http://example.com/category/10"
> directly maps to that element, using 10 as the id parameter. I can't 
> overstate how nice this is, specially when developing RESTful API's.

You can do this with a service encoder in Tapestry.

> One other thing I miss in Tapestry are templateless pages -- a page where all
> output is rendered programatically, and no template is needed. I know, I could
> write a whole new service, but isn't that a little too much? Specially if you
> have only a couple of these pages in an otherwise big application.

Try using a template like:

<span jwcid="@Insert" raw="true" value="ognl:pageContent"/>

Then write a page class like:

public class Home extends BasePage {

	@Override
	public ContentType getResponseContentType() {
		return new ContentType("text/xml");
	}
	public String getPageContent() {
		return "<foo>123</foo>";
	}

}

Of course, if you're writing a web service, you may want to integrate
say a web service engine (eg, Apache Axis) into your app. This will
provide you with nice features like data-binding.

--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org