Re: Index vs. invalid path

2011-04-04 Thread Thiago H. de Paula Figueiredo
On Mon, 04 Apr 2011 18:46:05 -0300, Josh Canfield   
wrote:



Thiago,
I prefer another approach: according to my experience, it's rare to  
have an

Index page with activation context parameters.


This is a little presumptuous. I have built a couple apps where I use
the index page activation parameters to pull html content from a
database.


So I guess we can provide a mixin and/or annotation that returns a 404  
when the activation context is not empty and let developers decide when  
and where to use it. I agree that we cannot make any good guesses for this  
scenario, so lets just provide a tool and document it.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Index vs. invalid path

2011-04-04 Thread Josh Canfield
Thiago,
>> I prefer another approach: according to my experience, it's rare to have an
>> Index page with activation context parameters.

This is a little presumptuous. I have built a couple apps where I use
the index page activation parameters to pull html content from a
database.

> The typical URL will be
> "/user/12345" but an errant CSS rule or relative URL to an image can
> result in "/user/images/icon.png" and a NumericFormatException trying
> to convert "images" to a Long (before accessing the User).

I haven't done the due diligence to know if it would be an easy matter
to simply return a 404 at the point we realize the types don't match,
but doesn't that seem like reasonable default behavior? In
non-production mode we can still return a useful body explaining what
happened. In production mode we give a standard "not found" body.

Josh

On Mon, Apr 4, 2011 at 1:04 PM, Howard Lewis Ship  wrote:
> On Mon, Apr 4, 2011 at 12:08 PM, Thiago H. de Paula Figueiredo
>  wrote:
>> On Mon, 04 Apr 2011 14:29:26 -0300, Howard Lewis Ship 
>> wrote:
>>
>>> @MatchExtraPath("\\d+")
>>> public class Index
>>> {
>>> }
>>
>> I prefer another approach: according to my experience, it's rare to have an
>> Index page with activation context parameters. Thus, I think we can create a
>> mixin that raises a 404 when page activation context is not empty,
>> automatically apply it to all Index pages and have a configuration symbol to
>> configure this, most probably with a false default value to provide
>> backwards compatibility.
>
> This may be true at the root level, but I often create index pages in
> subpackages for this purpose, i.e. root.pages.user.UserIndex that has
> a page activation context that's a user id.  The typical URL will be
> "/user/12345" but an errant CSS rule or relative URL to an image can
> result in "/user/images/icon.png" and a NumericFormatException trying
> to convert "images" to a Long (before accessing the User).
>
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
>> instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
>
>
>
> --
> 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
>
> -
> 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



Re: Index vs. invalid path

2011-04-04 Thread Howard Lewis Ship
But a no-args activation method will still be a failure, and result in
HTML content (from the page, or from the exception page) being
streamed to the client instead of the requested content. We really
want to get a 404 down to the client, and the best way to do that is
to have the PageDispatcher return false (rather than process the
request and return true).

On Mon, Apr 4, 2011 at 1:05 PM, Igor Drobiazko  wrote:
> What about @IgnoreInvalidContext anntation instead of @MatchExtraPath?
> Wouldn't it do the job? If the context is invalid, we check if
> @IgnoreInvalidContext is present. If so, the exception is caught and no-args
> activation method is invoked.
>
> On Mon, Apr 4, 2011 at 10:02 PM, Howard Lewis Ship  wrote:
>
>> I think we're definitely seeing some different concerns within
>> Tapestry conflicting with each other.
>>
>> On Mon, Apr 4, 2011 at 12:47 PM, Igor Drobiazko
>>  wrote:
>> > Tapestry is known for taking over the plumbing work and this solution
>> > somehow goes against this philosophy. In most cases a user don't have to
>> > know how the context value is converted from string to a server-side
>> object
>> > and vice versa. Providing @MetchExtraPath annotationthe user adds some
>> kind
>> > of redundancy.
>> >
>> > On Mon, Apr 4, 2011 at 7:29 PM, Howard Lewis Ship 
>> wrote:
>> >
>> >> Just had a thought (hopefully original) about dealing with the issue
>> >> of Index pages and bad paths.
>> >>
>> >> This comes up with Tapestry often enough; an errant entry in a CSS
>> >> file, or a manually mangled URL, and an Index page is activated with
>> >> an invalid page activation context, resulting in an exception.
>> >>
>> >> But it just occurred to me that in most cases, we will know what the
>> >> page activation context will look like (for example, a series of
>> >> digits is most likely) ... something that can be expressed as a
>> >> regular expression.
>> >>
>> >> So how about something like:
>> >>
>> >> @MatchExtraPath("\\d+")
>> >> public class Index
>> >> {
>> >> }
>> >>
>> >> This would identify the page activation context (the extra path) as
>> >> needed to match the pattern \d+  (a series of at least one digit).
>> >>
>> >> So, once the page is identified, the PageDispatcher (contributed to
>> >> the MasterDispatcher chain of command) can examine the page to see if
>> >> it has the @MatchExtraPath and, if so, continue searching if the extra
>> >> path does not match.
>> >>
>> >> --
>> >> 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
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> >> For additional commands, e-mail: dev-h...@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Igor Drobiazko
>> > http://tapestry5.de
>> >
>>
>>
>>
>> --
>> 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
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>



