Later this week, a few Vodorians, most of whom double as University of Illinois Alumni, will be heading back to the place that taught them (almost) everything they know. Vodori will be participating in Illinois' Engineers in Residence program on Sep 22nd and 23rd. The program is set up to allow established businesses and alumni to come back and talk to current students about their academic careers, and to answer any questions they may have about the transition from college life to the "real world" that is professional web development.
On Thursday, our team will give a talk and be available to answer questions, and on Friday, we will be hosting an office hours session from 10am to 3pm where any and all students will be able to interact with current Vodorians on a one-on-one basis. It should be a great time in Champaign, not only for the opportunity to visit Dos Reales again, but also for the chance to meet and interact with future Vodorians. We will be tweeting the event and answering questions with the hashtag #EIR2011, so make sure to follow us on Twitter (@Vodori) for the latest updates.
We've all been there, first day on the job. Whether it was a job at Mickey D's or an intern at Google; you were happy that you got the job. While going through the training you were on pins and needles because you didn't want to do anything stupid that would put you back to being a bum. As a freshy out of college and a newly hired Vodorian, I'm in that exact situation. Although I've worked at other companies in the past, they weren't quite the same as trying to work on websites from large pharmaceutical companies. Being a cart pusher at Wal-Mart utilized slightly less brainpower.
During my short time at Vodori, so far I've realized that learning in school is the same as in a job. No one is going to spoon-feed you the information, not all the information is written down and nicely organized like you want it, and Google quickly becomes your BFF.
Maybe that's all rainbows and ponies for you but I don't like being deprived of essential information that would help me keep my sanity. Learning the ropes is easier when you have some sort of guide or, better yet, a survival kit. One that you can whip out anywhere so that when you're in a dire situation you have something to fall back on. Usually only noobs need that so I'm going to call this the n00b survival kit! It's simply a list of things I think anyone who is a new developer would benefit from.
When you're stuck on a task and have no idea how to do it or fix it try to find an answer elsewhere, use Google, existing documentation, wikis, etc. If you still can't find the answer, don't be afraid to ask for help, but don't always ask for help. You need to have a balance between figuring things out on your own and knowing when to throw in the towel.
Chances are you can learn how to do things by simply listening to your peers and/or taking notes at meetings.Not everything is written down so people carry precious knowledge that is passed on to generations of Vodorians.
Being exposed to a lot of different technologies has made me realize a need to use tools to simplify simple tasks like email and data management.The following is a list of things I've found to be indispensable on a daily basis:
If you're writing a piece of code and it's taking forever, is extremely inefficient, or looks familiar; chances are it's been done. Look for similar code in other projects or on the web. If you can't find anything then don't be afraid to ask your fellow Vodorians. Code reuse is a natural cycle of life, it's better for the environment, and makes you look like a hard worker.
You can spot a n00b, in a variety of ways. They are very timid, usually space out, and say silly or goofy things.
In the event that you encounter a n00b; call 911, play dead, pour salt on it and watch it melt, yell at it in C++, or call a Mod.Once tamed you can help them back into society by teaching them how to become a l33t h4x0r.
Get involved with company events, running jokes, or happy hoursDrink beer, It's great for meeting other people and helps you be more comfortable at work.
This toolkit is not an exhaustive list but if you ever need to use it then feel free to print it out and reference it often. If you have any additional knowledge you can share with your fellow n00bs then please share it in the comments below. Thanks for reading!
Needing to run multiple sites locally is essential. Typing in "localhost" for all of the sites you develop is also not optimal. To solve this issue, we will be configuring virtual hosts in Apache to allow you to type in a domain name instead. This configuration is geared toward a local environment, however, the same idea applies in production environments.
In your hosts file, specify the domains of the websites that you will work on. [Windows: C:\Windows\System32\drivers\etc\hosts] [Linux: /etc/hosts]
127.0.0.1 local.domain1.com
127.0.0.1 local.domain2.com
127.0.0.1 local.domain2.net
Now in your Apache conf folder, create a sites folder. Here you will put all of your virtual hosts configurations. Next, in your httpd.conf file, look for the following lines:
# Virtual hosts
Include "conf/extra/httpd-vhosts.conf"
Make sure that there is no # character at the start of the second line. This will tell Apache that we intend to use virtual hosts. Once you have done that, add the following line to the end of the file.
Include "conf/sites/*.conf"
This will allow your Apache web server to read the virtual hosts defined in the sites folder you created. The only step left to do is define your virtual hosts for each of the domains we created above.
NameVirtualHost *:80
<VirtualHost *:80>
ServerName local.domain1.com
DocumentRoot "/var/www/domain1"
<Directory "/var/www/domain1">
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
<VirtualHost *:80>
ServerName local.domain2.com
...
A few notes about what we're doing here. The NameVirtualHost directive tells Apache that we are going to use the ServerName directive in order to determine the correct virtual host to serve. The DocumentRoot directive determines where the files for the site are. For Windows, we can use the / character for paths since Apache handles the conversion automatically, just prepend C: to the path if starting from the root directory. Order deny,allow tells Apache to evaluate deny rules first, then allow rules second. Allow from all gives everyone access to this directory.
Once you have created your virtual hosts file, restart your Apache server and point your browser to a domain name specified in your hosts file. You should be able to hit pages that are in the directory pointed to by your virtual hosts file.
The above is sufficient if you are not running a java webapp. If you are, a few more things are needed. In your httpd.conf file, make sure you have your rewrite, proxy and proxy_ajp module enabled.
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule rewrite_module modules/mod_rewrite.so
These modules will allow us to communicate with your application server (Tomcat, Glassfish, JBoss). In order to do that, we need to add a couple of lines to your virtual hosts config.
NameVirtualHost *:80
<VirtualHost *:80>
...
RewriteEngine on
RewriteRule ^/(.*) ajp://localhost:8009/$1 [P]
</VirtualHost>
This looks quite cryptic if you are not used to seeing regular expressions. Let’s break it down.
RewriteEngine on tells Apache that we will be using rules that determine where requests will be going. The ^/(.*) part of RewriteRule says to match urls (after the domain name) that start with [^] a backslash [/] followed by any character [.] any number of times [*]. If it matches (in this case, all urls will match), then serve up content via ajp://localhost:8009/$1, where $1 is a back-reference to the path matched by the first group of parentheses in ^/(.*). The [P] flag indicates that you want to proxy through ajp.
For example, if I request a url http://local.domain1.com/path/to/file.html, $1 will reference path/to/file.html, and the request will be served from ajp://localhost:8009/path/to/file.html. Again, once you are finished, restart Apache and you should be set.
For those of you running Macs, MAMP Pro allows you to do all of this in a simple to use GUI.
Most defect management systems have a field called Priority. It's usually a simple field with three to five possible settings that indicate how important an issue is. However, like Lady Gaga's wardrobe, the logic involved in choosing the best setting can be quite complicated.
I like to think of there being four components to determining priority: Severity, Exposure, Business Need, and Timeframe. Evaluating each component in sequence is a good process to use to reach a logical conclusion. However, each issue is unique and should also be evaluated on its sum total.
SeveritySeverity addresses the prevalence and penetration of the issue. Prevalence is how widespread the issue is—perhaps it occurs in multiple modules in the application. Penetration is how much the issue hurts—can the user easily work around it or does it cause a system failure?
Exposure indicates who can see the issue. Is it restricted to just the internal development environment? Is the client exposed to the issue? Are end users able to experience the issue?
Business need is an evaluation of the effect of the issue upon productivity, relationships, and reputations. Does the issue cause lost productivity for one person or many or the client? Does the issue pose a potential for damage to the developer-client relationship; perhaps through missed deadlines? Does the issue pose a potential for damage to the client-end user relationship through the exposure of the issue to the end user?
Considering Severity, Exposure, and Business Need, Timeframe is how soon the gears should start turning to resolve the issue. A good rule of thumb is to establish a timeframe that correlates directly with each priority. In the context of pre-production environment, think of natural milestones in the development lifecycle to establish timelines such as in time for a build, within an iteration, or before release to production.
Since we launched our new website back in March we have received tens, nay, dozens of inquiries about the metrics calculator visible on some of the pages. How does it work? Where does it get its data? As chief architect behind the calculator project I believe I can help answer some of those questions. So let's take a look inside!
(Follow along with the full calculator on the home page or the 'mini' calculator on the company page.)
|
|
|
The Vodori calculator as seen from our homepage |
The calculator first arrived at my desk on a scrap of a napkin from the Design team, detailing several boxes which would showcase different statistics about the company. The data points were chosen to reflect what we do best here at Vodori: convert coffee and food into multi-national webpages while riding bikes and alternately growing and shaving our beards. After several 'back of the envelope' calculations, done on the backs of actual envelopes, I began to program the precision logic which always delivers up-to-the-second statisics to our page visitors. The calculator changes over seconds, days, weeks, and months, reflecting the dynamic nature of Vodori.
Every day starts with the commute, and many employees (recently myself included) travel to the office by bike. Each employee's bike is fitted with a GPS transmitter, which reports the number of miles biked to and from the office to the central Vodori computer. You'll see the statistics on miles get updated from around 7am to 9am each morning, and around 4-6 each evening, as our dedicated Vodorians traverse the city on their way to and from the office.
As soon as anyone arrives at the office, it is generally accepted that they must imbibe their first cup of coffee. Our own observations show that if coffee is not consumed within the first hour of arriving, there is a risk that one's face might become stuck to one's keyboard. (The process has yet to be observed in action, but the distinct outlines of keyboards on faces have been previously identified.)
Each time we treat ourselves to a cup of coffee, special sensors in the coffee maker alert the Vodori Advanced Computing Grid (ACG for short) about another cup consumed, and the calculator is adjusted accordingly. If you hang around the website for a while, you can actually watch the coffee and bicycle miles increment in realtime! It should be noted that in 2010 the coffee maker became sentient for several days and refused to brew anything. While it was eventually offered a better position with superior coffee varieties, the stastistics accurately reflect this brief anomaly.
Midway through each workday, a tribe of hungry Vodorians forms to traverse the arduous quarter mile to Whole Foods for lunchtime eatings. Through an agreement with the grocery chain, Vodori employees are automatically marked through facial recognition as they enter and exit the store. This information is transferred through a secure network and provided to the coffee maker, which in turn loads it into the ACG and updates the ongoing statistics on the website. You can see the subtle rise and fall each day starting around 11:30 and usually lasting until 1:30. Though it starts off rather slow, by 12:30 when the most number of people are lunching you can see the numbers increment simply by refreshing the page.
In addition to clean, polished websites, we here at Vodori appreciate clean, well-trimmed facial hair. Though we strive to bring you the most up-to-the-minute information about the current state of Vodori's beards, we have yet to fully automate this process. In addition to his role as haircut inspector, co-founder Nathan Kurtyka makes rounds 3-4 times a day inspecting each active beard. The data collected is entered into the beard database ('BeardDB') where it is calculated and presented online.
Typically there are several major growth cycles occuring at any one time, including 'long-term' beards (those who grow for months and then shave for months), 'mid-term' (those who shave every few weeks), 'short-term' (those who shave every few days), and 'scraggle' (those who forgot to shave). This is easily represented in the following graph:
With the energy left over after growing beards, we produce awesome websites. The outbound connection to all of our servers measures the exact number of pixel data being delivered to the users browsing our sites. Each time a Pepper author sends another page out into the world, our calculator is notified and, quite proudly, increments itself. Finally, as the end of another day approaches, employees typically enjoy one last free cup of coffee before getting on their bikes and riding home. The evening commute is captured with each rotation of their wheels.
|
|
|
The Vodori calculator as seen from our company page. |
I hope this article has been an enlightening introspective into the Vodori Calculator. From its humble beginnings as a sketch on a cocktail napkin, to its modest existence on the back of an envelope, to its eternal presence on our website, its numbers speak to all that we are as a company and a people.
Our team of mathetmaticians and biologists continue to crunch the numbers in their ongoing quest to answer the question, "What makes a Vodorian a Vodorian?" And perhaps in the future we will know the answer, but for now we continue to collect as much data as we can, while quietly turning coffee into progress (and beards).
My absolute favorite feature of Firebug is its crazy-good documentation, available in wiki form.
Specifically, in addition to console object's better-known log, info, warn, and error methods, I find myself coming back to console.dir(object), which prints out the key/value pairs in an object as if you were inspecting it in the DOM tab, and console.dirxml(node), which prints a DOM node's structure as if you'd inspected it in the HTML tab.
 |
