Hi Ben, Thank you for your help. Very useful. I used the same technic with tapestry 4 I had encoder to slugify my objects and keeping the id at the end. I am always wondering if it’s better to have a slug without an id, or with an id. I think that keeping an id is more robust on the long run.
Best Numa > Le 19 nov. 2020 à 09:42, Ben Weidig <b...@netzgut.net> a écrit : > > Hi, > > for custom URLs you could use > org.apache.tapestry5.services.linktransform.PageRenderLinkTransformer > > It's responsible for transforming/decoding > PageRenderRequestParameters/Requests. > This ensures that generated links will be correct, too. > > The only problem here would be the actual mapping between the path and the > actual page / parameters, and vice-versa. > Usually, the path contains some kind of unique identifier, making the > actual name in the path more flexible. > > Medium has a hash at the end to actually identify the correct story, not > the full path. > Amazon has the product title in the URL, even though it can be changed > freely, and it still works due to the rest of the path. > > It all depends on the purpose of the pages, and how often URLs change or > are added. > > Is it a lot of dynamic content, e.g., article or product pages? An added > identifier should be subtle and easier to manage. > Is it a static page, e.g., checkout page? A fixed lookup map might be more > sensible. > > And you should also consider what is supposed to happen if something is > mixed up, e.g. missing locale (/acheter-tickets-concert), or wrong locale > (/fr/buy-concert-ticket). > > These are some of the problems we ran into with our multi-Locale system, I > hope this helps a little. > > Cheers > Ben > > On Thu, Nov 19, 2020 at 8:15 AM Numa Schmeder <n...@dfacto.ch> wrote: > >> Thanks, I will give it a try ! >> >>> Le 19 nov. 2020 à 07:45, Ilya Obshadko <ilya.obsha...@gmail.com> a >> écrit : >>> >>> Yes, you can do it this way: >>> >>> @Inject >>> private PageRenderLinkTransformer linkTransformer; >>> >>> @Inject >>> private RequestGlobals requestGlobals; >>> >>> PageRenderRequestParameters requestParameters = >>> linkTransformer.decodePageRenderRequest(requestGlobals.getRequest()); >>> >>> >>> >>> >>> >>> On Wed, Nov 18, 2020 at 6:09 PM Numa Schmeder <n...@dfacto.ch> wrote: >>> >>>> Hello, >>>> >>>> Just wondering if you have a way to access the >> PageRenderRequestParameters >>>> inside a component. >>>> >>>> I am building a LocalePageLink component for SEO purpose, that >> translates >>>> the current page url into its localized version, instead of using a >> locale >>>> toggle with an action link. >>>> >>>> I need it for SEO friendly language switcher but also for alternate >> href. >>>> >>>> My component is working correctly, and will render >>>> <a href="#" t:type="LocalePageLink" t:id="localeEN" locale="en" >>>> page="mypagename” context=“1"> EN </a> >>>> will render: /en/mypagename/1 for locale en >>>> >>>> <a href="#" t:type="LocalePageLink" t:id="localeFR" locale=“fr" >>>> page="mypagename” context=“1"> EN </a> >>>> will render: /en/mypagename/1 for locale fr >>>> >>>> But I want my component to be smarter and deduce the page name, context >>>> and parameters from the current url if they are not specified to the >>>> component. >>>> I know how to get the page name using componentResources, but I didn’t >>>> find a way to get the activation context and the context parameters >> without >>>> parsing the url. >>>> >>>> On the same subject I would like to have better page name than the >> “java” >>>> page name. For example if my page name is BuyTicket.java I would like to >>>> have >>>> /en/buy-concert-ticket in english >>>> /fr/acheter-tickets-concert in french >>>> … and so on. >>>> >>>> So I would like to localize page names in url, and eventually improve >> the >>>> name for SEO purpose, do you know where should I hook ? >>>> >>>> I would be happy to share my components once they are functional. >>>> >>>> Thank you for your help, >>>> >>>> Numa >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>>> >>>> >>> >>> -- >>> Ilya Obshadko >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
