You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Henri Dupre <he...@gmail.com> on 2005/11/03 19:52:17 UTC

PageRedirectException in pageBeginRender or pageAttached

I had a strange problem by throwing a PageRedirectException in a
pageBeginRender method: the encoding of the redirected page was
screwed up.
But it seems to work well in pageAttached.
So if PageRedirectException doesn't work correctly in pageBeginRender,
maybe it should be banned? (throw an ApplicationException)

Thanks,

Henri.

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Jesse Kuhnert <jk...@gmail.com>.
Hmmm....Maybe you have a point.

On 11/3/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
> Jesse Kuhnert wrote:
> > There is such a thing as creating a patch you know. Being ignored after
> > submitted a very acceptable patch and being ignored after submitting a
> bug
> > request are two very different things. I think with open source projects
> you
> > kind of have to either pay for it/fix it yourself/wait until it's fixed
> for
> > you. I know the first option is available by going to
> > tapestrysupport.com <http://tapestrysupport.com><
> http://tapestrysupport.com>;)
> >
> Oh yes. There also such a thing as feedback. I contributed once a patch
> to this project, only to see that it's sitting around hoping someone
> will look at it:
>
> http://issues.apache.org/jira/browse/TAPESTRY-628
>
> This is a simple patch for what I was asking for, it just adds a file to
> the codebase, and that's it. Sure, it needs some work, but its a good
> start.
> But it's still floating around.
>
> Now, for this other issue:
>
> http://issues.apache.org/jira/browse/TAPESTRY-735
>
> I didn't provide a patch, but rather asked for feedback. I just wanted
> to know if it was worth it to present a patch (if it was going to be
> included). The component is very handy, it allows to include Javascript
> functions that invoke listeners. Dump LinkSubmit and add this JS
> function to any DirectLink, PageLink, etc. A nice refactoring.
>
> For the exception error, IMO it's a simple catch you have to add:
>
> http://issues.apache.org/jira/browse/TAPESTRY-671
>
> But a frequent (and annoying) trend JIRA-based projects have it's that
> developers close issue reports after rejecting them. In the Bugzilla days,
> one could re-open an issue. Here we can't. Ignoring subsequent comments to
> the JIRA issue is just rude and inconsiderate to the people that are
> contributing to the project (don't worry, Gavin King of Hibernate also does
> that - maybe jboss's last 4 letters have gone to his head and it's
> regrettable to see, for a guy - me - that has been involved in that project
> since 2002). I don't like spamming JIRA databases, so I'd rather whine here
> in the developer's list.
>
> For the redirect error:
>
> http://issues.apache.org/jira/browse/TAPESTRY-607
>
> I didn't provide a patch, since I was exploring the functionality. I *did*
> explore the bug, and said (in the issue, that wasn't reported by me) that it
> was caused by an incorrect reset() on internal forwards, and that Tomcat
> didn't allow for the encoding to be changed after a reset() in the same
> request.
>
> Anyway. I'm just trying to help. But providing patches / errors request
> when nobody's reading them, well ... I have a job, too. I can't waste my
> time talking to the wall.
>
> Somewhere around here Geoff was complaining about something similar. IMO
> his bug was not as critical as he thinks, but I agree with him in that the
> problem is that "nobody cares!"
>
> So, my opinion is, if maintainers don't have time to keep up with all the
> bug reports, then get more developers involved! Maybe it's better to do a
> code freeze for 4.0. Cool! Then go fix the bugs, but don't go talking
> about doing a RC if you still have nasty errors.
>
> I'm all into contributing to open source projects. It contributes with my
> work and I can give something back. But there are 'developer-friendly'
> projects and there are 'ego-friendly' ones. If a developer provides a patch,
> or provides a detailed bug report, or asks for feedback on a complex issue,
> it's not a good idea to ignore him. We're open source developers, not
> beggars.
>
> --
> Ing. Leonardo Quijano Vincenzi
> Director Técnico
> DTQ Software
>
> p.s.: Please, please don't fall in the trap of releasing a bad product /
> bad documentation and then force people to go to TapestrySupport.com.
> It's just unprofessional. I'm not saying you are doing it, but then..
> don't do it, really... (I have enough with JasperReports's lack of
> documentation and all the ads promoting JasperSoft. Sorry, but I'd
> rather see a complete project before thinking of paying support for it).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>

Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Ron Piterman wrote:
> I am also often pissed off with how tapestry is handeling the comunity,
> but you should remember that if you want to add a class (like the 
> patch you sent) it is not neceserily a bug, its a wish, and wishes 
> are... how should i say it... well, free? This "patch" you posted - 
> there is no problem of placing it in your classpath and using it, you 
> *don't* need tapestry to have it in the codebase to use it, and its 
> not a bug which prevents you going on...
Of course. That's what I'm doing. Now, I usually only put 'wishes' I 
think are good for the community as a whole. So, my reasons to include 
them on the Tapestry codebase:

