Date formatting, GWT, and validation

[DispatchMediaGroup]

I've set up an implementation of the community edition of KonaKart at shop.dispatch.com, complete with a custom SSO design, custom front-end, and a small catalog, but there are still a couple of things I cannot quite figure out.

One thing I cannot figure out is how to change the formatting of dates as they appear to customers.  For example, although I was able to change the format in the Admin app to MM/dd/yyyy, I'm not finding success in having that change propagated out to a user page, like the one page checkout page when it asks for a customer's birthday.  Any ideas on that?

Also, being *completely* unfamiliar with GWT, how can I add validation messages for that screen as well?  So, if someone didn't enter their shipping state, and then they chose to attempt to continue the process, I would like to display a validation message stating whatever problems are on the page, or on a per field basis.

Along the lines of my GWT ignorance, can someone perhaps give me a quick rundown of how it's implemented in KonaKart and how I could go about adjusting some of its behavior?  I'm perfectly okay with references that can help me, too.  There are some (of course) last-minute changes that stakeholders would like to see, but I'm fairly sure that those changes will lie with the GWT code, and I, at this point, just need to figure out how to make the change(s) and move on.

[DispatchMediaGroup]

Also, I see in your demo store (i.e. konakart.com/konakart/Welcome.do) that your state field is a drow-down - how did you do that?  I've enable the state field through the admin interface, but it only displays as a text box, rather than the preferred pre-populated drop-down box.  Similarly, how can I make 'United States' the default in the country drop-down?

Again, I apologize for my ridiculously simple questions here, but as I mentioned, we're in crunch mode to get this released, and there are, all of a sudden, a lot of small little issues to resolve...and again, I know nothing of GWT.  Thanks, all.

[kate]

If you don't want to use the GWT One page checkout you could always switch to the JSP-based multi-page version instead.

However, if you haven't looked closely at GWT yet you still might want to try to understand that first.  For a java programmer it should be easy to understand as it's all java code.  The GWT compiler converts that java code into javascript but you don't need to worry about those details.

You can even import this one page checkout GWT code into Eclipse and debug it easily from there - stepping through your java code as the javascript executes.   It's very clever stuff.

Check out the User Guide for details.

[DispatchMediaGroup]

Well, I made all the onepagecheckout GWT changes I wanted to and ran the ant script.  The compilation went okay, outputted success, and generated a whole bunch of new files, including one javascript file, at the location, /usr/local/konakart/custom/onepagecheckout/war/com.konakart.Konakart/.  I then copied everything in that directory to /usr/local/konakart/webapps/konakart/.  The only javascript file that was generated was called com.konakart.Konakart.nocache.js, which matches the GWT javascript I was able to find that came packaged with KonaKart.

But when I restart KonaKart and then test the one page checkout process, I get the exact same results and behavior as I did before.  Anyone have any ideas?  Am I missing a step, putting files in the wrong place, etc.?  Is there more I can post to help others help me?

[DispatchMediaGroup]

Here are the two onepagecheckout files that I edited.  You can see the changes and comments on the changes' purpose.  I made changes to Konakart.java at line 395, where action== REGISTER_KO and at LoginBody.java at line 248, where I added a method that gets called from the aforementioned Konakart.java.

My purpose in these changes is to alter one aspect of the onepagecheckout process.  When a Customer uses onepagecheckout with an email address that's already been registered with KonaKart, I want to display a custom message with a link off to a Dispatch.com (my company's site) login page.  That login page would take care of redirecting back to the KonaKart checkout process, where the customer would then be logged in to KonaKart, effectively bypassing the onepagecheckout process.  However, it does not seem that the newly compiled code has any effect. Hope this addendum helps...

[kate]

might seem a silly question but did you refresh the browser to ensure you weren't caching the old one page checkout code?     

[DispatchMediaGroup]

I did figure this one out, actually.  Thank you for your reply and attempt at help though.  For others going through this process, there's a bit more to the steps that must be taken than the documentation might have suggested, although it probably should have been fairly obvious to anyone with experience in application deployment and web configuration.

I had literally just copied the generated javascript file, but nothing else, to <konakart>/webapps/konakart/.  But there's much more that should have been done on my part, which I will try to detail as well as possible below (admins, correct any mistakes, please):

1.) Go through the KonaKart documentation for making changes to the one-page-checkout (OPC) process, and continue to follow the documentation for ant building the OPC code.

2.) All generated classes and files will be put in /<konakart>/custom/onepagecheckout/war/.  Under this directory, there should be three folders: com.konakart.Konakart, images, and WEB-INF.
     - com.konakart.Konakart
          -- the contents of this generated folder should be copied to /<konakart>/webapps/konakart/, overwriting any files needed.
     - images
          -- this folder should also be copied to the aforementioned location, /<konakart>/webapps/konakart, merging with any existing files at that location
     - WEB-INF
          -- the contents of this should be copied to /<konakart>/webapps/konakart/WEB-INF/.  Particularly pay attention to where the new classes folder gets copied.  You will want to keep the contents of the original classes folder, but added to that will be a new folder structure which will contain the newly generated class files needed to interact with the javascript and GWT code.  So, your WEB-INF folder should have a bunch of messages files in it, along with com/konakart/.../.
          -- My recommendation would be to just copy the class files you need into WEB-INF (maintaining the necessary folder structure), and letting the class loader handle using those files.  I know this methodology will work with Tomcat installations, as the WEB-INF/classes location takes precedence over the lib folder.  This also means that you won't need to create/edit any jar files, and will, ostensibly, keep upgrade paths simple in the future, as these class files can be swapped with newer ones.

3.) After copying all new classes and folders to their respective locations, I would advise removing the following two folders, which will make sure that the new classes and such are being used: /<konakart>/temp/ and /<konakart>/work/.

4.) Restart Tomcat.

For me, using a headless Linux install as my KonaKart server, I was not able to completely use the dev shell method outlined in the documentation.  Rebuilding the custom OPC code and copying pertinent class files allowed for fairly easy development and testing.  I hope this helps others who share my general lack of experience and knowledge when it comes to deployment and class-loading mechanisms.  Again, any admins or konakarts, please feel free to update and/or correct my information posted in this thread to help with documentation and others' development.