PrimeFaces: working with big dialogs

I've come across a problem with PrimeFaces dialogs, when those dialogs contained elements which could expand, such as data grids. When those dialogs were bigger than the document itself, you could run into situation where the close button was unreachable and the user could only refresh page and lose all data.

The problem is that the dialog are not added to the main element, but are displayed as position:fixed. It means, that even if the scroll is available, the dialog itself won't be scrolled. That kind of positioning is working quite good with small dialogs, which are displayed only in the middle of window, but for big dialogs this is disaster. I didn't want to change that behaviour for small dialogs, for which it was working fine.

As a solution, I've created a JavaScript snippet, that checks if the dialog can fit the screen. If it is too big, the document is expanded and the dialog positioning is changed to absolute, so that the browser window scroll is displayed and each region of dialog can be visited. The position of dialog is also checked, to prevent the situation, where the dialog is displayed in unreachable region of window (this can happen, if you change the size of the browser after hiding the dialog.

This solution isn't perfect, it could be improved to react dynamically on window resize, for example, but this is fixing the main issue with too big dialogs on too small screens.

Any comments are welcomed.

function handleResizeDialog(dialog) {
    var el = $(dialog.jqId);
    var doc = $('body');
    var win = $(window);
    var elPos = '';
    var bodyHeight = '';
    var bodyWidth = '';
    // position:fixed is maybe cool, but it makes the dialog not scrollable on browser level, even if document is big enough
    if (el.height() > win.height()) {
        bodyHeight = el.height() + 'px';
        elPos = 'absolute';
    }   
    if (el.width() > win.width()) {
        bodyWidth = el.width() + 'px';
        elPos = 'absolute';
    }
    el.css('position', elPos);
    doc.css('width', bodyWidth);
    doc.css('height', bodyHeight);
    var pos = el.offset();
    if (pos.top + el.height() > doc.height())
        pos.top = doc.height() - el.height();
    if (pos.left + el.width() > doc.width())
        pos.left = doc.width() - el.width();
    var offsetX = 0;
    var offsetY = 0;
    if (elPos != 'absolute') {
        offsetX = $(window).scrollLeft();
        offsetY = $(window).scrollTop();
    }
    // scroll fix for position fixed
    if (pos.left < offsetX)
        pos.left = offsetX;
    if (pos.top < offsetY)
        pos.top = offsetY;
    el.offset(pos);
}

The Ten Happiest Jobs - Forbes - why IT jobs are hated?

I've found recently the following article:
The Ten Happiest Jobs - Forbes

What can be for some people suprising, ont the list of the most hated jobs are many IT jobs: web developer, technical specialist, IT director... Because of high salary this jobs are seen by many as the dream job, however for this big money a high price is to be paid.

This jobs are very stressful and you spend usually the whole day sitting at the desk and starring at the screen, which is both disastrous for health and eyes. IT specialists are usually very creative people, which wish to create something new and important, and unfortunatelly most of IT jobs is doing task which requires copypasterism and reading documentation about magic switches in someone's magic framework that doing something creative and innovative. This is mostly visible in web frameworks, where there are very many things written and most of the job is configuring and modifying someone's job. DB developers are in better position.

Exporting contacts to gmail

Google claims Gmail can import contacts from various programs, which is working because they accept 'various common names' for data fields. However, when I've wanted to import contacts from Excel spreadsheet, I've found out that it isn't as easy as it should.

I've named fields according to 'common sense' notation: first name, last name, name, e-mail, phone. E-mail got imported, name also, but other fields where added to 'notes'. I've tried to google out to which names the import react but I've found no tip. It seems that Google simply have implemented support for various popular formats, so if you want to prepare your own CVS file, you should apply to one of this formats. I've gone this way, using Gmail contacts export format. E-mail fields is named "E-Mail 1 - Value", phone - "Phone 1 - Value" (you can use numbers from 1 to 3). Additionally you need to specify e-mail and phone type: "Mobile" for cellular phone, "Other" for other, "Home" for 'home' email.

First I've formatted in such way the phone and it got imported. But when I've formatted e-mail, e-mail got imported, but not the phone. What was the cause? I was specifying value first, then type, and it seems google's import mechanism needs a bit stricter format. So finally, the works-for-me solution was:

• Given Name - the first name
• Family Name - the surname
• Name - the displayed name
• E-Mail 1 - Type - "Home" (or "Other")
• E-Mail 1 - Value - e-mail
• Phone 1 - Type - "Mobile"
• Phone 1 - Value - phone number
• Notes - additional info about contact