Re: PageURL rewriting deprecated
Please post examples always considering the application being deployed as root (/), so we don't need to guess whether MyApp is a page, package or context name. So, considering /MyPage/1 needs to be rewritten to /1 and MyPage is the only one with URLs like that, the easiest way is to avoid URL rewriting. Instead, rename MyPage (both class and template) to Index and it will work. On Mon, Jun 17, 2013 at 8:06 PM, Nomen Nomanum wrote: > Also, I plead You to explain me in text of course( not by source code ), > if You can step by step how to change following: > > localhost:8080/MyApp/MyPage1/1 > to just > localhost:8080/MyApp/1 > > How to delete MyPage1 context from link url and to leave only > > localhost:8080/MyApp/1 > > -- Thiago
Re: PageURL rewriting deprecated
On Mon, Jun 17, 2013 at 8:01 PM, Nomen Nomanum wrote: > You are master, master of knowledge, I just can say I'm a master at something because I have an master degree in Computer Science. :P Not of much use, but I had lot of fun in getting it, so it was well worth it. :) > So, back to topic, why my app fails when I deploy it as ROOT, clicking on > any link, it takes him to nowhere, ie. if I click to lets say Fashion link, > it directs him to > > listFashion.Fashion ( and with it points to nothing, instead just to > Fashion ), ie component linking is not bound, if You follow me here. When talking about an error, please always post the stack trace (if any). -- Thiago
RE: PageURL rewriting deprecated
Also, I plead You to explain me in text of course( not by source code ), if You can step by step how to change following: localhost:8080/MyApp/MyPage1/1 to just localhost:8080/MyApp/1 How to delete MyPage1 context from link url and to leave only localhost:8080/MyApp/1
RE: PageURL rewriting deprecated
You are master, master of knowledge, giving help thousands of people here who strive for it, so don't be modest. Your words expose to us new light how things function in a best possible way. For instance, without you I nor my fellows wouldn't know this: This first level (the context/webapp name) isn't handled by Tapestry, but by Tomcat/Jetty/other servlet container, so no URL rewriting logic in Tapestry (or any other framework) would work here. :) So, back to topic, why my app fails when I deploy it as ROOT, clicking on any link, it takes him to nowhere, ie. if I click to lets say Fashion link, it directs him to listFashion.Fashion ( and with it points to nothing, instead just to Fashion ), ie component linking is not bound, if You follow me here.
Re: PageURL rewriting deprecated
On Mon, Jun 17, 2013 at 3:15 PM, Nomen Nomanum wrote: > Hi, @Thiago! :) > Hi! > Yes, you are right, I have no idea what am I doing. But with a help from > master, I hope I will. My scenario is following: > Hey, I'm no master, just someone with a love for posting in mailing lists . . . > I have something as following: > localhost:8083/MyApp/MyPage > now I want to be something like > localhost:8083/MyPage > This first level (the context/webapp name) isn't handled by Tapestry, but by Tomcat/Jetty/other servlet container, so no URL rewriting logic in Tapestry (or any other framework) would work here. > So, I have renamed my war file to ROOT file, and in order this to work, I > have to rewrite incoming and outcoming URLS, Nope (at least if I understood what you're saying, maybe not), you don't need to do anything for the URLs to work. Tapestry (with the servlet container) takes care of the URLs.
RE: PageURL rewriting deprecated
Hi, @Thiago! :)
Yes, you are right, I have no idea what am I doing. But with a help from
master, I hope I will. My scenario is following:
I have something as following:
localhost:8083/MyApp/MyPage
now I want to be something like
localhost:8083/MyPage
So, I have renamed my war file to ROOT file, and in order this to work, I have
to rewrite incoming and outcoming URLS, so it would be something like
RewriteRuleApplicability.BOTH; . So, I will have to have decodePage rule in
which to substring everything before first "/" and process method to process my
incoming and outcoming urls, to test whether path starts with
localhost:8083/MyApp/MyPage
and to change it to
localhost:8083/MyPage
Is there any light in my vision, master?
> Date: Mon, 17 Jun 2013 14:20:43 -0300
> Subject: Re: PageURL rewriting deprecated
> From: thiag...@gmail.com
> To: users@tapestry.apache.org
>
> Hi, Nomen!
>
> I didn't understand what you're trying to do nor you said what do you mean
> by "it won't work". Do you want to rewrite incoming URLs (i.e. the ones
> received by Tapestry) or outgoing ones (i.e. the ones generated by
> Tapestry)? Anyway, your logic seems wrong, indicating you don't know yet
> what you're doing.
>
>
> On Mon, Jun 17, 2013 at 11:32 AM, Nomen Nomanum wrote:
>
> > Your module is great, @Thiago, however it seems to me I can't setup the
> > following scenario:
> >
> > Substring everything before second /, ie
> >
> > localhost:8080/X/Y/Z/
> > where X stands for app name. I have tried the following, but it won't work.
> >
> > URLRewriterRule rule1 = new URLRewriterRule() {
> > public Request process(Request request,
> > URLRewriteContext context) {String serverName =
> > request.getServerName();String path =
> > request.getPath().toLowerCase(); if
> > (serverName.equals("localhost") && path.equals("/X")) {
> > request = new SimpleRequestWrapper(request, "/");
> > } return request;
> > }
> > public RewriteRuleApplicability applicability() {
> > return RewriteRuleApplicability.OUTBOUND;
> > }
> > };so that final output would be something like
> > localhost:8080/Y/Z/
> > instead of
> > localhost:8080/X/Y/Z/
> >
> >
> > > To: users@tapestry.apache.org
> > > Subject: Re: PageURL rewriting deprecated
> > > Date: Sun, 16 Jun 2013 16:56:21 -0300
> > > From: thiag...@gmail.com
> > >
> > > On Sun, 16 Jun 2013 14:06:22 -0300, Howard Lewis Ship
> > > wrote:
> > >
> > > > The original implementation of url rewriting was flawed and replaced.
> > >
> > > Why flawed? Besides a couple bugs, it worked. I'd say it has some
> > > advantages and disadvantages over the current Link Rewriter API. IMHO URL
> > > rewriter is better at incoming URLs and Link Rewriter at outgoing ones.
> > >
> > > I ported it (the Tapestry 5.1.0.5 URL rewriter API) to Tapestry 5.3.x and
> > > the code is here: https://github.com/thiagohp/tapestry-url-rewriter.
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > > For additional commands, e-mail: users-h...@tapestry.apache.org
> > >
> >
>
>
>
>
> --
> Thiago
Re: PageURL rewriting deprecated
Hi, Nomen!
I didn't understand what you're trying to do nor you said what do you mean
by "it won't work". Do you want to rewrite incoming URLs (i.e. the ones
received by Tapestry) or outgoing ones (i.e. the ones generated by
Tapestry)? Anyway, your logic seems wrong, indicating you don't know yet
what you're doing.
On Mon, Jun 17, 2013 at 11:32 AM, Nomen Nomanum wrote:
> Your module is great, @Thiago, however it seems to me I can't setup the
> following scenario:
>
> Substring everything before second /, ie
>
> localhost:8080/X/Y/Z/
> where X stands for app name. I have tried the following, but it won't work.
>
> URLRewriterRule rule1 = new URLRewriterRule() {
> public Request process(Request request,
> URLRewriteContext context) {String serverName =
> request.getServerName();String path =
> request.getPath().toLowerCase(); if
> (serverName.equals("localhost") && path.equals("/X")) {
> request = new SimpleRequestWrapper(request, "/");
> } return request;
> }
> public RewriteRuleApplicability applicability() {
> return RewriteRuleApplicability.OUTBOUND;
> }
> };so that final output would be something like
> localhost:8080/Y/Z/
> instead of
> localhost:8080/X/Y/Z/
>
>
> > To: users@tapestry.apache.org
> > Subject: Re: PageURL rewriting deprecated
> > Date: Sun, 16 Jun 2013 16:56:21 -0300
> > From: thiag...@gmail.com
> >
> > On Sun, 16 Jun 2013 14:06:22 -0300, Howard Lewis Ship
> > wrote:
> >
> > > The original implementation of url rewriting was flawed and replaced.
> >
> > Why flawed? Besides a couple bugs, it worked. I'd say it has some
> > advantages and disadvantages over the current Link Rewriter API. IMHO URL
> > rewriter is better at incoming URLs and Link Rewriter at outgoing ones.
> >
> > I ported it (the Tapestry 5.1.0.5 URL rewriter API) to Tapestry 5.3.x and
> > the code is here: https://github.com/thiagohp/tapestry-url-rewriter.
> >
> > --
> > Thiago H. de Paula Figueiredo
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
>
--
Thiago
RE: PageURL rewriting deprecated
Your module is great, @Thiago, however it seems to me I can't setup the
following scenario:
Substring everything before second /, ie
localhost:8080/X/Y/Z/
where X stands for app name. I have tried the following, but it won't work.
URLRewriterRule rule1 = new URLRewriterRule() {
public Request process(Request request,
URLRewriteContext context) {String serverName =
request.getServerName();String path =
request.getPath().toLowerCase(); if
(serverName.equals("localhost") && path.equals("/X")) {
request = new SimpleRequestWrapper(request, "/");
} return request;
}
public RewriteRuleApplicability applicability() {
return RewriteRuleApplicability.OUTBOUND;
}
};so that final output would be something like
localhost:8080/Y/Z/
instead of
localhost:8080/X/Y/Z/
> To: users@tapestry.apache.org
> Subject: Re: PageURL rewriting deprecated
> Date: Sun, 16 Jun 2013 16:56:21 -0300
> From: thiag...@gmail.com
>
> On Sun, 16 Jun 2013 14:06:22 -0300, Howard Lewis Ship
> wrote:
>
> > The original implementation of url rewriting was flawed and replaced.
>
> Why flawed? Besides a couple bugs, it worked. I'd say it has some
> advantages and disadvantages over the current Link Rewriter API. IMHO URL
> rewriter is better at incoming URLs and Link Rewriter at outgoing ones.
>
> I ported it (the Tapestry 5.1.0.5 URL rewriter API) to Tapestry 5.3.x and
> the code is here: https://github.com/thiagohp/tapestry-url-rewriter.
>
> --
> Thiago H. de Paula Figueiredo
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
Re: PageURL rewriting deprecated
On Sun, 16 Jun 2013 14:06:22 -0300, Howard Lewis Ship wrote: The original implementation of url rewriting was flawed and replaced. Why flawed? Besides a couple bugs, it worked. I'd say it has some advantages and disadvantages over the current Link Rewriter API. IMHO URL rewriter is better at incoming URLs and Link Rewriter at outgoing ones. I ported it (the Tapestry 5.1.0.5 URL rewriter API) to Tapestry 5.3.x and the code is here: https://github.com/thiagohp/tapestry-url-rewriter. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: PageURL rewriting deprecated
The original implementation of url rewriting was flawed and replaced. On Sunday, June 16, 2013, Nomen Nomanum wrote: > Hi. > I am using latest version of Tap, and in it URL rewriting module is > deprecated. What troubles me is why is it deprecated, any particular reason > for it, or just because there are many others modules which contribute to > that part more optimal like Apaches mod, Tuckey etc... Also, if you had an > experience with this field so far what alternative would you recommend for > page url rewriting that would suit the best? > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
PageURL rewriting deprecated
Hi. I am using latest version of Tap, and in it URL rewriting module is deprecated. What troubles me is why is it deprecated, any particular reason for it, or just because there are many others modules which contribute to that part more optimal like Apaches mod, Tuckey etc... Also, if you had an experience with this field so far what alternative would you recommend for page url rewriting that would suit the best?