|
Firebug output of console.dir |
 |
|
Firebug output of console.dirxml |
The console's features are listed on the Firebug wiki. Many of these commands work in the WebKit Inspector, too.
Also, be sure to check out all the plugins available for Firebug. Some of my favorites are FireCookie and Firediff
With Google's Chrome browser now being developed at a lightning fast six week release cycle, users are able to get their mitts on shiny new features sooner. Some of these features sneak in and will never be seen or used by the vast majority of web surfers; these are improvements to the Chrome Developer Tools. Google has been building up an impressive suite of front-end development debugging tools that are bundled right into the browser instead of being a separate downloadable extension. Having been a Firebug user for years, it was hard to part ways when I switched to using Chrome as my main browser. The developer tools were somewhat lacking then, but after so many iterations, with the Chrome developer channel browser being at version 14, the developer tools have grown increasingly more powerful and I have not looked back since. Going over every little feature of the developer tools would require a long series of blog posts, so in the interest of TL;DRers like myself, I will highlight some of my favorite features (note that some of these features are also available in other debugging tools, especially Safari Developer Tools which are essentially the same thing).
Ever see something cool and wondered how it was done, only to see that the JavaScript code was minimized and obfuscated? One of the latest CDT additions is a "Pretty print" feature which will quickly auto-format JavaScript code for you which will get you half of the way there to understanding how the code works.
There are several flavors of page load speed analyzers out there, and one of the popular ones is an open source tool called Page Speed. It analyzes whatever page you throw at it and will provide tips on how to optimize the loading time of that page. With the Chrome Developer Tools, this handy tool already comes bundled. After all, page load times do play a small factor in Google search rankings.
Chrome's Developer Tools come jam packed with powerful CPU and Memory profiling tools to help you find those bottlenecks in your JavaScript code or even find when your backend code is giving slow responses. These tools are invaluable when you need to figure out what is causing a certain page to slow down, whether it's from loading scripts blocking the page load, the browser itself taking a while to render those millions of DOM nodes you might have created, or some of your code eating up a lot of memory.
I know this is also a feature in Firebug, but it is such a nifty shortcut that I wanted to share it with people who did not know about it. In the Chrome Developer Tools, whenever you click on a DOM node in the Elements tab, it saves a history of the five most recent DOM nodes you've clicked on as variables in the JavaScript console. This makes it quick and easy to run commands on DOM nodes without needing to type out document.getElementById() (or whatever shortcuts your JavaScript framework provides) in order to reference a certain DOM node. These variables are $0, $1, $2, $3, and $4. This comes in handy when you want to quickly test some JavaScript on a node that doesn't have an ID on it. You can simply click on the node, then type something like this into the console:
$0.appendChild(document.createTextNode("Hello World!"));
Google has built a very solid set of tools for making your front-end development life easier. It comes with all the standard bells and whistles you would expect from a debugging tool such as on-the-fly HTML and CSS editing and a JavaScript debugger with break points and stack traces, but it also gives you enough tools that you won't have to install any extra extensions. If you have never tried Google Chrome or only tried using it a few years back, I highly suggest you give it another try; it has come a very long way in the past few years.
|
With the 306k+ iPhone apps and nearly 200k Android apps how can you choose which are the best? We can help you with that. Even if you've had an iPhone or Android phone for years you may discover something new. Just got a shiny new smartphone? Well welcome to the age of instant access, where a quick Google search can squelch a dispute faster than Quick Draw McGraw. You now have the world-wide-webs at your fingertips, can access email and perhaps most importantly you can download apps! Whichever camp you fall into let us know what YOUR favorite apps are in the comments below. |
In this post we focus on business and productivity apps:
Lets you create notes, to-do lists, screen captures and more. It’s a really handy app that helps us capture all of those random great ideas we have throughout the day (ok, so maybe not the great ideas we have while we’re in the shower but we bet they’re working on that). Most of all, we love having access to all of our notes on the go.
Cost: Free
Available for: Desktop, iPhone, iPod Touch, iPad, Android, BlackBerry, PalmPre, Windows Mobile
Turns speech into text so we can remember useful or clever thoughts walking down the street and share them via SMS, email, Facebook or Twitter.
Cost: free
Available for: iPhone, iPad, iPod Touch
This app allows you to save the web pages you want to read later. This desktop site might not look like much but we really like the mobile interface for accessing Instapaper, with it’s adjustable font sizing, choice of light or dark background, tilt scrolling and more. There’s even a dictionary that’s accessible when you happen to be offline. Instapaper also lets you share your content across multiple social networks/other apps.
Cost: $4.99
Available for: iPhone, iPad, and Kindle
Search will never be the same with this this souped-up version of the Google search interface that includes search by voice, camera picture, location and more. Access to other Google applications like Maps and Gmail is also a breeze.
Cost: free
Available for: Android, BlackBerry, iPhone, NokiaS60, and more
Take pictures of things like documents, receipts, whiteboards, business cards, and notes and turn them into PDF documents. Even better is that all of the information stays with your phone so your information is confidential (JotNot does not store our data).
Cost: $0.99
Available for: iPhone, iPod touch, and iPad
This native app for Google Tasks is frills-free but that’s probably part of it’s charm. It does just what it says it should do, “View and update your Google Tasks, even when there is no network connection.” And that’s why we like it.
Cost: $2.99
Available for: iPhone, iPad
With this ‘magical’ app you can control your computer straight from your iPhone or iPad. Access your files and run your applications (even Photoshop). ZDNet even called the iPad version of this app a “killer VC client.”
Cost: $24.99
Available for: iPhone, iPad
Originally a proof-of-concept Prompt has turned into a, “clean, crisp, and cheerful, “ SSH/Terminal client. We think it’s great for those on-the-go server maintenance needs. Oh, those clever apes at Panic…what will they come up with next?
Cost: $4.99
Available for: iPhone, iPad
If you’d like an alternative to Safari then give Terra a spin. With it’s more traditional tabs and the ability to save web pages for offline viewing you may never go back to Safari again.
Cost: Free
Available for: iPad
Finally! Another non-iOS app. Have some hefty calculations to do on the go? This app is like having a scientific and engineering calculator in your pocket. Ah…it takes us back to Calculus II…the good ‘ole days. There are 2 versions available a free one and a ‘donate’ version for $3.25. If you like it as much as we do consider getting the donate version as a sign of your appreciation. You do get a few extras like, customizable unit conversions.
Cost: free or $3.25
Available for: Android
Welcome back to another exciting edition of avoiding xml configuration files in Java view rendering frameworks! In this post, I will be looking at two further applications, SiteMesh and Tapestry.
SiteMesh works as a servlet filter, utilizing the 'Decorator' design pattern. As pages are requested, they are first parsed and then passed through to the SiteMesh decorator classes, which insert the required markup. Because it's just a filter, it can be used alongside normal JSP, HTML, or even Freemarker and Velocity templated pages.
Configuring SiteMesh is fairly simple, requiring an addition of the filter mapping in your web.xml file. However, you will also need to make a 'sitemesh.xml' file, and possibly one or more 'decorators.xml' files.Herein lies the main headache of using this system. Every single decorator needs to be mapped to pages. Whenever you change a resource path, or want to apply decoration to a new page, these files must be updated.
There are a few bright spots though, namely that you can apply specific decorators based not just on path but on browser, locale, views (like 'print' or 'mobile'), and even request parameters. You can also specify multiple decorators for each mapping, allowing for a degree of modularity. To some extent, you can use page tags to apply decorators inline on a page, referenced by the name of the decorator. Generally, these configuration changes require server restarts. You can add the line <config-refresh seconds="3600"/> to the sitemesh.xml file, which will allow changes to be reloaded, but it hardly seems adequate for fast-paced, incremental changes during development.
Java-based configuration is possible within SiteMesh, but it is far more complicated than the xml version. By extending the ConfigurableSiteMeshFilter class you can use the provided SiteMeshFilterBuilder to programmatically add decorator filter paths. While the actual syntax isn't too bad, I ran into quite a few problems trying to get my class recognized, instantiated in the correct order, and working with the other web components.
SiteMeshFilterBuilder builder;
// ...
builder.addDecoratorPath("/*", "/default-decorator.html")
.addDecoratorPaths("/articles/*",
"/decorators/article.html",
"/decoratos/two-page-layout.html",
"/decorators/common.html")
.addExcludedPath("/javadoc/*")
.setMimeTypes("text/html",
"application/xhtml+xml",
"application/vnd.wap.xhtml+xml");
SiteMesh has a gigantic 'gotcha' often referenced as the deciding vote for people thinking about using it. When SiteMesh decorates a page, it stores the ENTIRE contents of the page in memory prior to decorating. For most applications this isn't much of a concern. However, for large data-driven pages it can be a big deal. An OutOfMemory exception is usually non-recoverable, and can bring your web-application to its knees.
Now I'd like to poke around in Tapestry, which is sort of the odd-one-out in this series. More than just a decorator or compositor, it's a full web application development system. There is an extreme emphasis by the designers on "convention over configuration". Class and method names are intended to correspond directly to page elements and their url's.
The normal amount of changes to web.xml are required, adding the Tapestry filter mapping and servlet context, but that's it! Tapestry features a hearty collection of annotations and base classes, fully integrating configuration with the design of your application. By simply naming your classes and their methods appropriately, you've provided the majority of the necessary configuration information to the Tapestry container.
The downside to all of this is that, since nearly all of the work is done in Java, non-programmers may find even simple tasks to be problematic. And when I say everything, I really do mean everything: even basic math is restricted to the Java code, since Tapestry does not work with JSP pages. The work done on the pages is fairly straightforward, using <tags> and ${expansions} to insert templated information. Decisions about what to render and how are deferred to the backing component class for the page.
Tapestry is quite keen about making all changes incremental without requiring the server to be restarted. Each time a Java class is changed, it will unload the old one and reload the new one. In fact, this is a big selling point of the Tapesty project. Their stated goal is to allow many developers to work in realtime on a shared development server. One of Tapestry's "superpowers" is an extremely helpful error reporting subsystem, so if something seems to be missing or even misspelled on a page it will let you know with great detail, suggesting alternative spellings of known classes, and classes and methods you might still need to create. If you're looking for a faster way to make web applications, and are at home in Java code, this might be the system for you.
Wrapping up our exploration of these two rendering frameworks, I think it's useful to look at their primary differences. SiteMesh is a smaller tool for basic page decoration, which seems to provide diminishing results for larger-scale projects. Java configuration is possible, but somewhat clunky and at odds with the simple usage style when editing pages (that is, the simplicity of editing a page would lead one to expect simpler configuration tools). Even though xml is the better option here, it means you will be constantly editing the sitemesh.xml file and individual decorators' configuration files.
In contrast to all of this we have Tapestry, a large and complete framework for web development. No xml configuration is required, as nearly all of the work is done in Java code, utilizing a "convention over configuration" design philosophy. On the other hand, even minor changes to a templated page will require Java code to be written, which can be problematic for non-programmers. However, working in a team with both developers and designers could very well make this a non-issue.
It's also worth pointing out that, while Tapestry is released under the Apache License and has the full support of the Apache Software Foundation behind it, SiteMesh is developed by OpenSymphony and is released under their own "OpenSymphony Software License" (which at least claims to be compatible with the Apache License). While both systems are up to date, Tapestry has seen some amazing growth in the last few years thanks to the community and foundation support behind it. Developers also benefit from integration with other Apache tools, such as their search offering Lucene.
Next time...an in-depth look at Apache Tiles, and some final meditations.
One of the most important architecture patterns that we use here at Vodori is MVC, which stands for Model-View-Controller. In our case, we use Java to create this MVC architecture, and use the Spring framework specifically to enhance the process. The Model is the object or objects that hold the data for the application, the View controls the way the application will be seen and interacted with, in our case a JSP layer. Finally, the Controller handles interactions between the model and the view, including user input or business logic. The Controller layer contains the core of any business application’s logic and complexity.
The Spring framework makes implementing an MVC based application really easy. Using the @Controller annotation, we can designate a java class to be recognized by Spring as a controller, and using the @RequestMapping annotation, we can specify which requests the controller is supposed to intercept. Request mapping at Vodori is usually dependent on GET’s and POST’s, but there is also support for HEAD, PUT and TRACE, among others. Most requests are GET’s where the browser is simply trying to access a specified URL. In some situations, such as if a form is being submitted, the browser does a POST in order to send data to the controller along with the request. Adding the annotation:
@RequestMapping(value = "/testForm.htm", method = {RequestMethod.POST})
to a method in the controller provides a good example of a request mapping annotation that handles a form submission(we can tell by the “RequestMethod.POST”). It can validate the form, add attributes to the model, make functions calls, and determine the view to return.
By using the @ModelAttribute and the @RequestParam annotation, we can specify what specific data we want to explicitly pass into the controller for processing. For example,
public String registrationStep(HttpServletRequest request,
ModelMap model,
@RequestParam(value = "step", required = false)
String step,
@ModelAttribute("userProfileForm") UserProfileForm userProfileForm,
BindingResult result)
{
//controller code
}
The @RequestParam allows us to send in a simple value that will be converted to the declared method argument type (String in this case) and assigned to a variable. The @ModelAttribute tag allows us to pass in a more complex object, which may consist of multiple request parameters. The model attribute can be specified with a variable name (“userProfileForm”) if there are multiple attributes, so that the method knows which instance to pull in. If the variable needs to be persisted throughout the session, the same variable will also need to be added as a session variable next to the @Controller annotation at the top of the controller class, e.g., @SessionAttributes({ "userProfileForm", "contactUsForm" }).
The next important thing to consider is the separation of controllers and services. Controllers are meant to handle specific user requests through their entire lifecycle from parsing the request through determining which view to return. We can separate out the common application functionality into services, which modify the model, write to databases, send emails, etc. This separation is not technically necessary, but it allows us to create code that can be reused or easily extended without much work. If we had to switch persistence frameworks and moved from Hibernate to OpenJPA using only the controller level, we would have to rewrite every controller and possibly add much more code, or duplicate code that we have already written. On the other hand, if we had all of our logic in the service layer, all we would need to do is update the logic there by modifying the method which interacts with the framework, meaning we can switch between frameworks with minimal, if any, changes to the controller.
By using a common application architecture such as MVC, we can be sure that if a new programmer or one of us Vodorians need to make an update in the future, we will be able to easily determine where to look for certain parts of code, without having to know anything about the code specifically.
Hipsters, nerds, and suits. We’ve learned a lot and we’re sharing it all. Because sharing is caring.
Help us, fellow web jabroni; we have a large project scope.
Join our force ›Copyright © 2013 Vodori - All Rights Reserved | Privacy Policy
we are hiring