3:11 p.m.
TH> "One of the more subtle things about VEE is that you can also get them on
an AJAX request. I don't think anyone's addressed that yet."
Has this been addressed yet?
--Lincoln
-------- Forwarded Message --------
From: Tim Holloway <timh(a)mousetech.com>
To: lincolnbaxter(a)gmail.com
Subject: Re: [jsr-314-open] Browser Dependencies
Date: Mon, 07 Sep 2009 15:03:16 -0400
Hi Lincoln,
Sorry to take so long. I've been wrangling pixels in CSS. As much work
as coding, and a lot less fun. I didn't realize that my JSF forms were
silently adding 16 pixels to the bottom of their (non-)display area.
Favors like that I could have done without.
When I saw Ed Burns capture the error page on ViewExpiredException, I
thought, "Why didn't I think of that?" Turns out I did, but without the
JSF2 parts. Unfortunately, I think that some of the wierdness in my
filter may be because I'm trying to use both the container and the
filter to trap that exception.
Pity I can't try the JSF2 approach just yet, but first they need to get
it info production!
One of the more subtle things about VEE is that you can also get them on
an AJAX request. I don't think anyone's addressed that yet.
Speaking of JSF2, have you seen this?
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
It's a nice rundown. I'm not sure if their ideas on
bookmarkable/parameterized URLs are as tidy or as complete as
PrettyFaces, though.
Best Regards,
Tim
On Thu, 2009-09-03 at 23:08 -0400, Lincoln Baxter, III wrote:
FYI - new blog entry by ed burns:
http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefull...
On Sun, 2009-08-30 at 13:25 -0400, Tim Holloway wrote:
> On Sun, 2009-08-30 at 11:33 -0400, Lincoln Baxter, III wrote:
> > Hmm, I do see value in that, but let me dump some thoughts and see
> > what you think:
> >
> > I suppose it depends on the scope of the bean in which you are storing
> > the query-param. If the bean is session scoped, then it will remain
> > valued until the session expires (or it is unset manually.) If it is
> > request scoped, it will need to be supplied each request. PrettyFaces
> > could, I suppose, overwrite the value in the session or application
> > scope with a default value, but that might create issues itself.
> >
> Yup. Request Scope at least starts out with a known value. The problems
> are with session and application scope. But I'd forgotten (for about the
> 3d time!) that PrettyFaces has to match on all items - and in the order
> illustrated - anyway. So the whole idea is probably moot.
>
> BTW, I don't think you ever formally indicated in the docs whether
> PrettyFaces does first-fit or best-fit on URL patterns. One of the URLs
> on my demo site has a "noise" component, and so I wanted to be able to
> match with or without the extra chunder, but I couldn't find a way to do
> that, so I had to make the core URLs distinct.
>
> I do admit to a bad habit of trying to treat Pretty URLs as cavalierly
> as I would raw URLs. Which really isn't nice of me. :)
>
> > Values can be set to defaults using initializers in the class file, or
> > via an action method.
> > Request values (query params) can be pulled out of the
> > externalContext.getRequestMap() to see if anything was set (if you
> > need to know). Pattern parameters wouldn't really work because
> > something has to be at that part of the URL.
> >
> > I'm not sure the malicious attack issue would be solved by default
> > values -- URL input is just as sensitive as form input, and is subject
> > to the same risks and requirements for validation. Unfortunately,
> > validation is manual with PrettyFaces because it would be very complex
> > to put in. But I use action methods to do my validation at the
> > RESTORE_VIEW default action method phase:
> >
> I had doubts myself. Just figured that any time there was a possibility
> for unexpected input, someone would find some way to do something nasty.
>
> >
> > if (!ALL.equals(featureFilter) &&
> > storyFeatureOptions.contains(featureFilter))
> > {
> > for (Iterator<Story> iterator = result.iterator();
> > iterator.hasNext();)
> > {
> > Story story = iterator.next();
> > if (!
> > story.getFeature().getName().equals(featureFilter))
> > {
> > iterator.remove();
> > }
> > }
> > }
> >
> > Thoughts? Did I understand your point?
> > --Lincoln
> >
> > On Sat, 2009-08-29 at 19:42 -0400, Tim Holloway wrote:
> > > the value of "pagesize" will be indetermite when the action
fires
> > > and
> > > there's no obvious way to detect the missing parameter(s) short of
> > > manually picking apart the action URL (which kind of defeats the
> > > purpose
> > > of PrettyFaces). So being able to set a default pagesize seems like
> > > a
> > > useful thing to be able to do.
>
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
4:03 p.m.
On 9/7/09 4:11 PM, Lincoln Baxter, III wrote:
TH> "One of the more subtle things about VEE is that you can
also
get them on
an AJAX request. I don't think anyone's addressed that
yet."
Has this been addressed yet?
--Lincoln
It depends on what you mean by "addressed".
If you get a VEE, or any other exception, on the server side, it will be
propagated back to the client, where you can act appropriately. And
appropriately for VEE probably just means a redirect to a central page.
Of course, if you're using Ajax, there's little excuse for getting a VEE
anyway - you should be running a polling process on the client to keep
the session alive on the server. The only time you'll get a VEE then is
for the case of navigating away from a page and coming back much later,
while using POST. Or deliberately, after someone's left a page on for
what you consider to be too long. In either case, redirecting to a
central page while dumping state wouldn't be considered too grim a
solution - after all, the user had already gone away for a significant
amount of time, including leaving the page...
But there are many other values for "addressed", where we haven't
actually done anything - for instance, I'd really like VEE handling to
be *much* more automatic (on client *and* server) - maybe we'll have
time for that in 2.1.
Jim
-------- Forwarded Message --------
*From*: Tim Holloway <timh(a)mousetech.com
<mailto:Tim%20Holloway%20%3ctimh@mousetech.com%3e>>
*To*: lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>
*Subject*: Re: Browser Dependencies
*Date*: Mon, 07 Sep 2009 15:03:16 -0400
Hi Lincoln,
Sorry to take so long. I've been wrangling pixels in CSS. As much work
as coding, and a lot less fun. I didn't realize that my JSF forms were
silently adding 16 pixels to the bottom of their (non-)display area.
Favors like that I could have done without.
When I saw Ed Burns capture the error page on ViewExpiredException, I
thought,"Why didn't I think of that?" Turns out I did, but without the
JSF2 parts. Unfortunately, I think that some of the wierdness in my
filter may be because I'm trying to use both the container and the
filter to trap that exception.
Pity I can't try the JSF2 approach just yet, but first they need to get
it info production!
One of the more subtle things about VEE is that you can also get them on
an AJAX request. I don't think anyone's addressed that yet.
Speaking of JSF2, have you seen this?
http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
It's a nice rundown. I'm not sure if their ideas on
bookmarkable/parameterized URLs are as tidy or as complete as
PrettyFaces, though.
Best Regards,
Tim
On Thu, 2009-09-03 at 23:08 -0400, Lincoln Baxter, III wrote:
> FYI - new blog entry by ed burns:
>
>
http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefull...
>
>
> On Sun, 2009-08-30 at 13:25 -0400, Tim Holloway wrote:
> > On Sun, 2009-08-30 at 11:33 -0400, Lincoln Baxter, III wrote:
> > > Hmm, I do see value in that, but let me dump some thoughts and see
> > > what you think:
> > >
> > > I suppose it depends on the scope of the bean in which you are storing
> > > the query-param. If the bean is session scoped, then it will remain
> > > valued until the session expires (or it is unset manually.) If it is
> > > request scoped, it will need to be supplied each request. PrettyFaces
> > > could, I suppose, overwrite the value in the session or application
> > > scope with a default value, but that might create issues itself.
> > >
> > Yup. Request Scope at least starts out with a known value. The problems
> > are with session and application scope. But I'd forgotten (for about the
> > 3d time!) that PrettyFaces has to match on all items - and in the order
> > illustrated - anyway. So the whole idea is probably moot.
> >
> > BTW, I don't think you ever formally indicated in the docs whether
> > PrettyFaces does first-fit or best-fit on URL patterns. One of the URLs
> > on my demo site has a"noise" component, and so I wanted to be able
to
> > match with or without the extra chunder, but I couldn't find a way to do
> > that, so I had to make the core URLs distinct.
> >
> > I do admit to a bad habit of trying to treat Pretty URLs as cavalierly
> > as I would raw URLs. Which really isn't nice of me. :)
> >
> > > Values can be set to defaults using initializers in the class file, or
> > > via an action method.
> > > Request values (query params) can be pulled out of the
> > > externalContext.getRequestMap() to see if anything was set (if you
> > > need to know). Pattern parameters wouldn't really work because
> > > something has to be at that part of the URL.
> > >
> > > I'm not sure the malicious attack issue would be solved by default
> > > values -- URL input is just as sensitive as form input, and is subject
> > > to the same risks and requirements for validation. Unfortunately,
> > > validation is manual with PrettyFaces because it would be very complex
> > > to put in. But I use action methods to do my validation at the
> > > RESTORE_VIEW default action method phase:
> > >
> > I had doubts myself. Just figured that any time there was a possibility
> > for unexpected input, someone would find some way to do something nasty.
> >
> > >
> > > if (!ALL.equals(featureFilter)&&
> > > storyFeatureOptions.contains(featureFilter))
> > > {
> > > for (Iterator<Story> iterator = result.iterator();
> > > iterator.hasNext();)
> > > {
> > > Story story = iterator.next();
> > > if (!
> > > story.getFeature().getName().equals(featureFilter))
> > > {
> > > iterator.remove();
> > > }
> > > }
> > > }
> > >
> > > Thoughts? Did I understand your point?
> > > --Lincoln
> > >
> > > On Sat, 2009-08-29 at 19:42 -0400, Tim Holloway wrote:
> > > > the value of"pagesize" will be indetermite when the
action fires
> > > > and
> > > > there's no obvious way to detect the missing parameter(s)
short of
> > > > manually picking apart the action URL (which kind of defeats the
> > > > purpose
> > > > of PrettyFaces). So being able to set a default pagesize seems
like
> > > > a
> > > > useful thing to be able to do.
> >
--
*Lincoln Baxter, III*
Co-Founder of OcpSoft <http://ocpsoft.com>
Author of PrettyFaces <http://ocpsoft.com/prettyfaces> URL Rewriting for JSF
5365
days inactive
5365
days old
jsr-314-open-mirror@lists.jboss.org
1 comments
2 participants
participants (2)
-
Jim Driscoll -
Lincoln Baxter, III