하찮은 웹개발자의 메모장

VO를 통해 Data를 관리하는 경우 Mybatis 설정 한줄이면 충분하다.

<settings>
	<setting name="mapUnderscoreToCamelCase" value="true"></setting>
</settings>

그러나 취향 또는 인계받은 프로젝트가 Map 의 형태로 구현된 경우 

Camel Case 처리가 귀찮을 수 있다.

나는 아래와 같이 커스텀맵을 만들어 처리를 하는 편이다.

import java.util.HashMap;

import org.springframework.jdbc.support.JdbcUtils;

@SuppressWarnings("serial")
public class CustomMap extends HashMap<String, Object> {

    @Override
    public Object put(String key, Object value) {
        return super.put(JdbcUtils.convertUnderscoreNameToPropertyName(key), value);
    }
    
}

나의 경우 HashMap의 제네릭을 String, Object로 고정시켜 두었기때문에

key값을 캐스팅해줄 필요가 없지만. 제네릭을 다르게한다면 캐스팅 처리가 필요할 것임.

부작용으로 위의 CustomMap을 RequestBody에도 사용하게되면

parameter name이 View에서 전달한 값과 다를 수 있음

public static String paramToQueryString(Map<String, Object> paramMap){
	List<NameValuePair> params = Lists.newArrayList();
	if(paramMap != null){
		for(Entry<String, Object> paramEntry : paramMap.entrySet()){
			Object value = paramEntry.getValue();
			if(value != null){
				params.add(new BasicNameValuePair(paramEntry.getKey(), value.toString()));
			}
		}
	}
	return URLEncodedUtils.format(params, "UTF-8");
}

import java.util.HashMap;

import java.util.List;

import java.util.Map;

import java.util.Map.Entry;

import org.apache.http.NameValuePair;

import org.apache.http.message.BasicNameValuePair;

//아래 둘중 어떤걸 써도 사용가능.

import org.apache.commons.compress.utils.Lists;

//import com.google.common.collect.Lists;

import org.apache.http.client.utils.URLEncodedUtils;

-------------------------------------------------------------------------------------

Server단에서 URLConnection 사용시 

Method 가 GET이어도 Body에 Parameter를 포함할 경우 POST로 자동변환되므로

GET 방식으로 Parameter 던질때 사용하기 위해 작성...

-------------------------------------------------------------------------------------

2022-04-18 추가

무슨생각으로 그랬는지 모르겠지만

List<NameValuePair> params = Lists.newArrayList();

이 부분은

List<NameValuePair> params = new ArrayList<>();

이렇게 치환해도 문제없음...

고객중에는 게시판 페이지 네비게이션 으로 이동시 ( 게시판 하단 1페이지 2페이지... 하는것들)

화면이 깜빡이는 것(페이지가 이동되는 액션)을 

극혐하는 고객들이 있다.

그럴때는 비동기로 데이터를 불러와 화면을 그리는데 요즘은 뷰인지 리액트인지 여러 기술들이있지만

그냥 javascript 든 jquery 로든 HTML을  그리는 경우도 있다.

요점은 그것이 아니고 해당 방식으로 그릴때 브라우저의 뒤로가기 기능이

일반 사람들의 논리와는 맞지않게 작동한다

웹 개발자는 당연히 페이지 이동이 일어난게 아니니 뒤로가기면

페이지 네비게이션으로 이동한 페이지가 아닌(게시판이 아닌) 화면으로 이동한다고 생각하지만

고객(일반인)은 당연히 해당 게시판내에서 페이지 번호가 이동해야한다고 생각한다.

어느정도 웹개발에 몸담은사람들은 다들 경험한 일일 것이다.

또한 해당 게시판의 x번째 페이지에 xx번 게시물을 클릭하여 이동했다가 브라우저 뒤로가기를 누르면 

마찬가지로 이전 페이지는 x번째 페이지가 아닌 Page가 Init 된상태 즉 1페이지를 바라보고 있을것이다.

해당 이슈는 호랑이 담배피던 시절부터 있던 이슈이며 모든 개발자들이 나름의 해결 방법을 만들어서

사용하고있다. 아래의 코드는 최근 프로젝트에서 정리한 버전이며 정답이 아니다.

내가 가끔 다시 생각할 수있게 기록을 남기는 것임.

/**
* 2020-02-26
* Page Init Painting HTML Logic
* Call Function Name paintHTML

// paintHTML (AJAX CALL 함수든 뭐든 결과적으로 HTML을 그리는 function)

// Browser Back Event Bind
// on > bind 변경가능
$(windows).on('popstate', function(){
	// History Check
	var hstate = history.state;
	if(hstate != null && hstate.formData) {
		// History 가 있을 경우 해당 FromData 로  HTML Paint
		paintHTML(hstate.formData);
	}else{
		// History 가 없는 경우 Browser Back 기능
		history.back(); // or history.go(-1);
	}
});


// Page Init 시에 사용할 Function
// ex)
// $(document).ready(function(){
//      initPaintHTML();
// });
// parameter : initFormData > 초기 Init 시에 필요한 FormData 가 있는경우 사용
function initPaintHTML(initFormData){
	// History Check
	var hstate = history.state;
	if(hstate != null && hstate.formData){
		// History 있는경우 해당 FromData 로 Paint
		paintHTML(hstate.formData);
	}else{
		// History 없는경우 받은 FromData 로 Paint
		paintHTML(initFormData);
		// History Stack
		if(initFormData){
			history.pushState({'formData' : initFormData}, null, '');
		}else{
			history.pushState({'formData' : 'initPage'}, null, '');
		}
	}
}

// 아래의 코드를 Page Navigation Function 내 추가 필수
// Page Navigation Action > History Stack (pushState)
history.pushState({'formData' : formData}, null, '');