1 2 Previous Next 15 Replies Latest reply on Apr 22, 2012 1:33 AM by bleathem

Slidfast improvements

bleathem Jan 10, 2012 1:24 AM

I recently started working through the Mobile RichFaces GSG, and I have some suggestions on how the usability can be improved.

The main problem as I see it, is the two-page model: "home" and "component-page". The way the approach in the GSG is structured, the application toggles between the "home" page and the "component-page", (both of which are div's in the DOM approach). Imagine a simple application with the following workflow:

1) A page listing the available actions (fits well with the "home" page)

click on a menu item to bring you to

2) A item listing page (ok, let's put this onto the "component-page"

click on an item to get to an item details page

3) where does this bring me? I can change the dynamic include on the "component-page", but how do I get slidfast to animate the transition?

As I understand it, this is way too strongly tied to the RichFaces showcase model, and will not be extensible to other applications.

However, I think the solution isn't too difficult. Let's allow for an unlimited number of page div's, and use the location hash to identify which div we want to make active. Navigation then consists of manipulating the locationHash, and slidfast should then be able to take care of the transitions.

What would it take to make this change? Is it merely a change to the GSG? I'm pretty sure slidfast could handle this as it is.

Additionally, I'd like to see us make a new component to help abstrract some of this javascript (<rich:slidfast> anyone? ). This would be gravy on top of the above fix, but something worth considering while we are at it.

1. Re: Slidfast improvements

wesleyhales Jan 10, 2012 7:54 PM (in response to bleathem)

My latest commit should satisfy your mobile wants and needs :
https://github.com/richfaces/components/commit/aa083bef542a5afb8fa16b0406132266106df2f9

Still need to update the GSG...
Actions
2. Re: Slidfast improvements

nathandennis Mar 27, 2012 8:07 AM (in response to wesleyhales)

ETA on the GSG update that includes this new funcationality?
Actions
3. Re: Slidfast improvements

bleathem Mar 27, 2012 11:30 AM (in response to nathandennis)

The GSG needs to be expanded to cover additional use-cases. But in the mean time you can check out the RichFaces "Kitchensink" archetype, which demos a mobile CRUD application.

http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22richfaces-archetype-kitchensink%22
Actions
4. Re: Slidfast improvements

nathandennis Mar 27, 2012 2:58 PM (in response to bleathem)

that was pretty much exactly what i was looking for. though there are some significant difference between the richfaces mobile showcase and that one. working examples are worth 1000 words. im perfectly ok with forgetting about the GSG and just expainding with more diverse examples. it would seem that im jumping on this project at the perfect time since this thread isnt even 3 months old.
Actions
5. Re: Slidfast improvements

bleathem Mar 27, 2012 3:03 PM (in response to nathandennis)

I'm glas to hear the example helps! It is quite different from the showcase, but that's because it supports quite a different use case. The GSG is also biased towards the showcase use case, which is why I feel it needs updating.

The next richfaces/slidfast related improvements I have in mind are to replace the static page divs with a single ui:include, so that the page content is loaded dynamically. Right now, all page divs are loaded upfront, which will not scale well with a bigger application.

If you have any questions, or suggestions for improvements, feel free to shout them out. Pull requests would be even better
Actions
6. Re: Slidfast improvements

nathandennis Mar 27, 2012 3:15 PM (in response to bleathem)

i was actually working on loading the page content dynamically earlier today. for some reason i was getting a bunch of squirely undocumented behaviors going on. pressure from the top made me start looking for a quicker way,, thats when i found this post. just to many unknowns floating around for me to be dangerous yet. i just moved to from javaee5/seam to javaee6/cdi this last month. it will take me a bit to get my brains wrapped around it all.
Actions
7. Re: Slidfast improvements

wesleyhales Mar 27, 2012 9:01 PM (in response to nathandennis)

A pretty decent version of dynamically loaded pages is here:
https://github.com/wesleyhales/slidfast/tree/master/demo/src/main/webapp/html5arch

I'm working on slidfast for my book, so these updates are kind of hidden. However, Brian and i have made plans to make this an indie public project. Just run the index.html to see it in action.
This was taken from my original article here: http://www.html5rocks.com/en/mobile/optimization-and-performance/#toc-fetching-caching
Actions
8. Re: Slidfast improvements

bleathem Mar 28, 2012 3:21 PM (in response to nathandennis)

The project from which we generate the archetype is now available as a top-level repository here:
https://github.com/richfaces/as-quickstarts/tree/master/kitchensink-rf

We'll be updating it over the coming weeks, feel free to follow along. Or, if you want to get involved, drop in to #richfaces on IRC, and you can help us decide in which direction we should steer this example.

Brian
Actions
9. Re: Slidfast improvements

nathandennis Mar 29, 2012 4:01 PM (in response to bleathem)

absolutely,, im temporarily slowed on the project until the management work on the functionality spec some more.. but this definitely looks like the direction im going to go. not such a bad thing though. it will give this a few more weeks to develop. i didnt realize these efforts were as recent as they apparently are.

if we can sort of get on the same page with the direction, i would be happy to contribute what i can to the effort. im working for a large non profit. there arent but two of us programmers here and im the only java guy (and new here as well). we are in the middle of a conversion too.. so time is a little tight but should get more plentiful in the foreseeable future.
Actions
10. Re: Slidfast improvements

bleathem Mar 31, 2012 12:01 PM (in response to nathandennis)

That's great to hear Nathan. chekout the project at the above github URL, I just pushed some changes that switch it to using a dynamic page render scheme (similar to how the showcase does it).

The app still needs two page-id's, differentiating between the "home-page" and the "app-page". My next plan is to make the necessary modifications to slidfast.js, so that we can have a single page-id. I'd also like to see the direction of the slide be passed as a parameter to the slidfast "slideTo" methond.

@Wes - are these changes consistent with the direction you've been taking slidfast for your book?
Actions
11. Re: Slidfast improvements

bleathem Mar 31, 2012 12:55 PM (in response to bleathem)

Also, I'd like to see SlidFast switch to using html5 push state rather than manipulating the location hash:
http://badassjs.com/post/840846392/location-hash-is-dead-long-live-html5-pushstate
Actions
12. Re: Slidfast improvements

nathandennis Apr 3, 2012 10:01 AM (in response to bleathem)

im planning on taking a close look at your additions today.
Actions
13. Re: Slidfast improvements

nathandennis Apr 3, 2012 10:23 AM (in response to bleathem)

how much additional overhead do you think we will have to carry around to support both pushstate and the older hash method? i was looking at the compatibility list and though i would love to see certain trident based products to disappear from the market share.. it isnt up to me.
Actions
14. Re: Slidfast improvements

bleathem Apr 22, 2012 1:28 AM (in response to nathandennis)

@nathan dennis: regarding push state with hash fallback, I was hoping to leferage something like jQuery BBQ to abstract away the push-state and hash handling / graceful degradation.
Actions

1 2 Previous Next

Go to original post