Touchfaces navBarControl question

[sage.sam]

I got the sample apps for touchfaces up and running and have been playing with it a bit.

So far it appears that each page is intended to be an application in itself. What I'd like to try is creating a deeper drill-down with views on each page, so that I don't have to keep every view in the same .xhtml file.

I figured out very easily that I can link via the i:rowItem tag to another .jsf page. This piece of navigation is very clean and easy.
My problem comes in that I would like to put a "back" or "home" button in the top left of the screen.

Fortunately, the addition of a leftNavBar facet was highly intuitive. That much works great on the single-page layout. When I try to split into multiple pages, this seems to break down.

I have index.jsf which links to page1.jsf. On page1.jsf, I added the facet and nav control:

<f:facet name="leftNavBar">
<i:navBarControl label="Home" view="./index.jsf"/>
</f:facet>

Which logically errors out because I don't have a view defined on my page called "index.jsf".

I also tried using a standard buttonLink, which errors out because buttonLink cannot be cast as a navBarControl.

Is there a simple way to create this link that I'm overlooking?

[cagatay.civici]

Well, initially touchfaces is designed with the fashion that every view should be enclosed in the application tag. Application tag tracks the navigation history and utilizes back navigation. So it's not meant to add each jsf page in it's own .xhtml. Practice is to add all views in one .xhtml enclosed in application tag.

What we do usually is to use ui:include so we can create seperate .xhtmls for each view and include them with ui:include. This way you can seperate views and still make navigation work.

[sage.sam]

OK, that makes sense. I'll give that a shot!

[sage.sam]

I was able to get the ui:include approach to work. This seems to be workable.

The problem that I see with this approach is that in doing includes, you are (obviously) including all the material together into a single page. This means that no matter how large or complex your application gets, it will all have to load on the main page.
Also, I have not yet tried loading dynamic data into the page. It seems like this may be a problem given that everything is loaded up front!

Do you have any advice or ideas on how to mitigate the performance issues and data loading?

[cagatay.civici]

If you check out the news application, you can see that views are loaded dynamically with ajax, so on initial page load footprint will be low since view contents are loaded with ajax on demand only not on load fully. Still there's room for improvement to make views easier to load with ajax.

[sage.sam]

If you check out the news application, you can see that views are loaded dynamically with ajax, so on initial page load footprint will be low since view contents are loaded with ajax on demand only not on load fully. Still there's room for improvement to make views easier to load with ajax.

OK, I can see that the news application loads very dynamically. That's excellent!

I guess my question stems more from the fact that in my sample application, each view has a fair amount of static content. This static content is loaded into the resulting source, resulting in a fairly large initial load -- though not prohibitively so.

I guess I could write some backing code and load more dynamically that way... does that make sense? To see it in action, yhou can check out http://magic.coruscant.cc/DCIMIPG/

[cagatay.civici]

Yes, I'd suggest loading it lazily. Also try to compate the page size with a regular page to see if it's really worth doing that. With 3g it should not be an issue.

[sage.sam]

Yes, I'd suggest loading it lazily. Also try to compate the page size with a regular page to see if it's really worth doing that. With 3g it should not be an issue.

Right now, it's not worth doing (except perhaps as an exercise); the resulting page size is still less than 200k and with the whole page loaded performance is quite snappy!

I simply wanted to make sure I understood the intent/best practices here with touchfaces and how it compares with other similar frameworks/libraries. Fairly similar, really.

[cagatay.civici]

Also note that touchfaces is still beta and will be improved based on user experience.