Clever Geek Handbook

Sticky footer instead of shell.html look

I have a knockout and durandal application whose footer will not be inserted.
I believe this is because the footer is not listed in shell.html

shell.htm
<div id="wrap" class="col-md-10 col-md-offset-1 col-xs-12">

  <nav class="navbar navbar-inverse navbar-static top" role="navigation"></nav>

  <div class="page-host" data-bind="router: { transition: 'entrance', cacheViews: true }">

</div>

but specified in a view that contains other views.

wizard.html

<div class="container-fluid">
    <div data-bind="compose:{model:currentWizardView,activationData:$root,transition: 'entrance'}"></div>
</div>    
<div id="push"></div>
<div id="footer">
<div class="footer-bar">
    <button id="previous" class="btn btn-lg btn-next" data-bind="click:previous,enable:canMovePrevious">< Previous</button>
    <button id="next" class="btn btn-lg btn-next" data-bind="click:next,visible:canMoveNext">Next ></button>

</div>

The wizard.html file is created in the shell.html file.

So basically ...

Shell.html wraps

  • Navbar
  • Creates master

Wizard.html wraps

  • creates a wizard look
  • footnote

I've searched the web for days and tried a few sticky css footers (i.e. navbar-fixed-bottom, position: fixed, vh is viewport height) doesn't give me the look I want.

I need a footer at the bottom of the page regardless of the height of the folded view.

Any ideas?

html ... with the fluff removed.

<div id="applicationHost" class="container-fluid">
    <div id="wrap" class="col-md-10 col-md-offset-1 col-xs-12" data-view="views/shell" data-active-view="true" style="">

        <nav class="navbar navbar-inverse navbar-static top" role="navigation">
        </nav>
        <div class="page-host" data-bind="router: { transition: 'entrance', cacheViews: true }">
            <div class="container-fluid" data-view="views/wizard" data-active-view="true" style="">
                <div data-bind="compose:{model:currentWizardView,activationData:$root,transition: 'entrance'}">
                    <div class="durandal-wrapper" data-view="views/texture" data-active-view="true" style="">
                        <div data-bind="compose:'templates/_value.html'">
                            <div class="durandal-wrapper" data-view="views/templates/_value" data-active-view="true">
                                <ul class="list-group" data-bind="foreach: values">
                                    <li class="list-group-item active" data-bind="click:$parent.setValue.bind($parent,$index()),css:{active: $parent.value() == $index()}">
                                        <label data-bind="text: $data"></label>
                                    </li>
                                </ul>
                            </div>
                        </div><div class="clearfix"></div>
                    </div>
                </div>
                <div id="push"></div>
                <div id="footer">
                    <div class="footer-bar">
                        <button id="previous" class="btn btn-lg btn-next" data-bind="click:previous,enable:canMovePrevious">&lt; Previous</button>
                        <button id="next" class="btn btn-lg btn-next" data-bind="click:next,visible:canMoveNext">Next &gt;</button>
                    </div>
                </div>
            </div>
            <div class="durandal-wrapper" data-view="views/serviceTypes" style="display: none;">
                <div class="row">
                </div>
            </div>
        </div>
    </div>
</div>
+3


source to share


1 answer


It is not so much a question of where in the lifecycle as the structure of the page.

Durandal is completely orthogonal in the way it stacks up: a shell is a view / view pair, just like everything else. The router manipulates the wrapper, creates views in it, and controls their visibility. Probably the best way to see this is to get a working Durandal app and hit F12 in your browser and then see what happens to the DOM as user actions cause the views to load.

Each type of shell contains some options:

<div class="container page-host" data-bind="router: { cacheViews:true }"></div>


Note the knockout binding to the router. This is what marshals see in the DOM. As a result, everything in any of your views is an indirect child of that div, and this is what makes your attempts at positioning the footer bothersome.

You can solve the layout problem by re-naming the footer, but that gives you a new problem: the visibility of the footer is no longer dependent on the view to which it logically belongs.

To get the sticky browsing footer back under automatic router control, you will need to manage your origins. You can do this through code in your viewmodel, activate and deactivate events, but a more elegant solution would be to bind its parentElement to a property on your viewmodel.

I suppose the sticky footer should be an immediate child $(document.body)

0


source






More articles:


All Articles