Client-side source vs Server-side source

I am new to Vaadin and Web development.

Referring your demo application, AddressBook, how do I know which part of java code is running in on client-side (within a browser) and which part of java code is running on server-side (within web server)?

Thanks,

Hi,

Basically, if you haven’t written a Vaadin widget - and for the Address Book demo, you haven’t - all of your code is running on the server side.

Cheers,

Charles.

Thanks for your reply, Charles.

Follow up question:

  1. If all is running on the server-side, then how usually people implement the client-side simple validation such as “number only” or “string only” etc?

  2. If we want to implement our login form using com.vaadin.ui.LoginForm and LoginForm.LoginListener is going to be executed on the server-side, then will the password travel to the server-side as encrypted or un-encrypted?

  3. If LoginForm’s password travel as un-encypted, would creating a custom Vaadin widget (including our own encryption logic) be the best idea? or do you have any other suggestions?

Sorry for many questions…

Thanks,
Jennifer.

Hi,

  1. They either write their own widgets, or re-use others from the
    Vaadin Directory
    . Note that if you want very fine control about what happens on the client and what happens on the server, then you’re probably looking at the wrong framework. You can do that - but one of the major points about Vaadin is that you can not care. In terms of validation, you can easily validate on the server with no problems. If you want to prevent invalid data as it is entered on the client side (e.g. stopping alpha characters in numerics) without talking to the server, you’ll probably want your own widgets (or to use something like the
    CSValidation add on

  2. If you’re using https for the browser (i.e. https://yourdomain/your-app) then it’s encrypted. If not, then not.

  3. I would suggest using using https : ensure that everything is encrypted between the client and the server, and needs no special development (it’s all handled by the browser and application server, e.g. tomcat). Failing that, you can of course create a widget that hashes the password in the browser and simply sends the hash to the server.

Cheers,

Charles.

Thank you for the clear explanation, Charles.