-- 
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

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



Re: Index vs. invalid path

2011-04-04 Thread Igor Drobiazko
What about @IgnoreInvalidContext anntation instead of @MatchExtraPath?
Wouldn't it do the job? If the context is invalid, we check if
@IgnoreInvalidContext is present. If so, the exception is caught and no-args
activation method is invoked.

On Mon, Apr 4, 2011 at 10:02 PM, Howard Lewis Ship  wrote:

> I think we're definitely seeing some different concerns within
> Tapestry conflicting with each other.
>
> On Mon, Apr 4, 2011 at 12:47 PM, Igor Drobiazko
>  wrote:
> > Tapestry is known for taking over the plumbing work and this solution
> > somehow goes against this philosophy. In most cases a user don't have to
> > know how the context value is converted from string to a server-side
> object
> > and vice versa. Providing @MetchExtraPath annotationthe user adds some
> kind
> > of redundancy.
> >
> > On Mon, Apr 4, 2011 at 7:29 PM, Howard Lewis Ship 
> wrote:
> >
> >> Just had a thought (hopefully original) about dealing with the issue
> >> of Index pages and bad paths.
> >>
> >> This comes up with Tapestry often enough; an errant entry in a CSS
> >> file, or a manually mangled URL, and an Index page is activated with
> >> an invalid page activation context, resulting in an exception.
> >>
> >> But it just occurred to me that in most cases, we will know what the
> >> page activation context will look like (for example, a series of
> >> digits is most likely) ... something that can be expressed as a
> >> regular expression.
> >>
> >> So how about something like:
> >>
> >> @MatchExtraPath("\\d+")
> >> public class Index
> >> {
> >> }
> >>
> >> This would identify the page activation context (the extra path) as
> >> needed to match the pattern \d+  (a series of at least one digit).
> >>
> >> So, once the page is identified, the PageDispatcher (contributed to
> >> the MasterDispatcher chain of command) can examine the page to see if
> >> it has the @MatchExtraPath and, if so, continue searching if the extra
> >> path does not match.
> >>
> >> --
> >> 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
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: dev-h...@tapestry.apache.org
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > Igor Drobiazko
> > http://tapestry5.de
> >
>
>
>
> --
> 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de


Re: Index vs. invalid path

2011-04-04 Thread Howard Lewis Ship
On Mon, Apr 4, 2011 at 12:08 PM, Thiago H. de Paula Figueiredo
 wrote:
> On Mon, 04 Apr 2011 14:29:26 -0300, Howard Lewis Ship 
> wrote:
>
>> @MatchExtraPath("\\d+")
>> public class Index
>> {
>> }
>
> I prefer another approach: according to my experience, it's rare to have an
> Index page with activation context parameters. Thus, I think we can create a
> mixin that raises a 404 when page activation context is not empty,
> automatically apply it to all Index pages and have a configuration symbol to
> configure this, most probably with a false default value to provide
> backwards compatibility.

This may be true at the root level, but I often create index pages in
subpackages for this purpose, i.e. root.pages.user.UserIndex that has
a page activation context that's a user id.  The typical URL will be
"/user/12345" but an errant CSS rule or relative URL to an image can
result in "/user/images/icon.png" and a NumericFormatException trying
to convert "images" to a Long (before accessing the User).

>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>



-- 
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

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



Re: Index vs. invalid path

2011-04-04 Thread Howard Lewis Ship
I think we're definitely seeing some different concerns within
Tapestry conflicting with each other.