1) Someone could benefit from them. As a note: It's nice to have Tassel, 
but it's usually better to have 2 o3 large component libraries - 
Tapestry Base, Contrib, Tacos - than hundreds of small components. Why? 
Because when they are on one big library they're usually better handled, 
maintained, etc.

2) I could benefit from modifications to it. That's the idea of Open 
Source, right? I give something, and I can expect people to review it, 
put improvements, etc. If you check on the patch, I said it's just a 
basic implementation.


>
> now about real bugs - like Jesse said its open source, but I guess he 
> forogt something important and that is - you don't need the tapestry 
> team in order to apply your patches :
>
> Fix the bug,
> create a patch,
> apply the patch,
> build tapestry,
> bug is gone,
> post the patch to jira.
Yes, but the patch never gets included.

As for patching the code myself, that's a fork. If I'm going to do a 
fork, then I'd better do it large. If not, maintaining my modified 
codebase with the other Tapestry updates is a nightmare. Several people 
on the open source community have talked about it. It's always better to 
*insist* that your patches go to the main code base, instead of patching 
yourself the code.

Now, I did patch the code. But it's a last resort solution. I'd rather 
have those bugs fixed on the main code base.
> If you don't do it this way, and complain that bugs are not being 
> fixed, well... a part from open source is interaction with the community.
>
> Some people understand "interaction" as "I submit a bug and you fix 
> it" - may be, and then again, may be not...
I'm not saying that. Now I do understand it as "I don't know the code as 
well as you. I'm submitting a bug with all detail I could possibly 
gather, and I hope you can fix it in 1 hour, instead of the 8 hours it 
would take me".

-- 
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Jesse Kuhnert wrote:
> Hmmmm...I think patching tapestry locally is a horrible idea, but maybe if
> you just ~have~ to have something in there it could be done in a pinch...
>
> Of course no one has mentioned that I'm sure 80-90% of the patches submitted
> probably either aren't up to snuff with the rest of the code or don't fit
> into the frameworks current/future goals.
>   
That's a good reason to apply / reject them immediately. They call it 
'continuous integration' ;).
> It does look like tapestry needs at least one more committer though. Someone
> to take care of some of those mean bug submissions everyone keeps posting
> when others are too busy. Hmmm...Who could we find to do that? hmmmmmm...Who
> has a lot of code readily available to examine and determine coding style
> and trustabiltity of source? hmmmm..oh well, i don't know anyone like that.
>   
hahaha I wonder who's the victim you're talking about....

Tapestry does need an additional committer, IMHO.
What's the process of becoming one?

-- 
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Jesse Kuhnert <jk...@gmail.com>.
Hmmmm...I think patching tapestry locally is a horrible idea, but maybe if
you just ~have~ to have something in there it could be done in a pinch...

Of course no one has mentioned that I'm sure 80-90% of the patches submitted
probably either aren't up to snuff with the rest of the code or don't fit
into the frameworks current/future goals.

