Spring Form Tag Broken for Portlet Use

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 ResourceRequest Change

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.

<init-param>
<name>renderResourceViewViaInclude</name>
<value>true</value>
</init-param>

Another person also suggested to set alwaysInclude to true on the InternalResourceViewResolver in the applicationContext, but that didn’t work for me either.

<bean id=”viewResolver” class=”org.springframework.web.servlet.view.InternalResourceViewResolver”>
<property name=”cache” value=”false”/>
<property name=”alwaysInclude” value=”true”/>
<property name=”viewClass” value=”org.springframework.web.servlet.view.JstlView”/>
<property name=”prefix” value=”/WEB-INF/jsp/”/>
<property name=”suffix” value=”.jsp”/>
</bean>

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.

Spring Portlet Handler Mapping Error

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.

Spring Portlet Validation Errors

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;

  1. 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
  2. Explicitly preserve the form object or errors after the redirect and ensure they get passed to the form when rendering completes
  3. 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 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.

I wrote an example for persisting the object and it seems the same result can be accomplished by persisting the errors object instead, but I haven’t tested that.  Options 1 and 3 can also be found in this thread.

Campus Organizations Portlet

As you know, I am currently programming web applications for the University of California Irvine.  I mainly work on web content for the student portal, ZotPortal.  If you aren’t too sure of what a web portal is, think iGoogle–lots of different content pieces all together in one place.  These content pieces are called portlets and I design, engineer, and maintain them on ZotPortal.  I want to talk about 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 spammers.  The connection will become apparent later.

