I can just reiterate how important pagename localization is (I don't care about full rewriting, parameter orders or component names, but just the visible/bookmarkable URLs to the rest of the world). Yes you can do everything in apache rewrite rules but I consider this a workaround which increases maintenance costs/effort.
In todays world where restful, meaningful URLs are so important there is no way around localized URLs. For a developer it is clearly more convient to have URLs built from pagenames, however that changes quickly if he is required to maintain a seperate set of apache rewrite ruls and provide them to a different ops departement etc, etc. So I would ask not to reinvent the wheel but provide some needed basics. Regards, Markus On Tue, Mar 10, 2009 at 7:30 PM, Fernando Padilla <[email protected]> wrote: > my two cents: > > I say, if you want full featured URLRewrite, that should be done outside of > tapestry.. Why should tapestry try to reinvent, then maintain the wheel.. :) > > > If you want pageNames localization, well, that is a nice feature to explore > how to do it within tapestry.. but could get messy quickly.. > since ComponentResolver would have to be locale aware, and LinkFactory would > have to be locale aware (pass in optional locale for each of their methods). > But not only that, only when parsing/generating user facing urls, so when I > refer to a page in my code through a pagelink/createPageLink, then it's > through a default code-locale not user-locale. :) But the link generated is > in user-locale. :) > > and what if there are page-name alias clashes? will have to add the > requirement that all localizations are unique for all pages? > > keep working on it :) > > ps - and I just realized, this is just for pagenames.. do you need to > localize component names too?? > > > > > On 3/10/09 11:14 AM, Howard Lewis Ship wrote: >> >> Yes, it does seem to be a partial solution as it will encourage people >> to bypass Tapestry link creation facilities to generate the url they >> want ... this comes down to something that could be done with a >> servlet filter around Tapestry almost as well. I think people were >> hoping for a full-featured solution, perhaps based on annotations on >> the pages. >> >> The problem with partial solutions is there's an implicit commitment >> to maintain this forever and there's the potential that it will >> interfere with a more full-bore solution. Probably not, and (to be >> honest) many of the features I've added are somewhat minimal as well. >> >> My goal with the built-in Tapestry "friendly" URL support was to have >> Tapestry generate short names that were sensible to the *developer* >> and similar to what a developer would create as a hand-tooled URL. It >> was never to make the URLs sensible to end-users, or to make them >> localized. >> >> On Tue, Mar 10, 2009 at 10:29 AM, Andreas Andreou<[email protected]> >> wrote: >>> >>> Hi... comments inline >>> >>> On Tue, Mar 10, 2009 at 2:05 PM, Thiago H. de Paula Figueiredo >>> <[email protected]> wrote: >>>> >>>> On Tue, Mar 10, 2009 at 3:04 AM, Andreas Andreou<[email protected]> >>>> wrote: >>>>> >>>>> Hi >>>> >>>> Hi, Andreas! >>>> >>>> - i'm just trying to understand a few things here, esp. >>>>> >>>>> since i saw that TAP5-557 is now closed... So: >>>>> 1) is this still a work in progress? >>>> >>>> My plan in 557 was to provide *basic* support to URL rewriting. In my >>>> humble opinion, this is implemented. It's so basic and simple that >>>> more sophisticated rewriting rules can be easily added on the top of >>>> it (regular expression, etc). >>>> >>>>> 2) how / who will generate the urls that those new urlrewrite services >>>>> can handle? >>>> >>>> I guess I need to reopen 557 to cover this part . . . The new code >>>> handles the requests, not the link generation . . . I guess I'll need >>>> to decorate LinkFactory . . . >>> >>> So, you don't have to reopen 557 just because i said so... For >>> whatever reasons, >>> I thought that link generation would be covered as well (probably due to >>> my >>> familiarity with T4's ServiceEncoder interface) and I mentioned it since >>> it may require changes to the new and public URLRewriterRule class. >>> >>> >>>>> thx and nice to see your first contribution! >>>> >>>> I'm very happy to finally contribute some code to a project I love, >>>> use and recommend. :) >>>> >>>> -- >>>> Thiago >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> -- >>> Andreas Andreou - [email protected] - http://blog.andyhot.gr >>> Tapestry / Tacos developer >>> Open Source / JEE Consulting >>> >>> --------------------------------------------------------------------- >>> 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]