On Mon, Apr 4, 2011 at 12:47 PM, Igor Drobiazko
 wrote:
> Tapestry is known for taking over the plumbing work and this solution
> somehow goes against this philosophy. In most cases a user don't have to
> know how the context value is converted from string to a server-side object
> and vice versa. Providing @MetchExtraPath annotationthe user adds some kind
> of redundancy.
>
> On Mon, Apr 4, 2011 at 7:29 PM, Howard Lewis Ship  wrote:
>
>> Just had a thought (hopefully original) about dealing with the issue
>> of Index pages and bad paths.
>>
>> This comes up with Tapestry often enough; an errant entry in a CSS
>> file, or a manually mangled URL, and an Index page is activated with
>> an invalid page activation context, resulting in an exception.
>>
>> But it just occurred to me that in most cases, we will know what the
>> page activation context will look like (for example, a series of
>> digits is most likely) ... something that can be expressed as a
>> regular expression.
>>
>> So how about something like:
>>
>> @MatchExtraPath("\\d+")
>> public class Index
>> {
>> }
>>
>> This would identify the page activation context (the extra path) as
>> needed to match the pattern \d+  (a series of at least one digit).
>>
>> So, once the page is identified, the PageDispatcher (contributed to
>> the MasterDispatcher chain of command) can examine the page to see if
>> it has the @MatchExtraPath and, if so, continue searching if the extra
>> path does not match.
>>
>> --
>> 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
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
> http://tapestry5.de
>



-- 
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

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



Re: Index vs. invalid path

2011-04-04 Thread Igor Drobiazko
Tapestry is known for taking over the plumbing work and this solution
somehow goes against this philosophy. In most cases a user don't have to
know how the context value is converted from string to a server-side object
and vice versa. Providing @MetchExtraPath annotationthe user adds some kind
of redundancy.

On Mon, Apr 4, 2011 at 7:29 PM, Howard Lewis Ship  wrote:

> Just had a thought (hopefully original) about dealing with the issue
> of Index pages and bad paths.
>
> This comes up with Tapestry often enough; an errant entry in a CSS
> file, or a manually mangled URL, and an Index page is activated with
> an invalid page activation context, resulting in an exception.
>
> But it just occurred to me that in most cases, we will know what the
> page activation context will look like (for example, a series of
> digits is most likely) ... something that can be expressed as a
> regular expression.
>
> So how about something like:
>
> @MatchExtraPath("\\d+")
> public class Index
> {
> }
>
> This would identify the page activation context (the extra path) as
> needed to match the pattern \d+  (a series of at least one digit).
>
> So, once the page is identified, the PageDispatcher (contributed to
> the MasterDispatcher chain of command) can examine the page to see if
> it has the @MatchExtraPath and, if so, continue searching if the extra
> path does not match.
>
> --
> 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de


Re: Index vs. invalid path

2011-04-04 Thread Thiago H. de Paula Figueiredo
On Mon, 04 Apr 2011 14:29:26 -0300, Howard Lewis Ship   
wrote:



@MatchExtraPath("\\d+")
public class Index
{
}


I prefer another approach: according to my experience, it's rare to have  
an Index page with activation context parameters. Thus, I think we can  
create a mixin that raises a 404 when page activation context is not  
empty, automatically apply it to all Index pages and have a configuration  
symbol to configure this, most probably with a false default value to  
provide backwards compatibility.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Home page layout

2011-04-04 Thread Howard Lewis Ship
On Mon, Apr 4, 2011 at 11:39 AM, Howard Lewis Ship  wrote:
> Just experimented using Chrome; adding a style="clear:both;" to the
>  tag justing before div#footer does the trick.
>
> I'll go fix that ...

Cancel that ... I'm a bit overloaded right now.  I'll get to it later,
but I'm hoping someone else will take care of it. Thanks!


>
> On Mon, Apr 4, 2011 at 11:35 AM, Ulrich Stärk  wrote:
>> I gues a style="clear:both;" somewhere will do the trick. although we then 
>> will have some blank
>> space below the main content.
>>
>> On 04.04.2011 19:50, Howard Lewis Ship wrote:
>>> Now that we have a few postings in the blog, the Twitter window is
>>> laid out poorly (it extends beyond the footer and looks quite odd).
>>> Any ideas on how to deal with that?  I don't want to give up either
>>> the blog postings or the twitter feed. Maybe we have to more severely
>>> limit the excerpted content from the blog entries?
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: dev-h...@tapestry.apache.org
>>
>>
>
>
>
> --
> 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
>



