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

TH> "One of the more subtle things about VEE is that you can also

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