It does look like tapestry needs at least one more committer though. Someone
to take care of some of those mean bug submissions everyone keeps posting
when others are too busy. Hmmm...Who could we find to do that? hmmmmmm...Who
has a lot of code readily available to examine and determine coding style
and trustabiltity of source? hmmmm..oh well, i don't know anyone like that.

On 11/4/05, Ron Piterman <rp...@gmx.net> wrote:
>
> I am also often pissed off with how tapestry is handeling the comunity,
> but you should remember that if you want to add a class (like the patch
> you sent) it is not neceserily a bug, its a wish, and wishes are... how
> should i say it... well, free? This "patch" you posted - there is no
> problem of placing it in your classpath and using it, you *don't* need
> tapestry to have it in the codebase to use it, and its not a bug which
> prevents you going on...
>
> now about real bugs - like Jesse said its open source, but I guess he
> forogt something important and that is - you don't need the tapestry
> team in order to apply your patches :
>
> Fix the bug,
> create a patch,
> apply the patch,
> build tapestry,
> bug is gone,
> post the patch to jira.
>
> If you don't do it this way, and complain that bugs are not being fixed,
> well... a part from open source is interaction with the community.
>
> Some people understand "interaction" as "I submit a bug and you fix it"
> - may be, and then again, may be not...
>
> Cheers,
> Ron
>
> ציטוט Leonardo Quijano Vincenzi:
> > Jesse Kuhnert wrote:
> >
> >> There is such a thing as creating a patch you know. Being ignored after
> >> submitted a very acceptable patch and being ignored after submitting a
> >> bug
> >> request are two very different things. I think with open source
> >> projects you
> >> kind of have to either pay for it/fix it yourself/wait until it's
> >> fixed for
> >> you. I know the first option is available by going to
> >> tapestrysupport.com <http://tapestrysupport.com><
> http://tapestrysupport.com>;)
> >>
> >
> > Oh yes. There also such a thing as feedback. I contributed once a patch
> > to this project, only to see that it's sitting around hoping someone
> > will look at it:
> >
> > http://issues.apache.org/jira/browse/TAPESTRY-628
> >
> > This is a simple patch for what I was asking for, it just adds a file to
> > the codebase, and that's it. Sure, it needs some work, but its a good
> > start.
> > But it's still floating around.
> >
> > Now, for this other issue:
> >
> > http://issues.apache.org/jira/browse/TAPESTRY-735
> >
> > I didn't provide a patch, but rather asked for feedback. I just wanted
> > to know if it was worth it to present a patch (if it was going to be
> > included). The component is very handy, it allows to include Javascript
> > functions that invoke listeners. Dump LinkSubmit and add this JS
> > function to any DirectLink, PageLink, etc. A nice refactoring.
> >
> > For the exception error, IMO it's a simple catch you have to add:
> >
> > http://issues.apache.org/jira/browse/TAPESTRY-671
> >
> > But a frequent (and annoying) trend JIRA-based projects have it's that
> > developers close issue reports after rejecting them. In the Bugzilla
> > days, one could re-open an issue. Here we can't. Ignoring subsequent
> > comments to the JIRA issue is just rude and inconsiderate to the people
> > that are contributing to the project (don't worry, Gavin King of
> > Hibernate also does that - maybe jboss's last 4 letters have gone to his
> > head and it's regrettable to see, for a guy - me - that has been
> > involved in that project since 2002). I don't like spamming JIRA
> > databases, so I'd rather whine here in the developer's list.
> >
> > For the redirect error:
> >
> > http://issues.apache.org/jira/browse/TAPESTRY-607
> >
> > I didn't provide a patch, since I was exploring the functionality. I
> > *did* explore the bug, and said (in the issue, that wasn't reported by
> > me) that it was caused by an incorrect reset() on internal forwards, and
> > that Tomcat didn't allow for the encoding to be changed after a reset()
> > in the same request.
> >
> > Anyway. I'm just trying to help. But providing patches / errors request
> > when nobody's reading them, well ... I have a job, too. I can't waste my
> > time talking to the wall.
> >
> > Somewhere around here Geoff was complaining about something similar. IMO
> > his bug was not as critical as he thinks, but I agree with him in that
> > the problem is that "nobody cares!"
> >
> > So, my opinion is, if maintainers don't have time to keep up with all
> > the bug reports, then get more developers involved! Maybe it's better to
> > do a code freeze for 4.0. Cool! Then go fix the bugs, but don't go
> > talking about doing a RC if you still have nasty errors.
> >
> > I'm all into contributing to open source projects. It contributes with
> > my work and I can give something back. But there are
> > 'developer-friendly' projects and there are 'ego-friendly' ones. If a
> > developer provides a patch, or provides a detailed bug report, or asks
> > for feedback on a complex issue, it's not a good idea to ignore him.
> > We're open source developers, not beggars.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>

Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Ron Piterman <rp...@gmx.net>.
I am also often pissed off with how tapestry is handeling the comunity,
but you should remember that if you want to add a class (like the patch 
you sent) it is not neceserily a bug, its a wish, and wishes are... how 
should i say it... well, free? This "patch" you posted - there is no 
problem of placing it in your classpath and using it, you *don't* need 
tapestry to have it in the codebase to use it, and its not a bug which 
prevents you going on...

