<개발로그 - 생활 속의 코딩...>
[롬바르디아전용] 가르다랜드 30~70프로 싸게 가는 법
(aka. 오늘도 평화로운 이탈리아 개발일기...)
봄시즌을 맞아 가르다랜드 30~70프로 싸게 가는 법을 공유드리려고 합니다.
https://www.trenord.it/en/giteintreno/relax-fun/gardaland-park/
현재 트레노드에서 프로모션을 하고 있어서 위 링크로 가시면 올해 연말까지 기차 포함해서 인원수 별로 30~70프로까지 할인이 되네요. 표도 3번이나 연기할 수 있어요.
그런데 역시나 뭐하나 쉬운게 없는 이탈리아 답게, 구매 과정에 문제가 있습니다.
(4월 1일부터 프로모션 시작인데,, 아직도 고쳐지지 않은게 참 놀라울 따름입니다...)
그리고 또 안되는건 없다고,, 웹사이트 뜯어서 문제를 해결해보겠습니다.
긴글이 싫으신 분들은 맨 아래 <결론>으로 내려가주세요!
문제정의
문제는 이렇습니다. 분명 gg/mm/aaaa 식으로 날짜를 넣으라 해놓고 BUY 버튼을 클릭하면 구매 페이지로 안넘어갑니다. gg/mm/aaaa 식으로 날짜를 집어넣으라는 에러메세지가 사라지질 않아요. 모바일 문젠가 해서 PC로 해봐도 절대안넘어가더라구요...
이럴 땐 F12버튼으로 웹사이트를 뜯어보면 됩니다.
STEP 1
먼저 1의 콘솔탭을 통해서 로그(웹사이트에서 주는 피드백)를 살펴보겠습니다. BUY 버튼을 누르면 콘솔 탭에 버튼 실행의 결과가 뜨는데요 2의 내용이 그것입니다. 읽어보시면 la data di partenza non e in un formato accettato라고 되어있네요. 포맷이 잘못되었다는 뜻인 것 같습니다.
포맷이 분명 22/05/2023 이런 식으로 넣으라고 했었고 내가 그렇게 넣었는데 포맷이 잘못되었다고 뜬다면, 아마 개발자가 포맷을 22/05/2023 이런 식으로 설정한 게 아닌데 이렇게 넣으라고 했을 가능성이 큽니다. 그럼 개발자가 포맷을 뭐로 설정했는지는 어떻게 알까요? 개발자 도구를 이용해서 페이지의 컴포넌트를 이것 저것 뜯어보아야 합니다.
먼저 날짜를 담고 있는 박스를 보겠습니다. 일단 가장먼저 왼쪽의 엘리먼트 탭을 선택합니다. 1번 버튼으로 선택 모드를 변경하고 2위치에 마우스를 호버한 뒤 클릭하면 해당 섹터에 관여하는 HTML 엘리먼트에 뜹니다. 아래와 같은 부분이 되겠습니다.
<input name="data_di_partenza_1" id="id_data_di_partenza_1" type="text" onchange="aggiorna_post($(this).attr('name'),$(this).val());" placeholder="Travel date format gg/mm/aaaa">
이때 name, id, type 등등은 영역에 관한 특징입니다. placeholder는 아무것도 입력하지 않았을 시 뜨는 문구내용이구요. 중요한 부분은 onchange, 즉 변경사항(날짜입력)에 대해서 어떻게 반응할 것인가 하는 내용입니다.
aggiorna_post($(this).attr('name'),$(this).val()); 복잡해보이지만 큰 틀을 보면 aggiorna_post( A , B ) 이런 구조로 되어있지요. 이게 뭔지는 만든 사람만 알 수 있습니다. 그래서 만든 사람이 어떻게 만들었는지를 보기 위해서 컨트롤+F 버튼을 통해 aggiorna_post를 검색해보겠습니다.
어떻게 만들었는지는 주로 맨 마지막 부분에 나오기 때문에 1부분을 9 of 9까지 내려주세요. 여기서 잘 찾아보면 2번 구역에 aggiorna_post가 있네요! 좀 복잡하게 생겼긴 한데 이름이 복잡해서 그런거라 구조화해보면 간단합니다.
var O = { };
function aggiorna_post( A , B ){
O[A] = B;
console.log(O);
}
즉 aggiorna_post( A , B ) 가 어떻게 동작하냐면
(1) O[A] = B -> O의 A자리에다가 B를 집어넣고
(2) console.log(O) -> 콘솔창에 O를 띄워줘라 는 내용입니다.
(이때 B가 우리가 실제로 입력한 날짜, A는 날짜를 집어넣을 곳 이라고 이해하시면 됩니다. 즉 우리가 입력한 날짜 정보를 O에다가 집어넣는다는 내용입니다.)
STEP 2
박스에 뭘 담고 있든 어찌됐든 오류는 언제 발생하냐하면 우리가 BUY버튼을 눌렀을 때 입니다. (더 정확히는 오류가 발생함으로 인해 아무일도 일어나지 않는 결과가 나타나고 있죠.) 그러면 위해서 날짜를 담고있는 O가 BUY를 눌렀을 때 도대체 어디로 가는 걸까요? 이번에는 앞에서 했던 똑같은 방식으로 BUY 버튼을 뜯어봐야합니다.
<button class="btn bottone-acquista-vetrina-dettaglio btn-block" id="bottone-acquista-vetrina-dettaglio" onclick="invia()">
낯이 익으시다면 프론트개발에 소질이 있으십니다. 앞에서 보았던 엘리먼트와 거의 유사하죠. 차이는 onchange 대신에 onclick이 있네요. 그 말은 이번에는 변경사항이 아니라 "클릭"에 어떻게 반응하는가를 정의하는 부분이 invia()가 되겠습니다.
말안해도 컨트롤+F 버튼을 통해 invia를 검색하고 계시다면 진로를 개발쪽으로 생각해보시기를 권장합니다.. 무튼, 아까 했던 방식으로 똑같이 이번에는 invia()를 찾아보겠습니다.
이번에는 2 of 2 부분에서 조금 내리다보면 이렇게 등장합니다. 또 구조화 시켜보겠습니다.
function invia(){
console.log(X);
if(verifico_informazioni==1){
console.log(X);
if(O != undefined){
...
if(verifica_informazioni( I , J ) === false){
...
}
console.log(X);
if(conferma_acquisto == 0){ //프로세스 거절
if(conferma_acquisto == 1){ //프로세수 실행
console.log는 큰의미가 없었으니까 제외하고, ==와 === 는 같다, !=는 다르다 라고 간단하게 생각하고 보겠습니다.
invia( ) 가 어떻게 동작하냐면 대략 세개의 if 조건을 거칩니다.
(1) if ( verifico_informazioni==1 ) -> 만약 verifico_informazioni이 1과 같고 (안중요하므로 skip)
(2) if ( O != undefined ) -> 아까 위에서 구했던 O 가 undefined와 다르다면 (다른 말로 O가 define 되었다면, 즉 이용자가 O를 생성했다면)
(3) if ( verifica_informazioni( I , J ) === false ) -> verifica_informazioni( I , J ) 와 false가 같다면 (즉 false 라면)
세 조건을 고려해서 최종적으로 이 BUY버튼을 통한 프로세스를 수행시킬지 거부할지가 결정됩니다.
더 간단하게 생각하면 요 세 조건을 만족하면 아래의 코드들이 실행되면서 BUY 버튼이 정상적으로 실행된다고 보면 되겠네요. (실제로는 그거보다 훨씬 복잡합니다.)
그러면 우리가 날짜정보를 입력한 이상 조건 (2)는 별 문제 없이 실행이 될거고, 문제는 (3)에서 일어나겠네요? 그렇다면 verifica_informazioni를 검색해봅니다!! 다와갑니다...!!
STEP 3
여기부터는 내용이 조금 어려워서 핵심만 설명하겠습니다. 실제로 개발자가 포맷을 어떻게 설정해 놓아있는 가에 해당하는 부분입니다.
^(0[1-9]|[12][0-9]|3[01])[-/.](0[1-9]|1[012])[-/.](19|20)\d\d$
위와 같이 표시한 부분은 정규식이라는 내용입니다. 우리가 휴대폰번호를 입력할 때 어떤 형식을 주지 읺으면 사람들은 온갖 이상한 번호를 넣을 수가 있겠죠. 네 가지 예시를 살펴보겠습니다.
010-1234-1234 or 01012341234 or 01012345123456 or 88812341234
이때 웹사이트는 앞의 두 개는 휴대폰 번호로 인식하되 뒤의 두 개는 휴대폰 번호가 아니라고 인식해야 되겠죠? 더 정확히는 첫번째 혹은 두번째로 형식을 통일시켜준 뒤에 사용자에게 알려주어야 이후 일어날 번거로운 수작업 과정을 생략할 수 있어요.
그거처럼 지금이 날짜도 04/06/2023 으로 하든 04.06.2023 으로 하든 04-06-2023으로 하든 년월일 부분만 맞다면 날짜로 인식시키기 위한 과정입니다. 그러니까 여기까지만 해도 큰 문제가 없어요.
그런데 조금 더 내려보면,
여기서는 정규식이 조금 다릅니다.
위에서 빨간색으로 처리한 -./ 중에서 ./는 사라지고 -만 남은게 보이시나요?
/([12]\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]))/ 이렇게 되면 하이픈을 매개로, 그리고 2023-02-04 이런식으로 입력한 값만을 정상값으로 받아들이게 되는거에요.
그런데 맨 처음 화면에 써져있기로는 dd/mm/aaaa 라고 써져있었잖아요? 그러니까 의도한 바 대로 개발을 했다면 하이픈- 이아니라 슬래시/ 를 집어넣어야 했겠죠. 더 정확히는
/(0[1-9]|[12]\d|3[01])/(0[1-9]|1[0-2])/([12]\d{3})/ 이렇게 되는게 맞을 겁니다.
왜그런지는 정규식을 공부해보시면 아실 수 있어요. 참고하실 만한 사이트 달아드립니다.
결론
그러니까 결론은, dd/mm/aaaa 가 아니라 aaaa-mm-dd 형식으로 입력하면 되는 거였습니다. 이탈리아에서 여행한번 가기 쉽지 않네요... 이제 정상적으로 결제가 됩니다 ㅎㅎ
아무튼 정규식에 관한 실수로 인해 발생한 이슈였구요..
우리가 BUY버튼을 누르면 웹상에서는 엄청나게 많은 프로세스가 일어난단 사실을 공유하고 싶었습니다.
그 프로세스의 결과로서, 그게 성공을 한다면 우리에게는 다음 페이지가 보이게 되죠.
간단하게 예를 살펴보았는데요, 실제 일어나는 프로세스의 1%정도를 보셨다고 생각하면 됩니다!
대사관 사이트 관련해서도 오류가 많이 보이던데,.. 이런식으로 뜯어보면 원인정도는 파악할 수 있어요.
무튼 결론은... 웹에서 안되는 건 없습니다.
덧)
개발 외주 업체에 해당 사이트에 정정 요청을 보내놓았는데요... 과연 올해 안에는 읽을려나 모르겠습니다. 정정되면 이 문제도 사라지겠죠! Trenord에 아시는 분이 있으시다면 좀 알려주세요... 한달동안 프로모션 사용자가 없을텐데도 아직 안 고쳐진 이유가 정말로 궁금합니다...
