I have a software design question. I am looking for Smarty plugins-like functionality in a Spring MVC app. Let me try to explain the case.
I am using Spring MVC to build a webapp and I want the system to be able to display application wide 'system messages' like
<div class="sysmessage'>Your user profile is incomplete, please fix it</div>
or
<div class="sysmessage'>System down for maintenance next friday between 13:00 and 14:00</div>
I already have a service method that returns system messages when the user needs to be informed of something. The normal approach to this (I think) would be to call the service method from each and every Controller method and add any system message to the model, display it in the main grid JSP and voila... application wide system messages.
But this approach seems so labour intensive. I would need to add the call to the service method to every controller method, add it to the model every time, etc..
My question: is there some kind of 'reversed' setup possible in Spring that resembles the Smarty plugin functionality? A smarty plugin is a piece of HTML/template code that is backed by PHP code. I need the same in my app. It would be much faster and cleaner if I could place a piece of JSP code that is backed by Java code in my template. I know a custom JSP tag basically does this, but I was wondering if there is something packed with Spring that can achieve the same. It seems like such a common scenario. I looked at Spring Protlet MVC, but I am not entirely sure if that fits my needs.
Several options:
Spring interceptor
Tiles view preparer
ServletAPI filter
In all cases, you will need to add some code to your jsp's to output the message in your page.
This would be best done in a tiles layout which is used by all the pages that should display the message.
Related
in my symfony application i use many controllers . They render their templates who all extend ::base.html.twig template. I feed these templates with an array of datas for display the dynamic content , thanks to my controllers. But the ::base.html.template need also to receive his array of datas for display 4 pictures in a kind of slider . These datas (url of pictures) come from datas base and are available for all pages in my website so i'am asking myself how to send just one time this array of picture? For moment in every controllers I have to repeat the same code for get the url of pictures from database .
Sorry if my question is not clear
I'd personally move the code that creates these sliders out of the controllers into a service layer, be it a proper service or simply a class you create and use dependency injection you need to access things like the EntityManager within it. Services are fine, but they have an associated overhead.
By moving the code out of the controllers, you have a method you can call from all the controllers and one copy of the code, instead of multiple copies through your controllers.
Rendering controllers within twig is certainly possible, but it seems a bit of a fix for bad design (in my opinion anyway). It's a quick win, but not exactly an efficient one.
Remember, controllers should be thin, not bloated fat with code.
I think the correct way would be to create a Twig extension that will get this data for you.
Every tutorial/example i can find for meteor shows a single view application. I would like to build something a little more complex. I'm unclear how to approach multiple views...preferably in a way that's somewhat scalable?
The iron-router package lets you access different views (layouts) by nice, REST-ful human-friendly clean URLs. It supports parameters in the URL, "loading" templates, waiting for subscriptions to finish loading, before and after hooks etc.
At this point you can only create Single Page applications with Meteor. Note that Single Page, doesn't mean you can't have several views - use iron-router for that.
But by design, Meteor serves a big fat unique JavaScript/HTML/CSS application down to the browser, though there's a feature request to allow incremental loading. It is then up to the application (or more precisely, the JavaScript framework), to dynamically render its views in order to display different "pages".
I was wondering the same thing and it took me way too much time getting something started. I finally got a paged app working solidly by using Backbone views and routes, so I created a simple boilerplate project to make setting up an app like this easier in the future.
Live demo here: backbone-boilerplate.meteor.com
Source code here: github.com/justinmc/meteor-backbone-boilerplate
Have you looked at madewith.meteor.com?
A bunch of apps there have multiple views using Backbone also Jonathan Kingston who created britto has started simple meteor framework called Stellar
At this stage of the game not sure if there really are best practices. But these two seem to be the current flow.
You can also make a tabbed interface for multiple views. There is a package project "Smart package for generating a tabbed interface with pushState" github project here: https://github.com/possibilities/meteor-tabs
The best solution right now is using a routing package (router is basic but works). The workflow is something like this:
declare routes; return a template name for each route
place the reactive helper provided by the package in your body tag
the reactive helper will return the template associated to that route
you create a template for each route and optionally set custom publish functions
Router will give you browser history (client side).
Note that at this time there are some limitation on the way Meteor handles html/js. They are load all at the same time. The bright side is that once the app is loaded, page transitions will be instant.
I am planning to create generic commenting module, that will work for any object in my application just by passing object_type, object_id.
Comment module will give list of comments along with form to enter new comment, I want to include this module in other jsp, like product jsp and others, so this should request the comment module before the o/p renders.
I know this is possible with PHP Zend framework, for those who dont understand my question properly refer 'Zend Action View Helper'
http://framework.zend.com/manual/en/zend.view.helpers.html#zend.view.helpers.initial.action
I got the solution we need to use <c:import url="/user/11"> this will do what I am expecting
Spring frame work supports a number of view technologies. If your using velocity for view you can use velocity macros as view helper. And JSP and other 'view technologies' also have smae kind of technologies.
I am working on a .net mvc web application that has a bunch of web parts on the homepage. I realize that a webpart is a .net forms terminology, but wasn't sure what to name those mini sections. So anyways, for now these sections are called when that page is rendered, but eventually I will plug in JQuery and call these sections using AJAX. These mini sections or widgets will need to keep state as the user navigates between the homepage and back. With .net forms, the page state info is kept in the viewstate, but with .net mvc, that is not available (thankfully).
So, is there a framework already created for such functionality for MVC? If not, what would be the best way to handle this situation? I was thinking to leverage the HttpContext object and store everything in there, but not sure if that object has any size limitations.
Just like with anything else in MVC you're going to need to store the state somewhere. As other users have pointed out, using Partial Views will reduce the complication of the design by allowing you to have controllers that handle just those small parts. They can then be responsible for saving/restoring/tracking the state or info for that part. (This could be using a database, in process memory, whatever.)
If you put the controls in the master page you can have the parts' implementation removed from your other logic so you don't need to worry about capturing and returning data related to those parts with the rest of your model meant for your view.
Having the parts separate like that will make it a lot easier to AJAXify them as well since they would already be operating independently of your view data even though they are rendered at the same time.
I think you want to check out Partial Views.
You can use output caching or data caching, both supported by MVC 1.0/2.0.
Not sure if you're after this but project Orchard has a notion of widgets: http://www.orchardproject.net/docs/Default.aspx?Page=widgets&NS=&AspxAutoDetectCookieSupport=1.
I am designing a web application that requires loading multiple components on a single page. (In terms of page layout is similar to Google reader) I like to keep these components separate from each other (for reasons such as reusability). For example, I have a left panel that let's user navigate among multiple feeds that he's subscribed to (user specific) and on the right side of that we show the contents of that feed, and maybe a right panel which shows some specific info about that specific feed.
My understanding of MVC and more specifically Spring-MVC is that each controller is in charge of the entire page. Here are 2 solutions that I have came up with after researching this a bit, and none of them sounds good to me.
Have a main controller that is mapped to that URL, and then load the other components from inside the jsp file. This is doable but doesn't sound like a good solution.
Using portlets.
I want to know what are the best practices. This sounds like a very common web design issue in MVC frameworks, how do people do it?
Spring MVC controller is usually "in charge" :-) of handling a particular request which does not necessarily mean that said request results in a monolithic page being presented to user.
Since you're talking about Google Reader-like functionality, perhaps you'll be using AJAX to load / navigate between different components on your page? If that's the case, you can easily map your 3 components to separate controllers (via separate URIs) plus have one "main" controller to initially load the entire page.
If that's not the case and your page is static, you can have your controller act as "router" of sorts by first instantiating your components and then directing commands / requests to an appropriate component as necessary. Each component would update its own part of the model after which your "main" controller would return the view to be rendered.
Can you use portlets for this? Sure. But if we're talking about a single page it might be a tad overkill.