-- 
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

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



Re: Home page layout

2011-04-04 Thread Howard Lewis Ship
Just experimented using Chrome; adding a style="clear:both;" to the
 tag justing before div#footer does the trick.

I'll go fix that ...

On Mon, Apr 4, 2011 at 11:35 AM, Ulrich Stärk  wrote:
> I gues a style="clear:both;" somewhere will do the trick. although we then 
> will have some blank
> space below the main content.
>
> On 04.04.2011 19:50, Howard Lewis Ship wrote:
>> Now that we have a few postings in the blog, the Twitter window is
>> laid out poorly (it extends beyond the footer and looks quite odd).
>> Any ideas on how to deal with that?  I don't want to give up either
>> the blog postings or the twitter feed. Maybe we have to more severely
>> limit the excerpted content from the blog entries?
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: dev-h...@tapestry.apache.org
>
>



-- 
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

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



Re: Home page layout

2011-04-04 Thread Ulrich Stärk
I gues a style="clear:both;" somewhere will do the trick. although we then will 
have some blank
space below the main content.

On 04.04.2011 19:50, Howard Lewis Ship wrote:
> Now that we have a few postings in the blog, the Twitter window is
> laid out poorly (it extends beyond the footer and looks quite odd).
> Any ideas on how to deal with that?  I don't want to give up either
> the blog postings or the twitter feed. Maybe we have to more severely
> limit the excerpted content from the blog entries?
> 

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



Home page layout

2011-04-04 Thread Howard Lewis Ship
Now that we have a few postings in the blog, the Twitter window is
laid out poorly (it extends beyond the footer and looks quite odd).
Any ideas on how to deal with that?  I don't want to give up either
the blog postings or the twitter feed. Maybe we have to more severely
limit the excerpted content from the blog entries?

-- 
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

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



Index vs. invalid path

2011-04-04 Thread Howard Lewis Ship
Just had a thought (hopefully original) about dealing with the issue
of Index pages and bad paths.

This comes up with Tapestry often enough; an errant entry in a CSS
file, or a manually mangled URL, and an Index page is activated with
an invalid page activation context, resulting in an exception.

But it just occurred to me that in most cases, we will know what the
page activation context will look like (for example, a series of
digits is most likely) ... something that can be expressed as a
regular expression.

So how about something like:

@MatchExtraPath("\\d+")
public class Index
{
}

This would identify the page activation context (the extra path) as
needed to match the pattern \d+  (a series of at least one digit).

So, once the page is identified, the PageDispatcher (contributed to
the MasterDispatcher chain of command) can examine the page to see if
it has the @MatchExtraPath and, if so, continue searching if the extra
path does not match.

-- 
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

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



Re: GSoC - CSRF Protection

2011-04-04 Thread françois facon
2011/4/3 Markus Jung :

> What is not clear for me is that this solution works for all form and bean
> based components. This solution seems only to work for actionLink, right -
> or am I missing something?

The form component render hidden input for parameters added by
LinkCreationListener2.
(new name for LinkFactoryListener)


> I'm currently digging into the details of Tapestry and different protection
> mechanisms against CSRF.  As far the most reasonable solution for me is like
> Andreas Andreou suggested to provide a component mixin, that could be added
> to all components that are rendered as a HTML form, e.g. Form Components and
> Bean related components. In the template an additional element has to be
> explicetely added, that holds the secure token and is rendered as HTML
> hidden input field.

If I were you I would first try to implement the wiki solution with
LinkCreationListener2.

> This solution could maybe extended to provide a more general usage pattern,
> e.g. a site configuration parameter that enables CSRF protection for all
> form based components without further coding required, or a page scope
> enabling of this mechanism maybe useful.
>

Keep in mind the draw back effect on
- bookmarking / url  re-rewriting.
- entry point to user auth and user right management
- session replication and so one
etc...


> In a further step it might be useful to protect HTML anchor rendered
> components also.
>
> I will prepare a project proposal with a rough timeline. Who would like to
> mentor this project - is it Ulrich Stärk? I would like to double check the
> project proposal with the mentor before I submit it.

Would be nice to have a page about Tapestry better than
http://www.owasp.org/index.php/Java_Server_Faces


François

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