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

[Lincoln Baxter, III]

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 at mousetech.com>
To: lincolnbaxter at 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-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
Author of PrettyFaces URL Rewriting for JSF


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090907/b75b3bb3/attachment.html