now about real bugs - like Jesse said its open source, but I guess he 
forogt something important and that is - you don't need the tapestry 
team in order to apply your patches :

Fix the bug,
create a patch,
apply the patch,
build tapestry,
bug is gone,
post the patch to jira.

If you don't do it this way, and complain that bugs are not being fixed, 
well... a part from open source is interaction with the community.

Some people understand "interaction" as "I submit a bug and you fix it" 
- may be, and then again, may be not...

Cheers,
Ron

ציטוט Leonardo Quijano Vincenzi:
> Jesse Kuhnert wrote:
> 
>> There is such a thing as creating a patch you know. Being ignored after
>> submitted a very acceptable patch and being ignored after submitting a 
>> bug
>> request are two very different things. I think with open source 
>> projects you
>> kind of have to either pay for it/fix it yourself/wait until it's 
>> fixed for
>> you. I know the first option is available by going to
>> tapestrysupport.com<http://tapestrysupport.com>;)
>>   
> 
> Oh yes. There also such a thing as feedback. I contributed once a patch 
> to this project, only to see that it's sitting around hoping someone 
> will look at it:
> 
> http://issues.apache.org/jira/browse/TAPESTRY-628
> 
> This is a simple patch for what I was asking for, it just adds a file to 
> the codebase, and that's it. Sure, it needs some work, but its a good 
> start.
> But it's still floating around.
> 
> Now, for this other issue:
> 
> http://issues.apache.org/jira/browse/TAPESTRY-735
> 
> I didn't provide a patch, but rather asked for feedback. I just wanted 
> to know if it was worth it to present a patch (if it was going to be 
> included). The component is very handy, it allows to include Javascript 
> functions that invoke listeners. Dump LinkSubmit and add this JS 
> function to any DirectLink, PageLink, etc. A nice refactoring.
> 
> For the exception error, IMO it's a simple catch you have to add:
> 
> http://issues.apache.org/jira/browse/TAPESTRY-671
> 
> But a frequent (and annoying) trend JIRA-based projects have it's that 
> developers close issue reports after rejecting them. In the Bugzilla 
> days, one could re-open an issue. Here we can't. Ignoring subsequent 
> comments to the JIRA issue is just rude and inconsiderate to the people 
> that are contributing to the project (don't worry, Gavin King of 
> Hibernate also does that - maybe jboss's last 4 letters have gone to his 
> head and it's regrettable to see, for a guy - me - that has been 
> involved in that project since 2002). I don't like spamming JIRA 
> databases, so I'd rather whine here in the developer's list.
> 
> For the redirect error:
> 
> http://issues.apache.org/jira/browse/TAPESTRY-607
> 
> I didn't provide a patch, since I was exploring the functionality. I 
> *did* explore the bug, and said (in the issue, that wasn't reported by 
> me) that it was caused by an incorrect reset() on internal forwards, and 
> that Tomcat didn't allow for the encoding to be changed after a reset() 
> in the same request.
> 
> Anyway. I'm just trying to help. But providing patches / errors request 
> when nobody's reading them, well ... I have a job, too. I can't waste my 
> time talking to the wall.
> 
> Somewhere around here Geoff was complaining about something similar. IMO 
> his bug was not as critical as he thinks, but I agree with him in that 
> the problem is that "nobody cares!"
> 
> So, my opinion is, if maintainers don't have time to keep up with all 
> the bug reports, then get more developers involved! Maybe it's better to 
> do a code freeze for 4.0. Cool! Then go fix the bugs, but don't go 
> talking about doing a RC if you still have nasty errors.
> 
> I'm all into contributing to open source projects. It contributes with 
> my work and I can give something back. But there are 
> 'developer-friendly' projects and there are 'ego-friendly' ones. If a 
> developer provides a patch, or provides a detailed bug report, or asks 
> for feedback on a complex issue, it's not a good idea to ignore him. 
> We're open source developers, not beggars.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Jesse Kuhnert wrote:
> There is such a thing as creating a patch you know. Being ignored after
> submitted a very acceptable patch and being ignored after submitting a bug
> request are two very different things. I think with open source projects you
> kind of have to either pay for it/fix it yourself/wait until it's fixed for
> you. I know the first option is available by going to
> tapestrysupport.com<http://tapestrysupport.com>;)
>   
Oh yes. There also such a thing as feedback. I contributed once a patch 
to this project, only to see that it's sitting around hoping someone 
will look at it:

