[jsr-314-open] [Fwd: Re: Browser Dependencies]

[Jim Driscoll]

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 at mousetech.com
> <mailto:Tim%20Holloway%20%3ctimh at mousetech.com%3e>>
> *To*: lincolnbaxter at gmail.com <mailto:lincolnbaxter at 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-gracefully-viewexpiredexception-jsf2
>>
>>
>>  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
>
>