I define a different module for each top-level route. I have startup stuff in my app module, then each #/foo route is defined in a module named app.foo (in a directory under app). I define substates for my top-level routes within the module that defines the top-level route. So app.foo.tab1 and app.foo.edit and app.foo.showall would all be in app.foo.
e On Fri, Sep 26, 2014 at 5:03 AM, mark goldin <[email protected]> wrote: > Are you saying that you are defining all states (substates) in the main > app? I would think that a loaded module should define its own ststates. > > > On Thursday, September 25, 2014, Eric Eslinger <[email protected]> > wrote: > > In the event of substates, I define substates. As an example, one >> application route has subtabs. Continuing the example above, I'd define >> app.tubers to be #/tubers, and define the 'body@app' view to contain >> tabset.html. >> >> Then I define tabset.html to contain two views, a skinny one to display >> tabs in, and a big one to display the tab content. I usually call that tabs >> and main. >> >> So, app.tubers.potatoes is #/tubers/potatoes, and has: >> header (from app) >> body (from app, but defined in app.tubers) >> tabs (from app.tubers, defined in the tabset template) >> main (from app.tubers, defined in the tabset template) >> footer (from app) >> >> Where [email protected] is set to the actual content we're displaying in >> the application. This would all probably be better if I wrote a plunk, I >> suppose. It ends up getting rather complicated, but underneath it all it >> falls apart nicely and you can look at each element of the layout as its >> own thing. >> >> The benefit to doing it this way (over storing current tab in a view >> variable and using ng-if) is that you end up preserving active tabs in the >> URL and I've found this to also be somewhat easier to refactor for mobile >> displays. >> >> Eric >> >> >> >> On Thu, Sep 25, 2014 at 6:15 PM, mark goldin <[email protected]> >> wrote: >> >>> Yes, I agree with footer and header. But with the body.... What id new >>> content that is loaded on a menu click needs to have its own states? Should >>> all these states be defined in the top level? >>> >>> On Thu, Sep 25, 2014 at 5:29 PM, Eric Eslinger <[email protected]> >>> wrote: >>> >>>> Personally, I use ui-router. I defined a top-level ui-view (called >>>> app), into which I placed a ui-view for header, footer, and body. Substates >>>> of app correspond to each "page" of the application, defining new content >>>> for the body view, and the menu bar and footer stay the same. >>>> >>>> On Thu, Sep 25, 2014 at 2:01 PM, mark goldin <[email protected]> >>>> wrote: >>>> >>>>> I am redesigning an application that has the following structure: >>>>> >>>>> Main screen with a drop dawn menu on a top. Each menu choice opens a >>>>> full screen page underneath the menu. Nothing special. How should I >>>>> architect my app based on Angular SPA concept? >>>>> Here is what I've got so far: I have an html page (like a main page of >>>>> one menu choice) but it has the menu in itself. Now I want to move the >>>>> menu >>>>> to an application main page. How I go about creating and managing states? >>>>> Right now the html page creates states and loads content. Should my >>>>> new application main page create states for menu choices pages or (looks >>>>> more comprehensible to me) each page will create its own set of states? >>>>> Any >>>>> docs about it? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "AngularJS" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/angular. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "AngularJS" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/angular/uHNV6Wi3KJM/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/angular. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "AngularJS" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/angular. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "AngularJS" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/angular/uHNV6Wi3KJM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