Campus Organization Portlet

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.  All in all, the portlet is well put together and useful for finding clubs that interest you.

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.

  1. CSS Codedirection
    • Coded
      • <span style="unicode-bidi:bidi-override; direction: rtl;">moc.elpmaxe@zyx</span>
        
    • Displayed
      • xyz@example.com
  2. CSS display:none
    • Coded
      • xyz<span style="display:none">foo</span>@example.com
        
    • Displayed
      • xyz@example.com
  3. ROT13 Encryption
    • Coded
      • decodeROT13(klm@rknzcyr.pbz); <!-- You'll have to use built in functions or define your own -->
        
    • Displayed
      • xyz@example.com
  4. Using ATs and DOTs
    • Displayed
      • xyz[AT]example[DOT]com
  5. Building with Javascript
    • Coded
      • var m = 'xyz';  m += '@';  m += 'example.com';  $('.email).append(m);
        
    • Displayed
      • xyz@example.com
  6. Replacing ‘@’ and ‘.’ with Entities
    • Coded
      • xyz&amp;amp;amp;amp;amp;#64;example&amp;amp;amp;amp;amp;#46;com
        
    • Displayed
      • xyz@example.com
  7. Splitting Email with Comments
    • Coded
      • xyz<!-- eat this spam --><!-- yeah! -->example<!-- shoo -->com
        
    • Displayed
      • xyz@example.com
  8. Urlencode
    • Coded
      • xyz%40example.com
        
    • Displayed
      • xyz@example.com
  9. Plaintext
    • Displayed
      • xyz@example.com

The author of this study (credit to Silvan Mühlemann; his original post can be found here) even watched of these methods for 1.5 years just to see the different amounts of spam each strategy would receive.  These were his findings…

Obfuscation Methods

The current obfuscating strategy I use received the lowest amount of spam out of the ones that got spam in this study, so it is an good choice.  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.

AI Project: Checkers

To kick this Project site off 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.  It was an interesting project to say the least.  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 it was the closest and easiest tool to use for what I needed.  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 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 the average score for each move.  This is the piece table used for the Checkers game.  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.

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.  Try your luck playing against it in the Code/Src tab.

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
    • Just a nice option for the player to choose.

You are my joy

So my first quarter of being a third year ended with some surprises. For instance, I found out I don’t have to take a million prerequisites for my concentration in Video Games. That’s a relief, I didn’t know how I was going to get into all of them. Another was the fact that I can ALSO add a focus to my major, if I just take a certain set of classes where I have a choice in the matter. Yes, that’s right; I could graduate with a degree in Information and Computer Science focusing in Artificial Intelligence with a concentration in Video Game Technology and Culture. And if all goes well, that’s what it will be.
The last surprise wasn’t a pleasant one however. I got my grades back and I joined the D club. I knew Computer Graphics wasn’t my class, but I wish it was a bit more balanced. We were forced to use OpenGL in C++. I wish we were free to just use OpenGL in whatever language we were familiar with. Ugh, I knew going into the final I didn’t have a hot grade but I felt I dominated the final and was hopeful to get at least a C. Oh well. I have plans to retake it later, so I’m gearing up for round 2! Why should I regret the things I can’t change now? Oh that’s a good one, lemme write that down…
Overall, it wasn’t a terrible quarter. A, B, B, D. And I actually really enjoyed that class I got an A in. I’m taking it’s next class as an elective just for kicks next quarter!

Okay, anyway. Finals week was insanely fun. It almost didn’t feel like I studied(Mom I promise I did study). During one of our breaks, a discussion took over the apartment and we talked about a key characteristic of God in our lives. Does God make us happy? While our discussion was essentially the same point being argued from two seemingly conflicting viewpoints I thought it was really interesting. We, essentially, agreed upon the fact that, no God doesn’t make us happy in every situation in life but He does supply us with an underlying feeling of being fulfilled in a spiritual sense or even just the fact that He loves us. Temporal happiness is vastly different than an everlasting happiness, what we were just calling joy. Happiness, Joy, psh they’re the same right? I don’t think so, and I think that is why our discussion had us arguing the same point against itself.
So what is the difference between the two? Well, we were kind of on the right track in our talk. Happiness is kind of temporal, it comes and goes. Happiness is based upon circumstances that may or may not be in our control. The dictionary defines it as “a pleasurable or satisfying experience.” Happiness, read with the root of the word as ‘hap’ or ‘chance’, is an emotional response to our current status. This root of hap is very important, much of our lives and experiences are chance and luck and these experiences effecting our emotions is how we judge our happiness or lack of happiness.
Believe it or not, God didn’t intend for us to feel happiness all the time; there is “a time to weep, and a time to laugh; a time to mourn, and a time to dance” (Ecclesiastes 3:4). And weeping and mourning don’t sound too happy if you ask me.

Joy, on the other hand, is a state of being rather than a state of circumstances. This state of being can be found in a particular circumstance, but it is not limited to it. We can think of joy as a strong foundation built to support the healthy emotions, including happiness. The long-range evidence of joy is general gratitude, contentment, optimism, and a sense of freedom. When we are in joy, we are free to experience this elevation at all times and not just when life is going our way. Another difference from happiness, being in a state of joy doesn’t have to be induced by a positive experience.
James 1:2-4

Consider it pure joy, my brothers, whenever you face trials of many kinds, because you know that the testing of your faith develops perseverance. Perseverance must finish its work so that you may be mature and complete, not lacking anything.

Isn’t that amazing? We could be terribly unhappy going through trials, but we can be joyful knowing how these trials will shape us. How strong is that joy? How free are you when you can be so joyful during such hard times?

God knew that some circumstances would make us happy and others would make us sad, and that there is a time for each to affect us. But God also desires us to be joyful, to feel fulfilled, in all circumstances no matter what we might feeling emotionally. God gives us this joy because we are made complete in God’s love. And God’s love is forever, a constant love. That feeling of joy is the same euphoric emotion of happiness but it isn’t fleeting, it lasts long after the circumstances do. You might find this joy in your first child keeping you up at night for 3 months, or volunteering at a local youth group and having to help and deal with the younger kids and their drama, or maybe skipping your senior prom to help raise awareness about a war in Uganda with a bunch of strangers for five days, or that God is in fact real, He loves you and He wants to relate with you.

I might be very unhappy about getting a D in Computer Graphics, but I remain joyous throughout my college years simply because I love who I am growing to be, I fall in love with my friends over and over again, I marvel at the things I learn outside classes, and I know that everything will turn out just perfect in the end.

Spring Break!

So for Spring break I went on a missions trip with my Cru group at UCI up to NorCal. We were aiming at going to public areas and just talking to people about the gospel. Not by any means corner evangelicals, but we kind of cruised around and asked people if we could talk to them about spiritual/cultural beliefs. After a few questions, we would ask if we could share what we believe in and if you found a cool enough person, a pretty good convo would ensue. I didn’t really find any people that were really open, but some people did come to Christ through this trip which was AWESOME!
(Saturday)
After being the last group to reach Santa Cruz (at 3:30 am, wtf google?!), we went out sharing today in the heart of San Francisco. I was paired with my friend Sam and it was a really positive experience.  At first we wandered around a little aimlessly, but then we ran into a group of homeless people on the steps of what was the old San Francisco Mint from the gold rush era. We asked them if we could ask them a couple of questions regarding their spiritual background and they responded positively. Even though two of the three were way to drunk, one shortly passed out on the sidewalk, the third guy seemed very interested in what we had to say. We must have talked to them for at least 45 minutes. The thing they really liked was the fact that we had stopped and talked to them, since everyone else would simply pass right by without even looking. I hear this a lot every time I get to go down with the povertees gang. Homeless people love it when us ‘others’ talk to them.

Excommunicating the undesirable is something that has been happening since back in Jesus’ day. Jesus responded with kindness that they had never really experienced before. While it’s all good an easy to show this kind of kindness to people that have visibly less than us, what about other groups of people that we have as a church excommunicated?

The Homosexual Community?

  • Definitely excommunicated, but we don’t have to support their lifestyles to interact with them.

The Islamic Community?

  • We kind of excommunicated each other, ever since the crusades…

The World in General?

  • There are tons of crazy religious right, and even left, groups harming the image of the Church the world sees.

How can we/you remedy these broken relationships?

For one, can we stop using the phrase “that’s so gay!” in a negative connotation?  While I probably use it in the same sense that a gay person might use the phrase “that’s retarded!”, it is something they probably take offense to. Having your lifestyle taken and being used as an insult is a huge slap in the face. I would be a little offended if people started saying “that’s so Christian.” This isn’t a “heal all hurts” response, but it sure is a lot better to get to know someone when you aren’t using their life as an insult. And that’s how you spread the word, the Holy Spirit takes it from there.

EDIT://

And the times that our church does try to overcome this excommunication, it gets death threats.
http://www.msnbc.msn.com/id/29769258/

I understand that these people did some drastic things in their life. But redemption has to start somewhere. Maybe this was a great idea, until the community started giving out death threats.