You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Brian K. Wallace" <br...@transmorphix.com> on 2006/04/11 06:56:39 UTC
[Discuss] Friendly URLs as the default
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've been looking at the 'normal' use case and it appears as though
Friendly URLs seem to be the 'preferred' method of displaying URLs. This
being the case, would it not make more sense for Friendly URLs to be the
'default' for Tapestry? I am not proposing the removal of the ability to
customize the way they are generated, only the default.
In proposing this, however, I'm not proposing "true/false" for their
enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
still available. I'd suggest three options:
enabled, relaxed, and disabled.
"enabled" (not backward compatible) would completely disable the ability
to access the page/resources through the 'ugly' (original Tapestry) URL.
In using ACEGI for path security, it's quite disturbing to get security
enabled only to find access is open through the 'un-friendly' URL.
"relaxed" (backward compatible) would present Friendly URLs by default,
but 'ugly' URLs would still be accessible
"disabled" (backward compatible) would present the original Tapestry
URLs as it is now without the Friendly URLs.
I'm still all for customization of the exact nature of the
'friendliness' (the current method of stating 'html' == page, 'direct'
== direct, 'sdirect' == secure direct) such that users can specify what
endings they want. I'm also searching for a message on the user list
from quite a while ago that takes friendly URLs a step farther, but
that's kind of outside the realm of this.
Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
Friendly URLs were popular enough - and I must say they are to me with
security external to Tapestry classes - can we not make it just a little
easier to 'default' them?)
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEOzcGaCoPKRow/gARAv+fAKDJ/q0UPj5vG1gkg9vU92OXcZYIrwCfffMY
IcchDDj58p91C/ZaLyJ8Q+Y=
=JPra
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I'm totally fine with moving the default to pretty urls.
I don't want to take the steam off of this conversation, but while
you're thinking about making urls pretty.. give a minute to thinking
about simplifying the url space by merging PageService and
ExternalService.. do we really need two different ways to access the
page when they're essentially the same thing, just with or without
parameters?
what are the pros and cons of treating every PageService request as an
ExternalService request, but with a dummy activateExternalPage method..
(implemented in BasePage), or simply have ExternalService not throw an
exception if the page doesn't implement IExternalPage, then
ExternalService supports both regular pages and externalpages..
Alright, back to the conversation at hand, friendly urls by default is
totally cool.
Brian K. Wallace wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've been looking at the 'normal' use case and it appears as though
> Friendly URLs seem to be the 'preferred' method of displaying URLs. This
> being the case, would it not make more sense for Friendly URLs to be the
> 'default' for Tapestry? I am not proposing the removal of the ability to
> customize the way they are generated, only the default.
>
> In proposing this, however, I'm not proposing "true/false" for their
> enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
> still available. I'd suggest three options:
>
> enabled, relaxed, and disabled.
>
> "enabled" (not backward compatible) would completely disable the ability
> to access the page/resources through the 'ugly' (original Tapestry) URL.
> In using ACEGI for path security, it's quite disturbing to get security
> enabled only to find access is open through the 'un-friendly' URL.
>
> "relaxed" (backward compatible) would present Friendly URLs by default,
> but 'ugly' URLs would still be accessible
>
> "disabled" (backward compatible) would present the original Tapestry
> URLs as it is now without the Friendly URLs.
>
> I'm still all for customization of the exact nature of the
> 'friendliness' (the current method of stating 'html' == page, 'direct'
> == direct, 'sdirect' == secure direct) such that users can specify what
> endings they want. I'm also searching for a message on the user list
> from quite a while ago that takes friendly URLs a step farther, but
> that's kind of outside the realm of this.
>
> Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> Friendly URLs were popular enough - and I must say they are to me with
> security external to Tapestry classes - can we not make it just a little
> easier to 'default' them?)
>
> Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFEOzcGaCoPKRow/gARAv+fAKDJ/q0UPj5vG1gkg9vU92OXcZYIrwCfffMY
> IcchDDj58p91C/ZaLyJ8Q+Y=
> =JPra
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah, squeezing persistent entities seems to be a very common idea. We
can't afford to lose out on DataSqueezers.
-----Original Message-----
From: Henri Dupre [mailto:henri.dupre@gmail.com]
Sent: Friday, April 14, 2006 11:31 PM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
On 4/13/06, Geoff Longman <gl...@gmail.com> wrote:
>
> On 4/12/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> snip!
>
> > We might lose out on the DataSqueezer functionality in the process. Of
> > course, DS is most useful when you are trying to squeeze a
> > Serializable object as a parameter. For ints, strings, booleans, etc.,
> > it is pretty straightforward to convert back and forth between
> > primitive values and string representations.
>
> Whoa there cowboy. We are having great success squeezing Hibernate
> objects down to a classname + uniqueId (and sets of such and lists of
> such, and even maps of such) today.
Same here (although it is causing some headaches with objects getting loaded
twice)! We would really need a replacement to implement a similar
functionality for squeezing hibernate objects in and out.
Henri.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah, I agree. The point we were making was that we can't really do without
the "squeezer" functionality. We don't want Tapestry to include any
hibernate-specific stuff. We just don't want it to take away the feature
that let us use Hibernate effectively.
-----Original Message-----
From: Leonardo Quijano Vincenzi [mailto:leonardo@dtqsoftware.com]
Sent: Saturday, April 15, 2006 10:06 PM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
But one thing is to *support* a Hibernate specific solution and another
to *implement* it. Even if Tapestry doesn't support Hibernate directly,
it can support a Hibernate oriented integration layer, IMO.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Web Application Design and Programming
http://www.dtqsoftware.com
Geoff Longman wrote:
> I'm not in favour of any Hibernate specific solution. What about
> Cayenne? TopLink?
>
> Hibernate is the flavour de jour. This may sound nuts but someday
> Hibernate will be eclipsed (as will Tapestry but I won't got there!).
>
> Squeezers are customizable enough to support any number of
> necessities, persistent objects just being one.
>
> Geoff
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
But one thing is to *support* a Hibernate specific solution and another
to *implement* it. Even if Tapestry doesn't support Hibernate directly,
it can support a Hibernate oriented integration layer, IMO.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Web Application Design and Programming
http://www.dtqsoftware.com
Geoff Longman wrote:
> I'm not in favour of any Hibernate specific solution. What about
> Cayenne? TopLink?
>
> Hibernate is the flavour de jour. This may sound nuts but someday
> Hibernate will be eclipsed (as will Tapestry but I won't got there!).
>
> Squeezers are customizable enough to support any number of
> necessities, persistent objects just being one.
>
> Geoff
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Geoff Longman <gl...@gmail.com>.
I'm not in favour of any Hibernate specific solution. What about
Cayenne? TopLink?
Hibernate is the flavour de jour. This may sound nuts but someday
Hibernate will be eclipsed (as will Tapestry but I won't got there!).
Squeezers are customizable enough to support any number of
necessities, persistent objects just being one.
Geoff
On 4/14/06, Henri Dupre <he...@gmail.com> wrote:
> On 4/13/06, Geoff Longman <gl...@gmail.com> wrote:
> >
> > On 4/12/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > snip!
> >
> > > We might lose out on the DataSqueezer functionality in the process. Of
> > > course, DS is most useful when you are trying to squeeze a
> > > Serializable object as a parameter. For ints, strings, booleans, etc.,
> > > it is pretty straightforward to convert back and forth between
> > > primitive values and string representations.
> >
> > Whoa there cowboy. We are having great success squeezing Hibernate
> > objects down to a classname + uniqueId (and sets of such and lists of
> > such, and even maps of such) today.
>
>
>
> Same here (although it is causing some headaches with objects getting loaded
> twice)! We would really need a replacement to implement a similar
> functionality for squeezing hibernate objects in and out.
>
> Henri.
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Henri Dupre <he...@gmail.com>.
On 4/13/06, Geoff Longman <gl...@gmail.com> wrote:
>
> On 4/12/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> snip!
>
> > We might lose out on the DataSqueezer functionality in the process. Of
> > course, DS is most useful when you are trying to squeeze a
> > Serializable object as a parameter. For ints, strings, booleans, etc.,
> > it is pretty straightforward to convert back and forth between
> > primitive values and string representations.
>
> Whoa there cowboy. We are having great success squeezing Hibernate
> objects down to a classname + uniqueId (and sets of such and lists of
> such, and even maps of such) today.
Same here (although it is causing some headaches with objects getting loaded
twice)! We would really need a replacement to implement a similar
functionality for squeezing hibernate objects in and out.
Henri.
Re: [Discuss] Friendly URLs as the default
Posted by Geoff Longman <gl...@gmail.com>.
On 4/12/06, Howard Lewis Ship <hl...@gmail.com> wrote:
snip!
> We might lose out on the DataSqueezer functionality in the process. Of
> course, DS is most useful when you are trying to squeeze a
> Serializable object as a parameter. For ints, strings, booleans, etc.,
> it is pretty straightforward to convert back and forth between
> primitive values and string representations.
Whoa there cowboy. We are having great success squeezing Hibernate
objects down to a classname + uniqueId (and sets of such and lists of
such, and even maps of such) today.
What would be the replacement?
Geoff
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Jesse Kuhnert <jk...@gmail.com>.
In regard to the partial / full renders, I'm not completely sure what the
best way to share knowledge is. I've added a new hivemind configuration
point (in tapestry.request.xml I think, 4.0 trunk) that has the start of our
new response builder contribution configuration. These builders work similar
to the way that you described the RoR response rendering.
I'm open to suggestions on what the best way is for me to share my
knowledge, it just feels like the best way to share is by showing code.
Maybe now that things are getting more maintainable with new dev help I can
start focusing on 4.1 more.
On 4/12/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> A very good summary.
>
> In terms of links and parameters:
>
> It's pretty clear that there's some tension on links/URLs right now.
> On the one hand, I really like listener methods, and the mapping of
> query parameters to listener method arguments, with automatic
> conversion.
>
> However, the design of Tapestry 4 (i.e., all releases up to 4) is
> predicated upon full page renders.
>
> I suspect that, going forward, full page renders will often be the
> exception, rather than the rule. That is, you'll have a full page
> render, then a series of partial renders. In many cases, the result
> sent back to the client will not even be HTML markup, but will be an
> (XML?) data stream interpreted by JavaScript running in the browser.
>
> Further, if you look at the Ruby on Rails approach to graceful
> degradation, their equivalent of the HttpServletRequest has an isXHR()
> method. They do partial renders when this method is true, full page
> renders when it is false. The use an X-HDR HTTP header to differential
> the two ... clever!
>
> So, with Tapestry 4, we have many types of links, each linked to a
> particular engine service, which interpets the URLs and largely guides
> the request processing cycle.
>
> I agree that a simplification would be nice.
>
> I'm just starting to think about this in terms of Tapestry 5. I too
> would like to see a single Link component that can do PageLink,
> DirectLink and ExternalLink functionality, and then some.
>
> We might lose out on the DataSqueezer functionality in the process. Of
> course, DS is most useful when you are trying to squeeze a
> Serializable object as a parameter. For ints, strings, booleans, etc.,
> it is pretty straightforward to convert back and forth between
> primitive values and string representations.
>
> I am thinking that Tapestry 5 will be able to more fully reconstitute
> the state of the page before invoking a delegate method (I'm going to
> have to create a cheat sheet of name changes!).
>
> In Tapestry 4, the For component can record page state into hidden
> fields within a Form.
>
> In Tapestry 5, the For component should be capable of doing the same
> thing outside a Form; each URL will include some page render state
> information (serialized, gziped, perhaps encrypted) that will be used,
> in concert of persistent page properties, to return the page to the
> state it was in when a the corresponding link rendered. This is what I
> attempted to do with the ActionLink component in Tapestry 1 days, but
> I'm smarter now :-)
>
> I have some concerns about excessive "growth" of URLs as information
> from a series of partial renders accumulates. I also don't fully
> understand the client-side part of the equation in terms of
> client-side scripts, Dojo event handlers, and partial renders.
>
>
> On 4/12/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > So what I'm gathering from this is:
> >
> > 1. Defaulting friendly URLs from a user perspective is a plus but has a
> > drawback of current implementation in both a hivemodule and web xml.
> >
> > 2. Changing the servlet to a servlet filter is/may be a plus. The caveat
> > here would be a) not backward compatible and b) different handling for
> > portlets - which may or may not be an issue (meaning 1 filter to handle
> > both vs. 1 filter for non-portlet, 1 for portlet)
> >
> > 3. Somewhat off-topic, the need for multiple types of links is not
> > clear. (ideally, I'd like to see a single @Link and have Tapestry figure
> > out what kind it needs to be by parameters, URL, or other identifying
> > marker.
> >
> > Are there any issues raised from this that I missed?
> >
> > Brian
> >
> > Howard Lewis Ship wrote:
> > > The tricky part is that if you use friendly URLs, you have to
> > > coordinate the hivemodule.xml configuration with the web.xml
> > > configuration.
> > >
> > > I frequently define new engine services, and new friendly URL schemes
> > > to go with them.
> > >
> > >
> > > On 4/10/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > I've been looking at the 'normal' use case and it appears as though
> > > Friendly URLs seem to be the 'preferred' method of displaying URLs.
> This
> > > being the case, would it not make more sense for Friendly URLs to be
> the
> > > 'default' for Tapestry? I am not proposing the removal of the ability
> to
> > > customize the way they are generated, only the default.
> > >
> > > In proposing this, however, I'm not proposing "true/false" for their
> > > enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs
> are
> > > still available. I'd suggest three options:
> > >
> > > enabled, relaxed, and disabled.
> > >
> > > "enabled" (not backward compatible) would completely disable the
> ability
> > > to access the page/resources through the 'ugly' (original Tapestry)
> URL.
> > > In using ACEGI for path security, it's quite disturbing to get
> security
> > > enabled only to find access is open through the 'un-friendly' URL.
> > >
> > > "relaxed" (backward compatible) would present Friendly URLs by
> default,
> > > but 'ugly' URLs would still be accessible
> > >
> > > "disabled" (backward compatible) would present the original Tapestry
> > > URLs as it is now without the Friendly URLs.
> > >
> > > I'm still all for customization of the exact nature of the
> > > 'friendliness' (the current method of stating 'html' == page, 'direct'
> > > == direct, 'sdirect' == secure direct) such that users can specify
> what
> > > endings they want. I'm also searching for a message on the user list
> > > from quite a while ago that takes friendly URLs a step farther, but
> > > that's kind of outside the realm of this.
> > >
> > > Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> > > Friendly URLs were popular enough - and I must say they are to me with
> > > security external to Tapestry classes - can we not make it just a
> little
> > > easier to 'default' them?)
> > >
> > > Brian
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFEPO9LaCoPKRow/gARAiLyAJwJZz5W6mV0x7ecCwjB0ncuVap4egCg0CBT
> > 6RBmRieHFOajMpJFywY6wU4=
> > =mJMm
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://opennotion.com
Re: [Discuss] the future
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I was talking about the first step.
Just a nice consistent way to calculate last-modified, for dynamic pages
with complex components and different data streams. Because the only
way to do that right now is for me to put a filter which does all
last-mod logic: calculate last-modified and handle the if-modified-since
headers. But then how it calculates the last-modified must be kept in
sync with the page is actually rendering. And then the right filter has
to be placed infront of the right page, etc, etc. That's fine for a few
pages, but sadly it'll get onerous quickly.
but of course, as we start down this path, it won't take long for
someone to experiment with caching layers around each component render
call, so that tapestry could cache each component render, just as you
were talking about (this would probably be configurable per component,
or something). But I see that as secondary. Though interesting,
tapestry would then just be a framework to composition and piece
together renderings from different components, and it could do this on
the server-side or from the clent-side as Howard was alluding to
earlier. interesting, full circle.
so, I am just asking for leaders to keep in mind the last-modified and
expires attributes for pages/components as you evolve on tapestry code.
they're useful.
Gordon Henriksen wrote:
> On Apr 12, 2006, at 3:42 PM, Fernando Padilla wrote:
>
>> right. the issue/goal with 'last-modified' is that calculating
>> 'last-modified' will be cheaper than rebuilding the whole output.
>
>
> Indeed, just returning a cached rendering of a component can be
> valuable, but I'm not sure the last-modified model is the best one for
> server-side cache validation. Most operating systems now support
> filesystem change notifications; SQL Server 2005 can even notify
> clients when a query's results would change. These are fundamentally
> "push" models. To support both push and pull, how about something like
> this:
>
> public interface Dependency {
> boolean isInvalid();
> }
>
> void SimpleFileDependency implements Dependency {
> File file;
> long cachedModificationTime;
> public SimpleFileDependency(File file) {
> this.file = file;
> cachedModificationTime = file.lastModified();
> }
> public boolean isInvalid() {
> return cachedModificationTime != file.lastModified();
> }
> }
>
> class NotificationFileDependency implements Dependency {
> FileChangeNotification notification;
> boolean isInvalid;
> public NotificationFileDependency(File file) {
> notification = new MysicalMagicalFileChangeNotification {
> public void fileChanged() {
> isInvalid = true;
> }
> };
> }
> public boolean isInvalid() {
> return isInvalid;
> }
> public static boolean isSupported() {
> magic!
> }
> }
>
> public class CacheEntry {
> ...
> public void addDependency(File file) {
> if (NotificationFileDependency.isSupported())
> addDependency(new NotificationFileDependency(file));
> else
> addDependency(new SimpleFileDependency(file));
> }
> public void addDependency(Dependency dependency) {
> ...
> }
> }
>
> A CacheEntry can easily know when it was generated, and can simply
> report that as its modification date for the Last-Modified HTTP header
> field. Thus, dependencies don't need to calculate that data.
>
> Generically determining whether something is cacheable in Tapestry
> strikes me as harder, though.
>
> — G
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] the future
Posted by Gordon Henriksen <go...@mac.com>.
On Apr 12, 2006, at 3:42 PM, Fernando Padilla wrote:
> right. the issue/goal with 'last-modified' is that calculating
> 'last-modified' will be cheaper than rebuilding the whole output.
Indeed, just returning a cached rendering of a component can be
valuable, but I'm not sure the last-modified model is the best one
for server-side cache validation. Most operating systems now support
filesystem change notifications; SQL Server 2005 can even notify
clients when a query's results would change. These are fundamentally
"push" models. To support both push and pull, how about something
like this:
public interface Dependency {
boolean isInvalid();
}
void SimpleFileDependency implements Dependency {
File file;
long cachedModificationTime;
public SimpleFileDependency(File file) {
this.file = file;
cachedModificationTime = file.lastModified();
}
public boolean isInvalid() {
return cachedModificationTime != file.lastModified();
}
}
class NotificationFileDependency implements Dependency {
FileChangeNotification notification;
boolean isInvalid;
public NotificationFileDependency(File file) {
notification = new MysicalMagicalFileChangeNotification {
public void fileChanged() {
isInvalid = true;
}
};
}
public boolean isInvalid() {
return isInvalid;
}
public static boolean isSupported() {
magic!
}
}
public class CacheEntry {
...
public void addDependency(File file) {
if (NotificationFileDependency.isSupported())
addDependency(new NotificationFileDependency(file));
else
addDependency(new SimpleFileDependency(file));
}
public void addDependency(Dependency dependency) {
...
}
}
A CacheEntry can easily know when it was generated, and can simply
report that as its modification date for the Last-Modified HTTP
header field. Thus, dependencies don't need to calculate that data.
Generically determining whether something is cacheable in Tapestry
strikes me as harder, though.
— G
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] the future
Posted by Fernando Padilla <fe...@alum.mit.edu>.
right. the issue/goal with 'last-modified' is that calculating
'last-modified' will be cheaper than rebuilding the whole output. This
has to be application specific, it can not do this without application
specific intervention.
Most components have no concept of what data they are rendering or
doesn't know how to calculate last-modified efficiently, so they have to
return "null" or "now", the cycle would continue down the tree.
Eventually this cycle will ask one of the application components which
does know about the data that it is rendering and knows how to calculate
the 'last-modified' in a more efficient manner than rendering the whole
output. That then components returns the appropriate last-modified
value. Then cycle would then return the latest value, and use that for
the whole page.
The last-modified strategy requires application specific knowledge about
what the page/component is rendering and how to calculate last-modified
in an efficient manner, else there is no way to calculate it, then you
might as well disable calculation of last-modified all together.
Brian K. Wallace wrote:
> The problem with your description of a 'last-modified' process of asking
> each component what it's last-modified time was is:
> 1. With caching enabled, the question is irrelevant.
> 2. With caching disabled, the question could be irrelevant - it
> depends on what the component does. If the component retrieves the
> latest entries from a database, the component may not have changed - but
> the entries may have. This would require the component to build itself
> in order to know if it had truly changed. Past that, you aren't saving much.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] the future
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Padilla wrote:
>
> Howard Lewis Ship wrote:
>
>> I suspect that, going forward, full page renders will often be the
>> exception, rather than the rule. That is, you'll have a full page
>> render, then a series of partial renders. In many cases, the result
>> sent back to the client will not even be HTML markup, but will be an
>> (XML?) data stream interpreted by JavaScript running in the browser.
>
> ** client-side-inclde
> Interesting. I have been waiting for the concept of Client-Side-Include
> for a while, and maybe tapestry will be build totally around this
> concept in the future. For now I just created tapestry components to do
> so client-side-include, but then I had to create simple pages just to
> render the desired html fragment.
>
>
> ** last-modified
> I am not sure if I have mentioned it before, but please as you guys are
> thinking about the framework please work in proper support for
> last-modified checking! and expires setting! for any render/request.
> This simple technique can easy multiply the number of users the system
> can handle, for zero cost ( if you were already planning on rendering
> everything anyhow ).
>
> I have been dreaming of refactoring the rewind cycle operation to add a
> last-modified cycle, that would walk through the tree and ask each
> component it's last-modified time, and then aggregate that information
> somehow to determine the page's last-modified time. Then determine
> after that if we actually go through the final render step. This saves
> resources all around ( cpu, memory, response time, bandwidth ).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
I have no comment on client-side-includes - outside of js I must admit
I've either never had the need for them and/or I just don't quite grasp
the concept. Full vs. partial renderers, yes. Much past that and I think
I must be missing a point or two somewhere.
As for last-modified... I have two separate thoughts. I'd definitely
like to be able to put a cache pragma on a page and have that page
"built once, displayed over and over" (little borrowing of the Java
mantra with a tweak for caching purposes :-)). Delivering a cached page
will (should?) always be faster than a completely generated page. I'd
also like to be able to go back in time and resurrect the 'generate
static HTML from Tapestry application' thought. Having a web-server
deliver static content will usually (usual caveats: config, load, etc)
be faster and less resource intensive than asking a servlet container to
do so. I view both of these as separate 'wishes', but both designed to
do two things: speed up delivery of content to the client, and reduce
load on the server.
The problem with your description of a 'last-modified' process of asking
each component what it's last-modified time was is:
1. With caching enabled, the question is irrelevant.
2. With caching disabled, the question could be irrelevant - it
depends on what the component does. If the component retrieves the
latest entries from a database, the component may not have changed - but
the entries may have. This would require the component to build itself
in order to know if it had truly changed. Past that, you aren't saving much.
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEPVItaCoPKRow/gARAoJtAJ9016W1pKpu98OYX8TsErUUW7L9yQCglhj5
TXv16cN2F6blStzQbYBdLFw=
=AnOO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[Discuss] the future
Posted by Fernando Padilla <fe...@alum.mit.edu>.
Howard Lewis Ship wrote:
> I suspect that, going forward, full page renders will often be the
> exception, rather than the rule. That is, you'll have a full page
> render, then a series of partial renders. In many cases, the result
> sent back to the client will not even be HTML markup, but will be an
> (XML?) data stream interpreted by JavaScript running in the browser.
** client-side-inclde
Interesting. I have been waiting for the concept of Client-Side-Include
for a while, and maybe tapestry will be build totally around this
concept in the future. For now I just created tapestry components to do
so client-side-include, but then I had to create simple pages just to
render the desired html fragment.
** last-modified
I am not sure if I have mentioned it before, but please as you guys are
thinking about the framework please work in proper support for
last-modified checking! and expires setting! for any render/request.
This simple technique can easy multiply the number of users the system
can handle, for zero cost ( if you were already planning on rendering
everything anyhow ).
I have been dreaming of refactoring the rewind cycle operation to add a
last-modified cycle, that would walk through the tree and ask each
component it's last-modified time, and then aggregate that information
somehow to determine the page's last-modified time. Then determine
after that if we actually go through the final render step. This saves
resources all around ( cpu, memory, response time, bandwidth ).
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Howard Lewis Ship <hl...@gmail.com>.
A very good summary.
In terms of links and parameters:
It's pretty clear that there's some tension on links/URLs right now.
On the one hand, I really like listener methods, and the mapping of
query parameters to listener method arguments, with automatic
conversion.
However, the design of Tapestry 4 (i.e., all releases up to 4) is
predicated upon full page renders.
I suspect that, going forward, full page renders will often be the
exception, rather than the rule. That is, you'll have a full page
render, then a series of partial renders. In many cases, the result
sent back to the client will not even be HTML markup, but will be an
(XML?) data stream interpreted by JavaScript running in the browser.
Further, if you look at the Ruby on Rails approach to graceful
degradation, their equivalent of the HttpServletRequest has an isXHR()
method. They do partial renders when this method is true, full page
renders when it is false. The use an X-HDR HTTP header to differential
the two ... clever!
So, with Tapestry 4, we have many types of links, each linked to a
particular engine service, which interpets the URLs and largely guides
the request processing cycle.
I agree that a simplification would be nice.
I'm just starting to think about this in terms of Tapestry 5. I too
would like to see a single Link component that can do PageLink,
DirectLink and ExternalLink functionality, and then some.
We might lose out on the DataSqueezer functionality in the process. Of
course, DS is most useful when you are trying to squeeze a
Serializable object as a parameter. For ints, strings, booleans, etc.,
it is pretty straightforward to convert back and forth between
primitive values and string representations.
I am thinking that Tapestry 5 will be able to more fully reconstitute
the state of the page before invoking a delegate method (I'm going to
have to create a cheat sheet of name changes!).
In Tapestry 4, the For component can record page state into hidden
fields within a Form.
In Tapestry 5, the For component should be capable of doing the same
thing outside a Form; each URL will include some page render state
information (serialized, gziped, perhaps encrypted) that will be used,
in concert of persistent page properties, to return the page to the
state it was in when a the corresponding link rendered. This is what I
attempted to do with the ActionLink component in Tapestry 1 days, but
I'm smarter now :-)
I have some concerns about excessive "growth" of URLs as information
from a series of partial renders accumulates. I also don't fully
understand the client-side part of the equation in terms of
client-side scripts, Dojo event handlers, and partial renders.
On 4/12/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So what I'm gathering from this is:
>
> 1. Defaulting friendly URLs from a user perspective is a plus but has a
> drawback of current implementation in both a hivemodule and web xml.
>
> 2. Changing the servlet to a servlet filter is/may be a plus. The caveat
> here would be a) not backward compatible and b) different handling for
> portlets - which may or may not be an issue (meaning 1 filter to handle
> both vs. 1 filter for non-portlet, 1 for portlet)
>
> 3. Somewhat off-topic, the need for multiple types of links is not
> clear. (ideally, I'd like to see a single @Link and have Tapestry figure
> out what kind it needs to be by parameters, URL, or other identifying
> marker.
>
> Are there any issues raised from this that I missed?
>
> Brian
>
> Howard Lewis Ship wrote:
> > The tricky part is that if you use friendly URLs, you have to
> > coordinate the hivemodule.xml configuration with the web.xml
> > configuration.
> >
> > I frequently define new engine services, and new friendly URL schemes
> > to go with them.
> >
> >
> > On 4/10/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > I've been looking at the 'normal' use case and it appears as though
> > Friendly URLs seem to be the 'preferred' method of displaying URLs. This
> > being the case, would it not make more sense for Friendly URLs to be the
> > 'default' for Tapestry? I am not proposing the removal of the ability to
> > customize the way they are generated, only the default.
> >
> > In proposing this, however, I'm not proposing "true/false" for their
> > enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
> > still available. I'd suggest three options:
> >
> > enabled, relaxed, and disabled.
> >
> > "enabled" (not backward compatible) would completely disable the ability
> > to access the page/resources through the 'ugly' (original Tapestry) URL.
> > In using ACEGI for path security, it's quite disturbing to get security
> > enabled only to find access is open through the 'un-friendly' URL.
> >
> > "relaxed" (backward compatible) would present Friendly URLs by default,
> > but 'ugly' URLs would still be accessible
> >
> > "disabled" (backward compatible) would present the original Tapestry
> > URLs as it is now without the Friendly URLs.
> >
> > I'm still all for customization of the exact nature of the
> > 'friendliness' (the current method of stating 'html' == page, 'direct'
> > == direct, 'sdirect' == secure direct) such that users can specify what
> > endings they want. I'm also searching for a message on the user list
> > from quite a while ago that takes friendly URLs a step farther, but
> > that's kind of outside the realm of this.
> >
> > Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> > Friendly URLs were popular enough - and I must say they are to me with
> > security external to Tapestry classes - can we not make it just a little
> > easier to 'default' them?)
> >
> > Brian
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFEPO9LaCoPKRow/gARAiLyAJwJZz5W6mV0x7ecCwjB0ncuVap4egCg0CBT
> 6RBmRieHFOajMpJFywY6wU4=
> =mJMm
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Comments inline
Fernando Padilla wrote:
>
>
> Brian K. Wallace wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> So what I'm gathering from this is:
>>
>> 1. Defaulting friendly URLs from a user perspective is a plus but has a
>> drawback of current implementation in both a hivemodule and web xml.
>
> "drawback of breaking backwards compatibility" and having to update
> configuration files
The breaking of backward compatibility would be a definite possibility,
but not a certainty. The specific ramifications of this change would be
implementation dependent, but it would probably come on the heels of
either "break it" or "re-config it". The percentage of users who would
actually have apps _break_ would probably be very low in any case as one
of the options I originally presented would continue to accept URLs as
they currently are.
>
>
>> 3. Somewhat off-topic, the need for multiple types of links is not
>> clear. (ideally, I'd like to see a single @Link and have Tapestry figure
>> out what kind it needs to be by parameters, URL, or other identifying
>> marker.
>
> This is a bad summary. We were just talking about PageLink/Service and
> ExternalLink/Service. They are essentially the same: loadPage,
> initPage, renderPage, returnPage. The only difference is if you have
> any parameters to pass the page for it to initialize itself with.
>
> There is no talk (I am not qualified to talk) of confusing this very
> straight forward behavior with ActionLink or DirectLink, which deal with
> more complicated scenarios and doing callbacks on particular components
> within a page, blah blah blah.
>
> If I create an Page/ExternalLink I am fully aware that the page has only
> as much information as I pass to it through the parameters, nothing
> more. That's the whole point. I think we can work on refactoring these
> together without having to deal at all with the issues of rewind or
> state management.
It's an interesting feeling to be somewhere between "good summary" and
"bad summary". :-/ Perhaps my summary was too high a level and contained
both 'summary' and 'my personal preference' in one. Yes, I was indeed
summarizing only Page and External links. My addition to include a
desire for an @Link vs. all the different types of components was
misplaced for such a summary. (I should have put it in the thread
leading up to the summary if I were going to mention it at all, but
that's one of the areas that lay outside the original question of URLs)
Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEPU9YaCoPKRow/gARAj4zAKDye9NW7V2SQMZ7ZZYMJxxDTH3N+ACfVR1e
ciaSHfbLLCKic8t/HgFwjOA=
=zOJm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Fernando Padilla <fe...@alum.mit.edu>.
Brian K. Wallace wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So what I'm gathering from this is:
>
> 1. Defaulting friendly URLs from a user perspective is a plus but has a
> drawback of current implementation in both a hivemodule and web xml.
"drawback of breaking backwards compatibility" and having to update
configuration files
> 3. Somewhat off-topic, the need for multiple types of links is not
> clear. (ideally, I'd like to see a single @Link and have Tapestry figure
> out what kind it needs to be by parameters, URL, or other identifying
> marker.
This is a bad summary. We were just talking about PageLink/Service and
ExternalLink/Service. They are essentially the same: loadPage,
initPage, renderPage, returnPage. The only difference is if you have
any parameters to pass the page for it to initialize itself with.
There is no talk (I am not qualified to talk) of confusing this very
straight forward behavior with ActionLink or DirectLink, which deal with
more complicated scenarios and doing callbacks on particular components
within a page, blah blah blah.
If I create an Page/ExternalLink I am fully aware that the page has only
as much information as I pass to it through the parameters, nothing
more. That's the whole point. I think we can work on refactoring these
together without having to deal at all with the issues of rewind or
state management.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So what I'm gathering from this is:
1. Defaulting friendly URLs from a user perspective is a plus but has a
drawback of current implementation in both a hivemodule and web xml.
2. Changing the servlet to a servlet filter is/may be a plus. The caveat
here would be a) not backward compatible and b) different handling for
portlets - which may or may not be an issue (meaning 1 filter to handle
both vs. 1 filter for non-portlet, 1 for portlet)
3. Somewhat off-topic, the need for multiple types of links is not
clear. (ideally, I'd like to see a single @Link and have Tapestry figure
out what kind it needs to be by parameters, URL, or other identifying
marker.
Are there any issues raised from this that I missed?
Brian
Howard Lewis Ship wrote:
> The tricky part is that if you use friendly URLs, you have to
> coordinate the hivemodule.xml configuration with the web.xml
> configuration.
>
> I frequently define new engine services, and new friendly URL schemes
> to go with them.
>
>
> On 4/10/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> I've been looking at the 'normal' use case and it appears as though
> Friendly URLs seem to be the 'preferred' method of displaying URLs. This
> being the case, would it not make more sense for Friendly URLs to be the
> 'default' for Tapestry? I am not proposing the removal of the ability to
> customize the way they are generated, only the default.
>
> In proposing this, however, I'm not proposing "true/false" for their
> enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
> still available. I'd suggest three options:
>
> enabled, relaxed, and disabled.
>
> "enabled" (not backward compatible) would completely disable the ability
> to access the page/resources through the 'ugly' (original Tapestry) URL.
> In using ACEGI for path security, it's quite disturbing to get security
> enabled only to find access is open through the 'un-friendly' URL.
>
> "relaxed" (backward compatible) would present Friendly URLs by default,
> but 'ugly' URLs would still be accessible
>
> "disabled" (backward compatible) would present the original Tapestry
> URLs as it is now without the Friendly URLs.
>
> I'm still all for customization of the exact nature of the
> 'friendliness' (the current method of stating 'html' == page, 'direct'
> == direct, 'sdirect' == secure direct) such that users can specify what
> endings they want. I'm also searching for a message on the user list
> from quite a while ago that takes friendly URLs a step farther, but
> that's kind of outside the realm of this.
>
> Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> Friendly URLs were popular enough - and I must say they are to me with
> security external to Tapestry classes - can we not make it just a little
> easier to 'default' them?)
>
> Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEPO9LaCoPKRow/gARAiLyAJwJZz5W6mV0x7ecCwjB0ncuVap4egCg0CBT
6RBmRieHFOajMpJFywY6wU4=
=mJMm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by D&J Gredler <dj...@gmail.com>.
Speaking as a tapestry user, I'm with Fernando on this. The point of the
external service is to allow bookmarkable pages, but with the friendly URLs,
regular (non-external) pages just look like HTML pages, which are obviously
bookmarkable too. It has been hard for me to see a difference.
Regards,
Daniel
On 4/11/06, Fernando Padilla <fe...@alum.mit.edu> wrote:
>
> I still don't see the difference between PageService and
> ExternalService, and want ExternalService to be mapped to *.html some
> how. There is no reason to have an ugly url for ExternalService, when
> it's just a regular page with parameters.
>
Re: [Discuss] Friendly URLs as the default
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
ditto for that...
Why the special distinction between PageService and ExternalService?
We could even have pages with parameters (using @Parameter annotation or
JWC parameters). Orthogonality and regularity are Good Things (tm).
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Fernando Padilla wrote:
> I still don't see the difference between PageService and
> ExternalService, and want ExternalService to be mapped to *.html some
> how. There is no reason to have an ugly url for ExternalService, when
> it's just a regular page with parameters.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I still don't see the difference between PageService and
ExternalService, and want ExternalService to be mapped to *.html some
how. There is no reason to have an ugly url for ExternalService, when
it's just a regular page with parameters.
Howard Lewis Ship wrote:
> For Tapestry 5, I've been thinking in terms of three standard mappings:
>
> /asset/
> *.html
> /action/
>
>
> Everything handled by the direct and external services and quite a bit
> more, would fall under the /action/ pattern.
>
> I think your servlet filter idea has a lot of value as well.
>
> On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
>
>>On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>
>>>Unless we do what I suggested a while back and make Tapestry just a servlet
>>>filter mapped to "/*" and not an actual Servlet. That way, the URL patterns
>>>can be configured via HiveMind.
>>
>>I remember also someone wishing to show a proof of concept, does that
>>gone forward?
>>
>>--
>>Massimo
>>http://meridio.blogspot.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
Yeah, unfortunately, I'm not that familiar with the portlet aspect of
Tapestry yet. Heck, I'm not really familiar with Tapestry yet, at least not
at the level of you guys. But, as long as all the URLs that were previously
serviced by the servlet are serviced by the filter, shouldn't it be somewhat
transparent? The only difference would be that any request that comes in
that doesn't have a service name encoded into it would just flow through
instead of just going to the Home service.
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Tuesday, April 11, 2006 1:11 PM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
A servlet filter approach would mean that Portlet Tapestry would be
significantly different from Servlet Tapestry (not that it isn't
already the case).
On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> The filter would basically have to do what the RequestCycleFactoryImpl
class
> does:
>
> WebRequest request = _infrastructure.getRequest();
> QueryParameterMap parameters = extractParameters(request);
> decodeParameters(request.getActivationPath(), request.getPathInfo(),
> parameters);
>
> After the parameters have been decoded, then it would try to lookup the
> service name in the parameters. If the service name is not there, then I
> guess it'd just let the request go on through (and not default to the
"Home"
> service). Otherwise, it'd just invoke the ServletRequestServicer, since
it
> knows that one of the services will take care of it. Sound about right to
> you guys?
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Tuesday, April 11, 2006 12:37 PM
> To: 'Tapestry development'
> Subject: RE: [Discuss] Friendly URLs as the default
>
> If you just have the servlet filter take all URLs, then it can decide
> whether to just handle the request itself or just let it go through to
> whatever else might handle it (like the default servlet).
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Tuesday, April 11, 2006 11:37 AM
> To: Tapestry development
> Subject: Re: [Discuss] Friendly URLs as the default
>
> For Tapestry 5, I've been thinking in terms of three standard mappings:
>
> /asset/
> *.html
> /action/
>
>
> Everything handled by the direct and external services and quite a bit
> more, would fall under the /action/ pattern.
>
> I think your servlet filter idea has a lot of value as well.
>
> On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
> > On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > > Unless we do what I suggested a while back and make Tapestry just a
> servlet
> > > filter mapped to "/*" and not an actual Servlet. That way, the URL
> patterns
> > > can be configured via HiveMind.
> >
> > I remember also someone wishing to show a proof of concept, does that
> > gone forward?
> >
> > --
> > Massimo
> > http://meridio.blogspot.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Howard Lewis Ship <hl...@gmail.com>.
A servlet filter approach would mean that Portlet Tapestry would be
significantly different from Servlet Tapestry (not that it isn't
already the case).
On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> The filter would basically have to do what the RequestCycleFactoryImpl class
> does:
>
> WebRequest request = _infrastructure.getRequest();
> QueryParameterMap parameters = extractParameters(request);
> decodeParameters(request.getActivationPath(), request.getPathInfo(),
> parameters);
>
> After the parameters have been decoded, then it would try to lookup the
> service name in the parameters. If the service name is not there, then I
> guess it'd just let the request go on through (and not default to the "Home"
> service). Otherwise, it'd just invoke the ServletRequestServicer, since it
> knows that one of the services will take care of it. Sound about right to
> you guys?
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Tuesday, April 11, 2006 12:37 PM
> To: 'Tapestry development'
> Subject: RE: [Discuss] Friendly URLs as the default
>
> If you just have the servlet filter take all URLs, then it can decide
> whether to just handle the request itself or just let it go through to
> whatever else might handle it (like the default servlet).
>
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Tuesday, April 11, 2006 11:37 AM
> To: Tapestry development
> Subject: Re: [Discuss] Friendly URLs as the default
>
> For Tapestry 5, I've been thinking in terms of three standard mappings:
>
> /asset/
> *.html
> /action/
>
>
> Everything handled by the direct and external services and quite a bit
> more, would fall under the /action/ pattern.
>
> I think your servlet filter idea has a lot of value as well.
>
> On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
> > On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> >
> > > Unless we do what I suggested a while back and make Tapestry just a
> servlet
> > > filter mapped to "/*" and not an actual Servlet. That way, the URL
> patterns
> > > can be configured via HiveMind.
> >
> > I remember also someone wishing to show a proof of concept, does that
> > gone forward?
> >
> > --
> > Massimo
> > http://meridio.blogspot.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
The filter would basically have to do what the RequestCycleFactoryImpl class
does:
WebRequest request = _infrastructure.getRequest();
QueryParameterMap parameters = extractParameters(request);
decodeParameters(request.getActivationPath(), request.getPathInfo(),
parameters);
After the parameters have been decoded, then it would try to lookup the
service name in the parameters. If the service name is not there, then I
guess it'd just let the request go on through (and not default to the "Home"
service). Otherwise, it'd just invoke the ServletRequestServicer, since it
knows that one of the services will take care of it. Sound about right to
you guys?
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: Tuesday, April 11, 2006 12:37 PM
To: 'Tapestry development'
Subject: RE: [Discuss] Friendly URLs as the default
If you just have the servlet filter take all URLs, then it can decide
whether to just handle the request itself or just let it go through to
whatever else might handle it (like the default servlet).
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Tuesday, April 11, 2006 11:37 AM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
For Tapestry 5, I've been thinking in terms of three standard mappings:
/asset/
*.html
/action/
Everything handled by the direct and external services and quite a bit
more, would fall under the /action/ pattern.
I think your servlet filter idea has a lot of value as well.
On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
> On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> > Unless we do what I suggested a while back and make Tapestry just a
servlet
> > filter mapped to "/*" and not an actual Servlet. That way, the URL
patterns
> > can be configured via HiveMind.
>
> I remember also someone wishing to show a proof of concept, does that
> gone forward?
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
If you just have the servlet filter take all URLs, then it can decide
whether to just handle the request itself or just let it go through to
whatever else might handle it (like the default servlet).
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Tuesday, April 11, 2006 11:37 AM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
For Tapestry 5, I've been thinking in terms of three standard mappings:
/asset/
*.html
/action/
Everything handled by the direct and external services and quite a bit
more, would fall under the /action/ pattern.
I think your servlet filter idea has a lot of value as well.
On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
> On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> > Unless we do what I suggested a while back and make Tapestry just a
servlet
> > filter mapped to "/*" and not an actual Servlet. That way, the URL
patterns
> > can be configured via HiveMind.
>
> I remember also someone wishing to show a proof of concept, does that
> gone forward?
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Howard Lewis Ship <hl...@gmail.com>.
For Tapestry 5, I've been thinking in terms of three standard mappings:
/asset/
*.html
/action/
Everything handled by the direct and external services and quite a bit
more, would fall under the /action/ pattern.
I think your servlet filter idea has a lot of value as well.
On 4/11/06, Massimo Lusetti <ml...@gmail.com> wrote:
> On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> > Unless we do what I suggested a while back and make Tapestry just a servlet
> > filter mapped to "/*" and not an actual Servlet. That way, the URL patterns
> > can be configured via HiveMind.
>
> I remember also someone wishing to show a proof of concept, does that
> gone forward?
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
No, I haven't had time to work on it. I don't think anyone believes that
it's not possible. After all, a Filter can do everything that a servlet can
do.
-----Original Message-----
From: Massimo Lusetti [mailto:mlusetti@gmail.com]
Sent: Tuesday, April 11, 2006 9:20 AM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> Unless we do what I suggested a while back and make Tapestry just a
servlet
> filter mapped to "/*" and not an actual Servlet. That way, the URL
patterns
> can be configured via HiveMind.
I remember also someone wishing to show a proof of concept, does that
gone forward?
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Massimo Lusetti <ml...@gmail.com>.
On 4/11/06, James Carman <ja...@carmanconsulting.com> wrote:
> Unless we do what I suggested a while back and make Tapestry just a servlet
> filter mapped to "/*" and not an actual Servlet. That way, the URL patterns
> can be configured via HiveMind.
I remember also someone wishing to show a proof of concept, does that
gone forward?
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: [Discuss] Friendly URLs as the default
Posted by James Carman <ja...@carmanconsulting.com>.
Unless we do what I suggested a while back and make Tapestry just a servlet
filter mapped to "/*" and not an actual Servlet. That way, the URL patterns
can be configured via HiveMind.
-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: Tuesday, April 11, 2006 1:42 AM
To: Tapestry development
Subject: Re: [Discuss] Friendly URLs as the default
The tricky part is that if you use friendly URLs, you have to
coordinate the hivemodule.xml configuration with the web.xml
configuration.
I frequently define new engine services, and new friendly URL schemes
to go with them.
On 4/10/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've been looking at the 'normal' use case and it appears as though
> Friendly URLs seem to be the 'preferred' method of displaying URLs. This
> being the case, would it not make more sense for Friendly URLs to be the
> 'default' for Tapestry? I am not proposing the removal of the ability to
> customize the way they are generated, only the default.
>
> In proposing this, however, I'm not proposing "true/false" for their
> enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
> still available. I'd suggest three options:
>
> enabled, relaxed, and disabled.
>
> "enabled" (not backward compatible) would completely disable the ability
> to access the page/resources through the 'ugly' (original Tapestry) URL.
> In using ACEGI for path security, it's quite disturbing to get security
> enabled only to find access is open through the 'un-friendly' URL.
>
> "relaxed" (backward compatible) would present Friendly URLs by default,
> but 'ugly' URLs would still be accessible
>
> "disabled" (backward compatible) would present the original Tapestry
> URLs as it is now without the Friendly URLs.
>
> I'm still all for customization of the exact nature of the
> 'friendliness' (the current method of stating 'html' == page, 'direct'
> == direct, 'sdirect' == secure direct) such that users can specify what
> endings they want. I'm also searching for a message on the user list
> from quite a while ago that takes friendly URLs a step farther, but
> that's kind of outside the realm of this.
>
> Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> Friendly URLs were popular enough - and I must say they are to me with
> security external to Tapestry classes - can we not make it just a little
> easier to 'default' them?)
>
> Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFEOzcGaCoPKRow/gARAv+fAKDJ/q0UPj5vG1gkg9vU92OXcZYIrwCfffMY
> IcchDDj58p91C/ZaLyJ8Q+Y=
> =JPra
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [Discuss] Friendly URLs as the default
Posted by Howard Lewis Ship <hl...@gmail.com>.
The tricky part is that if you use friendly URLs, you have to
coordinate the hivemodule.xml configuration with the web.xml
configuration.
I frequently define new engine services, and new friendly URL schemes
to go with them.
On 4/10/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've been looking at the 'normal' use case and it appears as though
> Friendly URLs seem to be the 'preferred' method of displaying URLs. This
> being the case, would it not make more sense for Friendly URLs to be the
> 'default' for Tapestry? I am not proposing the removal of the ability to
> customize the way they are generated, only the default.
>
> In proposing this, however, I'm not proposing "true/false" for their
> enablement. Currently, when enabling Friendly URLs, the 'ugly' URLs are
> still available. I'd suggest three options:
>
> enabled, relaxed, and disabled.
>
> "enabled" (not backward compatible) would completely disable the ability
> to access the page/resources through the 'ugly' (original Tapestry) URL.
> In using ACEGI for path security, it's quite disturbing to get security
> enabled only to find access is open through the 'un-friendly' URL.
>
> "relaxed" (backward compatible) would present Friendly URLs by default,
> but 'ugly' URLs would still be accessible
>
> "disabled" (backward compatible) would present the original Tapestry
> URLs as it is now without the Friendly URLs.
>
> I'm still all for customization of the exact nature of the
> 'friendliness' (the current method of stating 'html' == page, 'direct'
> == direct, 'sdirect' == secure direct) such that users can specify what
> endings they want. I'm also searching for a message on the user list
> from quite a while ago that takes friendly URLs a step farther, but
> that's kind of outside the realm of this.
>
> Thoughts on this? (I don't see any value add for 'ugly' URLs, and if
> Friendly URLs were popular enough - and I must say they are to me with
> security external to Tapestry classes - can we not make it just a little
> easier to 'default' them?)
>
> Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFEOzcGaCoPKRow/gARAv+fAKDJ/q0UPj5vG1gkg9vU92OXcZYIrwCfffMY
> IcchDDj58p91C/ZaLyJ8Q+Y=
> =JPra
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org