http://issues.apache.org/jira/browse/TAPESTRY-628

This is a simple patch for what I was asking for, it just adds a file to 
the codebase, and that's it. Sure, it needs some work, but its a good start.
But it's still floating around.

Now, for this other issue:

http://issues.apache.org/jira/browse/TAPESTRY-735

I didn't provide a patch, but rather asked for feedback. I just wanted 
to know if it was worth it to present a patch (if it was going to be 
included). The component is very handy, it allows to include Javascript 
functions that invoke listeners. Dump LinkSubmit and add this JS 
function to any DirectLink, PageLink, etc. A nice refactoring.

For the exception error, IMO it's a simple catch you have to add:

http://issues.apache.org/jira/browse/TAPESTRY-671

But a frequent (and annoying) trend JIRA-based projects have it's that developers close issue reports after rejecting them. In the Bugzilla days, one could re-open an issue. Here we can't. Ignoring subsequent comments to the JIRA issue is just rude and inconsiderate to the people that are contributing to the project (don't worry, Gavin King of Hibernate also does that - maybe jboss's last 4 letters have gone to his head and it's regrettable to see, for a guy - me - that has been involved in that project since 2002). I don't like spamming JIRA databases, so I'd rather whine here in the developer's list.

For the redirect error:

http://issues.apache.org/jira/browse/TAPESTRY-607

I didn't provide a patch, since I was exploring the functionality. I *did* explore the bug, and said (in the issue, that wasn't reported by me) that it was caused by an incorrect reset() on internal forwards, and that Tomcat didn't allow for the encoding to be changed after a reset() in the same request.

Anyway. I'm just trying to help. But providing patches / errors request when nobody's reading them, well ... I have a job, too. I can't waste my time talking to the wall.

Somewhere around here Geoff was complaining about something similar. IMO his bug was not as critical as he thinks, but I agree with him in that the problem is that "nobody cares!"

So, my opinion is, if maintainers don't have time to keep up with all the bug reports, then get more developers involved! Maybe it's better to do a code freeze for 4.0. Cool! Then go fix the bugs, but don't go talking about doing a RC if you still have nasty errors.

