This issue came up as I was dealing with the Spring Portlet ResourceRequest change(before I found the problem/solution). Still not getting the portlet to render views via ResourceRequests properly, I decided to test with Spring 3.2.x to see if the problem would follow. I was also curious to see what changes would be made on the portlet side of things, any added improvements or shortcuts? Based on the 3.2.x changelog, not much was changed regarding portlet support(ctrl+f “portlet”). But its never that simple, right?
Enter SPR-8684. This change actually makes things easy for most Spring webapps; automatically prepending the contextPath and servletPath in the Spring form tag is an easy shortcut. But for portlets, this renders the form tag essentially useless. Portlets don’t want their forms to be prepended with their own contextPath, they should resolve to the portal’s contextPath. The good news is that my request for a fix was accepted almost instantly, SPR-10382. So I’ll just have to wait to use Spring 3.2.3.
I know many of my most recent posts have been about problems using Spring, but I don’t want to sound like a complainer. Without Spring I would be without a brilliant framework to code portlets with, and its a pretty niche area to be honest. I love Spring because they are constantly moving forward by adding new ideas and technologies into their product. Also, the community support is pretty fantastic!
Spring Portlet made a change to the way portlets return resource requests. They changed the default behavior of DispatcherPortlet when handling resource
requests to use PortletRequestDispatcher.forward instead of PortletRequestDispatcher.include; JIRA issue here — SPR-9876. I’m indifferent about the change. It seems more people use the ResourceRequest with the .forward, so its good for them I guess. I mostly use resource requests with small custom jsps, so I use the .include. But it doesn’t really matter to me aslong as they maintain compatibility, which they did. If you set renderResourceViewViaInclude property to true(defaults as false) it should work the same as before.
Well, I can’t get my views to render through resource requests anymore after this change. The only change that was supposed to be needed was adding an init-param into your portlet.xml, but even with that in place my views just return blank.
Another person also suggested to set alwaysInclude to true on the InternalResourceViewResolver in the applicationContext, but that didn’t work for me either.
I’m still trying to figure out why this isn’t working. Based on the git commit tied to the issue, it looks like aslong as renderResourceViewViaInclude is set to true then the dispatcher should call .include. Is it not working as intended? Or is renderResourceViewViaInclude not being set properly?
The culprit has been found! While talking with the person who made the JIRA issue and git commit, it looks like Spring never implemented the renderResourceViewViaInclude flag on DispatcherPortlet(and now rereading the last comment on JIRA I can see that they actually said they weren’t going to). So all resource requests were ALWAYS using .forward. The fix? You will have to subclass DispatcherPortlet and override doDispatch to use .include, or set up your own flag.
Hopefully Spring will actually put this the flag into the their portlet library so people won’t have to do this for every portlet that wants a review returned from a resource request.Talking with some other portlet developers, it seems I am in the minority of using resource requests to return views, they are mostly used to return pure json data. It seems I either need to get with the times or I will have to use my subclassed DispatcherPortlet in all future portlets.
Another post about Spring Portlet MVC. Currently in Spring 3.1.2(and 3.1.1 as far as I can tell) there is a problem with portlet annotation handler mapping apparently due to a flaw in predicate comparison; its documented more in depth in their jira at SPR-9303. The issue has been reported to have been fixed for Spring 3.1.3, but until that comes out I had to find a work around.
The hard part about diagnosing this bug is that it may or may not affect your portlet depending on how many annotation handlers you have, how they are structured, and in what order they are picked up by Spring. Many of the portlets we have created haven’t had any problems(or none that we have experienced so far), but one portlet in particular was mapping every single render request to its default mapping. Someone on stackoverflow has investigated the ordering further and shows exactly why the ordering matters. Long story short, if the default handler mapping isn’t ordered last then any handler mappings behind it will never get used.
A workaround is simple enough, albeit a little ugly. Remove the default annotation handler mapping method into its own class and package and have Spring component-scan to register it separately. Like so:
<context:component-scan base-package=”com.kwilkins.portlets.foo”>
<context:exclude-filter type=”regex” expression=”com.kwilkins.portal.foo.controller.springbug..*”/>
</context:component-scan>
<!– This package temporarily exists due to spring bug; SPR-9303 –>
<context:component-scan base-package=”com.kwilkins.portlets.foo.controller.springbug”/>
Doing this should scan and register the default mapping after everything else already has been.
I am currently in the process of updating some of our portlets to use Spring 3.1 and the new Portlet 2.0 spec in preparation with a portal framework upgrade taking place for ZotPortal this summer. A problem we were experiencing using the new Spring 3.0 annotations for our portlets was the new way Spring handles validation/binding errors for forms. Before, the validation is done in the action phase, then the error(s) are stored in the model attribute, and if errors are present you can redirect back to the render phase so the initial page form will be displayed again with the submitted data but this time displayed with error messages that explain to the user why it failed validation. I was surprised when the validation would fail this time and redirect back to the page form but no errors would show. Apparently something changed in the way Spring handles objects placed into the model via the @ModelAttribute annotation. Now Spring would replace an object even if it is associated with errors and they will not be present/displayed when redirected back to the form.
A few solutions have been proposed across the spring forms, stackoverflow, and the interwebs;
Validate the form object during the render phase as well. This will generate the errors and have them displayed on the form when the rendering completes.
Explicitly preserve the form object or errors after the redirect and ensure they get passed to the form when rendering completes.
Instead of using @ModelAttribute, persist the form object as a session attribute so it persists across the action and render phases.
Option 1 isn’t really an option for our applications. In the initial render phases the form object would not pass our validation tests because it isn’t filled out yet! We don’t want to display validation error messages to the user upon the first load of the form when they haven’t had a chance to submit any data yet, it would seem a bit rude in my opinion. Validation should occur if data has been submitted. Option 3 seemed to be overkill, submitting a simple form shouldn’t need to persist the form object in the session which lives well past the action phase of the submit. I believe Spring has some nice ways of handling these session attributes, but I haven’t played with it very much.
I decided to use option 2. When the render phase is deciding what object to populate the form with it first checks to see if an applicable object with errors already exists in the model, if it does it lets that object stay in the model to populate the form. The previous submitted data and errors get passed through the render phase and displayed on the form for the user to see and fix so it can be validated properly.
Currently I am a student software engineer for the University of California Irvine where I build web tools for the for the student portal, ZotPortal. If you aren’t too sure of what a web portal is, think iGoogle – lots of different content pieces on one page. These content pieces are called portlets and I design, engineer, and maintain them on ZotPortal. I want to talk about two different things in this post, 1) a portlet I designed that enables people to search for on campus organizations at UCI and 2) some different ways of obfuscating email addresses (or other data) from potential scrappers/spammers. The connection will become apparent later.
The Campus Organizations Portlet was the first portlet I built. The idea was simple enough: given a feed of all the campus organizations, parse out the data, and display all the organization information in a searchable UI. There are currently around 540 different organizations to show, so the data needed to be broken up into separate pages. I decided to use the Fluid Pager javascript component to page through the data without having to reload the page. This enables us to place each organization in its row along with its info box and category. The gapped paging scheme makes navigating through the pages a breeze without cluttering the pager bar. Some more javascript was added for to display organization info and the search bar to re-render the pager with just the search results.
Now, on each organization’s information panel we supplied a mailing address so a user could contact the club leaders. And since this portlet is accessible from the guest view, there is potential for spam bots to troll through our student portal and collect all of the club email addresses to sell or send spam to. I wanted to hide the email addresses from the spammers while at the same time enable the viewer to use the email. So, I spelled out the symbols in the email to confuse any would-be spam bots reading through my portlet data. Instead of coolclub@uci.edu, coolclub[at][you see eye][period]edu. An average spam bot wouldn’t recognize this as an email address, spam avoided! The only thing that bothers me with this approach is the fact that the user has to do the work of replacing [at][you see eye][period] with”@uci.”. Sure, it isn’t very difficult or time consuming, but it would be a lot better if the user could simply copy/paste or click a mailto tag.
I found someone in a similar dilemma and a really good answer was provided to him. Examining these different methods of obfuscation allows us to pick the best one for our situation.
xyz<!-- eat this spammer -->@<!-- ha ha -->example.com
Renders as
xyz@example.com
Urlencode
Code
xyz%40example.com
Renders as
xyz@example.com
Plaintext
Renders as
xyz@example.com
The author of this study (credit to Silvan Mühlemann; his original post can be found here) even watched each of these methods for over a year just to see the different amounts of spam each strategy would receive. These were his findings…
The current obfuscating strategy I use received the lowest amount of spam out of the ones that got spam in this study. However, there are better strategies, with zero spam, that don’t require any work from the user (strategies 1-3). So, I should change the strategy for obscuring the organization email in the portlet since there doesn’t seem to be any cost Late February 2011, we changed the obfuscating method and decided to use CSS direction. We still are looking into a combination approach with CSS direction for display and javascript building for a mailto link for better and easier interaction.
I figure I’d start revisiting some work I did a couple quarters ago at UCI in an AI project course. We set out to experiment with some different Checker strategies and see how they would fair against each other, against us, and (most importantly) against another team developing another Checkers AI system. I’ve created a simple game from my own ideas, but I haven’t created a game from a preexisting set of rules before or have the game play against the human. The game system is pretty self-explanatory; moves are hi-lighted, jumps are mandatory, a piece becomes a king on the other end of the board, and you win when you lose all your pieces or when you can’t make a move. I really wanted to build this in something other than a Java applet, since they aren’t used much these days, but UCI programming courses heavily use java and their game courses heavily use a custom library called UCIGame (you-see-ga-me). The AI depth search uses a min/max and alpha/beta pruning strategy to allow the massive move set to be shortened so a move decision can be made in reasonable time, but a search of depth 10 still makes a noticeable pause.
The most interesting part of this project is the AI strategies we implemented.
Random
The AI selects a move at random. Hardly a challenge
Basic
The AI examines all possible moves within the search depth value. It then selects the move that allows the AI to be in the position were losses and gains will be the most beneficial. Ideally, the more pieces it can take and least amount of pieces it can lose will increase the probability to win the entire game. This strategy is easily countered by tricking the AI with bait, and then trapping and taking its piece. The best choice is based on an average score derived from a couple of heuristics.
Taking pieces(+ for regular; ++ for kings)
Loosing computer pieces(- for regular; — for kings)
Getting ‘Kinged'(+)
Moving a piece from a ‘King Me’ square(–)
Piece Table
In addition to the heuristics above for the basic strategy, a piece table is also incorporated into the score for a move. The piece table gives each square a value and it is added into the average score for each move. This is the piece table used for our AI. Each number denotes a square worth value. The higher the value, the higher the worth of keeping a piece on that square. Notice that all ‘King Me’ squares hold the highest value of 4, these spots are very important, and a player would only want to move a piece from this location as a last resort. Squares close to the sides of the board also have the value 4, and closer inside is 3, are the least vulnerable from attacks. On the other hand, the squares in the very middle of the board hold a value of 1. These squares get vacated as fast as possible since they are most susceptible from attacks. The numbers make a sort of spiral from the outside, decreasing in value as they come closer to the middle. This strategy is very strong since it combines the heuristics from the Basic strategy to minimize losses and maximize gains as well as achieve optimal piece placement on the board to further minimize more losses and maximize more gains. I have not been able to beat this strategy with a high depth.
Overall, it was a very enlightening project to work on. I learned a lot working with massive decision trees, different strategies, implementing given rules, and classifying data sets using a range of scores. I was quite happy with the outcome of an AI that can easily beat its creator, and with the fact that we smoked the other Checkers project team. Checkers is a solved problem after all, so if we were evenly matched it should tie or win ~50% of the time.
EDIT// before java was more or less shuttered from browser support, we had a working embedded applet you could play but not anymore.
I have a couple of planned changes for this application’s future:
Simplify the button options
The three buttons on the GUI made sense at the time I created them, but many users have reported that they have trouble knowing which one to click when. Combining the Resign and New Game button into a single one will free space for an AI vs AI option. Another problem is that when the Make AI Move button is pressed the player switches sides. They have to click it again to resume play as the original red color.
Allow the player to select his color at start of game
