As mentioned in a few threads in the user's list ( http://markmail.org/message/jmava67vkpkn5dsy ) full incoming-outgoing rewritting with parameter reordering, e.t.c. can be easily done with filters such as http://tuckey.org/urlrewrite/
That's why i asked then what's the usecase that this new service will cover. It now seems (and it's something i've never thought of) that pagename localization is a valid usecase and one that a custom UrlRewriteRule can cover if and only if url generation is also part of the new additions. On Tue, Mar 10, 2009 at 10:17 PM, Markus Joschko <[email protected]> wrote: > 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] > > -- 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]
