It's been an oft requested feature over the years. In fact, I'd still love to have T4 version.
While doable at a high-level, it's error prone. Rewrite rules or declaritive security statements have to be written and every resource accessed to test. Now, if Tapestry is already writing the URLs out for me and I already know which resources I want protected, it makes a lot of sense to define that in the class itself. Moreover, the guy deploying and the guy developing are often different people and lack of communication using a "high-level" approach can lead to big problems. Also, please start new threads if you want to wrangle other issues. Jumping to framework design issues and URL schemes really doesn't help the matter of the Secure annotation at all. -- Kevin On 3/15/08 7:58 AM, "kranga" <[EMAIL PROTECTED]> wrote: > Funny - my experience has been the exact opposite. > > Building a general purpose framework on one's personal experience can have > shortfalls. For example you state in your blog "I also think Tapestry's > built-in rules for URLs are really strong and appealing; I simply don't see > customizing the built-in rules to be a priority, or frankly, of any great > value." > > I can tell you the URL scheme of Tapestry would not work at all for some of > the apps I've built. > > ----- Original Message ----- > From: "Howard Lewis Ship" <[EMAIL PROTECTED]> > To: "Tapestry users" <users@tapestry.apache.org> > Sent: Friday, March 14, 2008 2:38 AM > Subject: Re: new features in 5.0.11 > > >> It's nice that you think that. >> >> The reality is that almost every application I've worked on or >> consulted for had a subset of pages that needed to be protected via >> HTTPS and the remainder could operate via HTTP. >> >> On Thu, Mar 13, 2008 at 6:01 PM, kranga <[EMAIL PROTECTED]> wrote: >>> Defining secure access via HTTPS is a high level architectural decision. >>> Seldom is one going to want to do that by annotation. >>> >>> ----- Original Message ----- >>> From: "Angelo Chen" <[EMAIL PROTECTED]> >>> To: <users@tapestry.apache.org> >>> Sent: Thursday, March 13, 2008 10:07 AM >>> Subject: t5: new features in 5.0.11 >>> >>> >>>> >>>> Hi, >>>> >>>> As usual I always like to look at new features of every release, here >>> are >>>> the one officially listed as new to the 5.0.11: >>>> >>>> 1. The @Cached annotation has been added to allowing the caching of >>> method >>>> results. >>>> >>>> Can't understand this, any use case to explain this? >>>> >>>> 2. Tapestry can now generate accessor methods for fields automatically >>> via >>>> the @Property annotation. >>>> >>>> This is a cool feature, saving a lot of code. >>>> >>>> 3. It is now possible to override the built-in display and edit blocks >>> for >>>> data types. >>>> >>>> What's this? >>>> >>>> 4. Tapestry now supports "Index" pages at the root or in sub-folders. >>>> >>>> nice feature. >>>> >>>> 5. Tapestry pages may now be secured for access only via HTTPS. >>>> >>>> good feature. >>>> >>>> 6. Added the FormFragment component to allow for forms that are >>> mutable on >>>> the client-side. In addition, the Form component may now update a >>> Zone. >>>> >>>> good feature. >>>> >>>> a.c. >>>> -- >>>> View this message in context: >>>> >>> http://www.nabble.com/t5%3A-new-features-in-5.0.11-tp16025541p16025541.html >>>> Sent from the Tapestry - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
