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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
