Often, you'll want to prevent impatient users from clicking a submit button multiple times, as you can end up with multiple actions taking place, or object state can get in a bad way leading to errors. For this example we'll assume you have a final Submit Order form that actually places the order, auth's the credit card, etc...

You can't simply disable the submit button onclick with ATG as typically the submit button is the input field that actually activates the handle method. I tried a bunch of things, before I was able to get something working, so I wanted to share that here.

First thing is to write some javascript that will handle all of the magic (this example uses jQuery):

 
<SCRIPT language="JavaScript">
function submitform() {
	$('#commitOrderButton').attr("href","#");
	document.myFormsName.submit();
}
</SCRIPT>
 

Second, you need to move the input that calls the correct handle method out of the submit button and into a hidden form field:

 
<dsp:input bean="CommitOrderFormHandler.commitOrder" value="submit" type="hidden" />
 

Thirdly you'll want to replace the submit input with a submit <a> which will call your javascript:

<a href="javascript:submitform()" id="commitOrderButton">
    <img src="/myapp/img/button/submitOrder.gif" alt="Submit Order" border="0" class="submitOrder" />
</a>

And that's it.

Another reason that I love my mac: it can handle 1.3 GB log files easily with built in tools. I recently received a huge log file in zipped form from a co-worker with the warning "good luck opening it, textpad won't open it."

After unzipping it to the full 1.3 GB size I was able to open it using the built in Apple log viewer Console.

I ended up mostly using the terminal and tools like cat, less, grep, etc... to quickly find what I wanted and view the log lines surrounding the events I was interested in.

No problem.

I just read about the recently released Protocol Buffers from Google.

"Protocol Buffers allow you to define simple data structures in a special definition language, then compile them to produce classes to represent those structures in the language of your choice. These classes come complete with heavily-optimized code to parse and serialize your message in an extremely compact format. Best of all, the classes are easy to use: each field has simple "get" and "set" methods, and once you're ready, serializing the whole thing to – or parsing it from – a byte array or an I/O stream just takes a single method call."

It's like XML binding, only supposedly MUCH faster, and it looks very easy as well. The Java Tutorial lays it out pretty simply.

I'm definitely going to try using Protocol Buffers next time I need to transport some data across the wire and see how it goes. Has anyone tried this yet? Any comments?

Over at our new ATG Developer Community site, we're using Atlassian Crowd to manage our user accounts, groups, and single sign-on (SSO) between Jira, Confluence, to manage Subversion authentication, and to handle the forums (JForum) user accounts.

There was an example on how to integrate JForum and Crowd, which works pretty well. When you login to the forum, it checks Crowd and creates a local account if needed and logs you in.

However, we want single sign-on (SSO) so that our users don't need to login to the forums separately. We also want group membership in Crowd to be reflected in JForum to allow us to manage permissions based on Crowd managed groups.

I've written a JForum SSO implementation that ties into Crowd that I'm going to share here. It's version 1.1 (just added group sync), but it seems to work nicely.

Download the zip file here:
jforum-crowd-sso

unzip it into your jforum/WEB-INF/classes/ directory.

You have to install the crowd client jar, and the crowd.properties file.

You may also need to install the xfire jars if you get errors. I did.

Then you need to setup the sso configuration in the jforum/WEB-INF/config/SystemGlobals.properties

like this:

authentication.type=sso
sso.implementation = com.digitalsanctuary.jforum.CrowdSSO
sso.redirect = your crowd managed app login page
sso.crowd.syncGroups=false

That last flag should be set to true if you would like the user's groups synced from Crowd to JForum at auth time. This takes a second, so I made it optional. It does not push JForum group membership info to Crowd, it just syncs Crowd data down, as Crowd should be your master directory for that type of data.

The source code is available here for now:

CrowdSSO.java

-EDIT-

Added a full downloadable module and installation instructions here:

http://confluence.atlassian.com/display/CROWDEXT/JForum+Single+Sign-On+Crowd+Connector

I am thrilled to announce that we (Spark::red) have just launched the ATG Developer Community!

It is a free, open, community portal for everyone who works with ATG software, developers, architects, project managers, business users, everyone. The site has a wiki for posting articles, your own pages and blog entries, how-tos, and more. There is also a number of forums for discussion and asking questions. We also offer free Subversion code hosting, and Jira issue tracking for open source ATG related projects and code development.

Please check it out, register, and tell us what we can add to make it more useful.