I second Markus' opinion. I could care less what the URLs look like to the developer, after all, that's who writes the code and would be familiar w/ whatever scheme the framework provides.
A bunch of the next-gen web frameworks ( Rails, Grails, Wicket) have a way of specifying some kind of URL rewriting to provide friendly URLs. The whole point of having a web framework is to pull the common usage patterns together and make them convenient to use. If Tapestry shouldn't reinvent and maintain the wheel (that is, URL rewriting), then it should at least provide clean integration w/ an existing wheel (as it does w/ its Spring & Hibernate integration) that fits well w/ the existing T5 usage patterns (e.g. maybe the ability to configure the Tuckey URL rewriting for T5 pages). Cheers, Alex Kotchnev On Tue, Mar 10, 2009 at 4: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] > >
