Zend framework Nesting controllers
I was wonder if it is possible to have nested controllers.
I have an application that has a page with left bar and right bar.
| --TAB----TAB----TAB--
MyGroups |
|
So I want to have one controller to be as a wrapper for entire page
then have myGroups controller for left bar, and for right side, there are many tabs that would show based on some selections.
So I want to have one controller for each tab.
This is a very big application and each of those tabs do lots of other things.
So I want have separate controller/model/view/layout for each tab and also for left side's myGroups.
What is the best way to approach this.
I appreciate if you give me some code structure too.
Thank you very much.
Alex
You could use the the Action view-helper in your layout for each or your left and right bars. But the downside to this is that you incur three full server calls (complete with bootstrap and dispatch cycle) to render a single page. I consider that to be a pretty significant downside, especially if each bar needs its own database connection.
An alternative approach is to use front-controller plugins for your left and right bars. Register them at bootstrap, give them a postDispatch() hook which accesses/generates whatever data they need and places that data into the layout/view. Then your layout renders the content without needing to know how it got there.
If you use the 'action view-helper' suggested by David, you could always ajax these in for better UX - therefore the user can read what has currently been loaded, while waiting for the rest of the page.
Related
I have a joomla site and would like to integrate some old unfinished webcomics to it, so I can pick them up where I stopped in a CMS that won't leave me in an absolute frothing rage (thanks, wordpress).
I've got some experience with Joomla and I believe it would be a pretty good platform for managing multiple comics... except for the small issue of horrid navigation between pages/articles. Joomla's integrated article navigation is a humble but passable start, but if you intend to use categories to organize chapters then getting from the end of one to the beginning of the next is... yeah. This is a pity, as Joomla's category and article management options are beautiful for archiving and presentation, and adding gantry 5 to it means a great deal of control over the reading experience. Basically, joomla has pretty much everything I want, except for the navigation.
Ideally, what I'd like to be able to accomplish for comic navigation in joomla is:
Clickable full-article-image leading to next article/page
Prev/next article buttons (already available)
Prev/next category buttons (do we have those?)
The latter two in a module I can choose where to publish (optional)
And this is it, basically. I understand that implementing the first could be very hard without some major template customization, in which case I'd be willing to insert the image as a link in the article body... but only if there was one single code I could use, like the one that generates the next category article button. Because I'm not willing to create hundreds of menu items to generate links page-by-page.
So is any of this doable?
This is a quick answer but too much for a comment. I'm assuming since you are on SO that you don't mind coding (as opposed to just configuring).
I think you need to do two things. First you need to create a pagination.php for your template. This will let you really super control what the pagination looks like. You can have images, special css and js, whatever you want. You can also add the "last" and "first" options.
I think you need to make a new plugin to replace the core pagenavigation plugin and that also generates the previous/next category links. (Or I guess you could make one just to do categorynavigation depending on what you want.) HOWEVER, it seems to me that there is data on the sibling links that is already being generated in the content category model so you might be able to use that. (Check the code; I think there was never a UI for it, but it is there. Even if it isn't there, siblings are very easy to obtain in nested sets)
The other thing you can really think about if you go that route is changing the whole thing somewhat to use a module that gets the current ID and category ID from JInput. You might also be able to use JPagination. The important thing, however is that you make sure to do the caching the way the pagination that is there does it. In other words you really want to cache the whole list in the order you want so you are not running so many queries and slowing your site down. You may want to look at the categories and category modules to get some ideas about the queries to do.
Hope that gets you started, but it is definitely something you can do without too much trouble.
Today when I searched on the internet I saw the View first approach in web development of Lift framework. Can somebody tell me the differences between view first and MVC approach ?
Thank you very much
View first is based not on a model and a controller, but mostly interested in the view. Many problem domains do not neatly compose in controllers and models. Think about a ecommerce site, the shopping cart exists on all pages, but should every controller control it? Personally in MVC too much of my time is spent thinking about how to logically make the problem fit into MVC than just coding. View first takes away this controller / view / model and instead just has a view which in Lift can call "snippets". It is almost a superset of MVC since if you wanted you could only have a single snippet per page, but Lift allows you to do much more. Snippets can be cross cutting concerns or very page specfic logic.
From the lift website..
Lift is different [from MVC]. For HTML requests, Lift loads the view first and builds your page from the view. Lift also supports REST style requests for non-HTML data. (See 11 on page 1↑) “Why?” Because complex HTML pages rarely contain a dominant piece of logic... a single controller... but contain many different components. Some of those components interact and some do not. In Lift, you define the collection of components to be rendered in the resulting HTML page in the view.
When your using lift, you basically have a view(page) and from this you could incorporate any snippet(app) that you have without much of the antics you'd normally have to do in an MVC framework/environment.
Basically you don't have to choose what the most important thing on the page is just what you want to add to a page and then add it.
Currently, in our deployment we have a abstract type Component which represents a part of our Page, basically an element such as a Question, which can have multiple choice, a text box or any other form of answering it, or a Video that users can play, basically a shard of a page that is interchangeable, basically, our design was to have a specific area in our website which would be rendered through a list of Components, we tried at first to have each "Page" object have a List of Components, and each Component would have a method render that would return a Spring View, we thought we could iterate over the list and somehow mash the views together.
We also tried using XSTLViews with no more success, it seems to be more of a design problem and our abuse of the way Spring MVC should be used.
We will really be glad to receive any advice/tips/corrections about how to do it right and maybe some corrections about misconceptions we might have.
It sounds like you're more than half way to a design that uses AJAX to build your page. You're trying to mash up a bunch of Components into one request. What if you returned a container page which then requested/inserted a block of html for each URL it was given a render time. Each of these URLs would refer to a single component. It might be a performance hit if you are including a lot of these Components, but it seems to fit the design.
we have a small questionaire application,
and 1 of the main sections is the questionaire itself.
it has a big view for some general templating, introduction and title etc
and it has subviews per question (with next and previous buttons)
we decided to use routing, because from several places one can jump to a specific question
so we use /ivr/4 to show question 4, and /ivr/overview showing the final overview.
so in a way you go from /ivr/1 to /ivr/2 ... to /ivr/overview
now, if one comes from /ivr/1 and arrives on /ivr/2
the big view is there, and it should only update the question to the right question
but when you arrive from /home to /ivr/2
the big view is not loaded, so one should first open the questionaire and then load question 2
currently i have it always rerendering the big view
which works, but is lots of overhead and i would like to refactor this to a better way.
can anyone give me some guidance as to how i would structure routeActions and or views
to only update the big parentview when it actually needs to, and do the question view only, if the parent view is already there.
do i need events?
or would i go with partial routes?
any tip is welcome.
I think both of your proposed solutions sound workable. If you go with events, I'd recommend using the event aggregator pattern to facilitate communication between your views. This seems like the simpler option to me.
The other solution, partial routes, might be more involved. Check out the Backbone.Marionette plugin, which was designed to help manage complex view manipulation.
I want to know that can i change the navigation menu dynamically,i am having two tabs on the basis of which i want to render the navigation menu.How can it be done
Thanks in advance
For usability reasons, the global navigation generally shouldn't change. Users will expect to see the same options available to them and will get confused (and leave) if they aren't.
Could you explain the requirement more?
EDIT:
Usability issues aside, try adding all necessary items to the top nav, then use Javascript to toggle between tabs. If you don't want to change the navigation PHTML files to add IDs to them, you can use the existing classes to target which nav items to show and which to hide.
Since Magento stores cannot function without JS anyway, you should be pretty safe with that solution. Preferably, you can change the top nav's template (I believe app/design/frontend/base/default/template/page/template/links.phtml in 1.4) to use IDs for those LIs as well, in which case you can target those instead.
Thanks,
Joe