I'm all into contributing to open source projects. It contributes with my work and I can give something back. But there are 'developer-friendly' projects and there are 'ego-friendly' ones. If a developer provides a patch, or provides a detailed bug report, or asks for feedback on a complex issue, it's not a good idea to ignore him. We're open source developers, not beggars.

-- 
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software

p.s.: Please, please don't fall in the trap of releasing a bad product / 
bad documentation and then force people to go to TapestrySupport.com. 
It's just unprofessional. I'm not saying you are doing it, but then.. 
don't do it, really... (I have enough with JasperReports's lack of 
documentation and all the ads promoting JasperSoft. Sorry, but I'd 
rather see a complete project before thinking of paying support for it).



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Jesse Kuhnert <jk...@gmail.com>.
There is such a thing as creating a patch you know. Being ignored after
submitted a very acceptable patch and being ignored after submitting a bug
request are two very different things. I think with open source projects you
kind of have to either pay for it/fix it yourself/wait until it's fixed for
you. I know the first option is available by going to
tapestrysupport.com<http://tapestrysupport.com>;)

If you've got something to contribute I think patches always help. (of
course I'm one to talk...)

jesse

On 11/3/05, Leonardo Quijano Vincenzi <leonardo@dtqsoftware.com > wrote:
>
> Leonardo Quijano Vincenzi wrote:
> > Henri Dupre wrote:
> >> I had a strange problem by throwing a PageRedirectException in a
> >> pageBeginRender method: the encoding of the redirected page was
> >> screwed up.
> >> But it seems to work well in pageAttached.
> >> So if PageRedirectException doesn't work correctly in pageBeginRender,
> >> maybe it should be banned? (throw an ApplicationException)
> >>
> > I think that usually it's better to fix the bug rather than ban legal
> > use of redirection.
> >
> > http://issues.apache.org/jira/browse/TAPESTRY-607
> >
> > Still unsolved.. Mind Bridge wrote something about this getting ready
> > by the end of the week, 2 weeks ago, hehehe.
> > Need any help?
> >
> I forgot I had to insist on another bug. I just find it annoying when
> people ignore you:
>
> http://issues.apache.org/jira/browse/TAPESTRY-671
>
> --
> Ing. Leonardo Quijano Vincenzi
> Director Técnico
> DTQ Software
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>

Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Leonardo Quijano Vincenzi wrote:
> Henri Dupre wrote:
>> I had a strange problem by throwing a PageRedirectException in a
>> pageBeginRender method: the encoding of the redirected page was
>> screwed up.
>> But it seems to work well in pageAttached.
>> So if PageRedirectException doesn't work correctly in pageBeginRender,
>> maybe it should be banned? (throw an ApplicationException)
>>   
> I think that usually it's better to fix the bug rather than ban legal 
> use of redirection.
>
> http://issues.apache.org/jira/browse/TAPESTRY-607
>
> Still unsolved.. Mind Bridge wrote something about this getting ready 
> by the end of the week, 2 weeks ago, hehehe.
> Need any help?
>
I forgot I had to insist on another bug. I just find it annoying when 
people ignore you:

http://issues.apache.org/jira/browse/TAPESTRY-671

-- 
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Re: PageRedirectException in pageBeginRender or pageAttached

Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Henri Dupre wrote:
> I had a strange problem by throwing a PageRedirectException in a
> pageBeginRender method: the encoding of the redirected page was
> screwed up.
> But it seems to work well in pageAttached.
> So if PageRedirectException doesn't work correctly in pageBeginRender,
> maybe it should be banned? (throw an ApplicationException)
>   
I think that usually it's better to fix the bug rather than ban legal 
use of redirection.

http://issues.apache.org/jira/browse/TAPESTRY-607

Still unsolved.. Mind Bridge wrote something about this getting ready by 
the end of the week, 2 weeks ago, hehehe.
Need any help?

-- 
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org