WPXML2TTXML(워프 백업을 WXR이라고 하니 WXR2TTXML 이라고 할 수 있겠네) 작업을 한창 하고 있는 중이다.
첨부파일 작업만 하면 콘솔 기반으로는 별 문제 없이 1차적으로는 완결이 될 것 같다.
(물론 현재 로깅 - 콘솔로 정보 뿌려주는 것 포함 - 기능이 없어서 어떻게 할까 고려중이었다)
근데, 힘이 빠져서 계속하기가 좀 어려울 것 같다. 그럴만한 이유가 생겼기 때문이다.
첫째, 사용자들의 Needs 와는 정반대의 작업을 하고 있었다.
워드프레스가 대단한 블로그 툴이어서 그런건지 워드프레스에서 태터계열로 이사하려는 사용자들은 찾기 어려운데 태터계열에서 워드프레스로 이사하려는 사용자들은 꽤 있는 것 같다. 즉, 역방향을 원하는 사용자들이 대다수인 것이다.
역방향 이사 툴은 A2 님의 작품이 이미 있고, 쓰기 편하게 워드프레스 플러그인으로 만들어 두신데다가 사용자에게 친숙한 웹 페이지 기반이니, 내가 콘솔 상으로 똑같이 만든다고 해도 A2 님의 작품을 사용하는 것이 당연한 결과이다.
내가 이쪽으로 방향을 선회하는 것은 'reinventing the wheel' 이다.
사실 첫번째 이유는 일찌감찌 인식했었고 고민을 했지만 필요로 하는 소수 사용자가 있을수도 있으니(바램??) 어느정도까지는 계속하려고 했다. 계속하는데 결정적 장벽이 된 것은 아니다.
진짜 문제는 두번째에 있다. 바로 태터 계열의 고유 '치환자' 이다.
태터계열에서 워드프레스로 첨부파일을 옮기는 작업은 어렵지 않다.
첨부파일을 옮길 때 어려운 부분은 '경로가 변경된다' 는 것인데, 로컬에 첨부파일을 직접 써 버리고 그 경로를 치환자를 태그로 변경할 때 사용하면 작업이 완료된다.
치환자가 그 부분만 변경하면 된다는 이정표가 되기 때문에 오히려 작업에 큰 도움이 된다.
정반대의 경우에는 치환자가 상당한 문제가 된다.
좀 더 풀어 말하면, 태터 계열 백업을 복원하면 첨부파일 경로가 확정되지 않는다는 것이 진정한 문제이다.
그러므로, 첨부파일을 표현하기 위해서는 '치환자에 의존해야 한다'.
워드프레스에서 일반 HTML 태그를 써서 링크나 이미지를 띄워놓고 음악, 동영상을 걸어 놓으면 이를 전부 치환자로 변경해야 한다. 모든 태그를 검사하고, 태그가 참조하는 경로가 첨부파일인지 아닌지 일일히 확인해야 한다. 이건 작업이 귀찮을 뿐, 할 만 한 작업이다.
이거 말고 몇 가지 까다로운 점이 있다. 까다로운 정도가 아니라 사실 첨부파일 처리를 거의 불가능하게 만드는 것이다.
일단, 치환자는 표현하는 데 한계가 있다.
예를 들어 문서 첨부파일을 치환자로 표현하면 어떠한 설명도 링크에 붙일 수 없다. 무조건 파일명이 붙은 객체가 글에 첨부된다. 다시 말해, <a href="첨부파일">첨부파일설명</a> 의 구조를 사용할 수 없다.
그러므로 글 내용을 그대로 복원할 수 없다. 임의로 치환자 바깥으로 뺀다거나 해야 하지만 사용자가 원하는 방향인지는 잘 모르겠다. 복원이 깔끔하게 되는 것은 아니므로... 그리고 처리도 엄청나게 복잡해진다.
게다가, 치환자는 태그로 둘러쌓이면 안된다.(이런 경우 해당 글은 복원이 되지 않는다!!)
스타일 태그들에 둘러쌓인 A 태그나 IMG 태그, 혹은 A 태그 내에 포함된 IMG 태그등을 바로 변환할 수 없다. 바깥으로 빼내야 한다. 이것 또한 글 내용을 그대로 복원할 수 없게 만드는 요인이 된다. 물론 처리의 복잡함은 말할 것도 없다.
치환자로 변환하는 데 드는 노력은 상당한데, 그 결과가 '레이아웃이 변경되거나 일부 내용을 제거한 채로 복원' 이라면 그게 정말 메리트가 있는건지...
현재 버전도 워드프레스 계정에 파일이 그대로 존재한다면 링크가 깨지는 일은 없다. 이 쪽이 당연히 이사 전 글 모습에 가깝다. 그래서 더더욱이나 치환자 변환 작업의 메리트가 없다.
하여튼 오늘 필 받아서 하루종일 첨부파일 작업 하다가 치환자에서 막혀 답을 못 찾아서 짜증나고 답답해서 써 본다.
슬슬 취직 걱정도 되어 가고...
다시 도전할 마음이 생기거나, 멋진 답안이 떠오르기 전 까지는 다른 일을 해야겠다.
첨부파일 작업만 하면 콘솔 기반으로는 별 문제 없이 1차적으로는 완결이 될 것 같다.
(물론 현재 로깅 - 콘솔로 정보 뿌려주는 것 포함 - 기능이 없어서 어떻게 할까 고려중이었다)
근데, 힘이 빠져서 계속하기가 좀 어려울 것 같다. 그럴만한 이유가 생겼기 때문이다.
첫째, 사용자들의 Needs 와는 정반대의 작업을 하고 있었다.
워드프레스가 대단한 블로그 툴이어서 그런건지 워드프레스에서 태터계열로 이사하려는 사용자들은 찾기 어려운데 태터계열에서 워드프레스로 이사하려는 사용자들은 꽤 있는 것 같다. 즉, 역방향을 원하는 사용자들이 대다수인 것이다.
역방향 이사 툴은 A2 님의 작품이 이미 있고, 쓰기 편하게 워드프레스 플러그인으로 만들어 두신데다가 사용자에게 친숙한 웹 페이지 기반이니, 내가 콘솔 상으로 똑같이 만든다고 해도 A2 님의 작품을 사용하는 것이 당연한 결과이다.
내가 이쪽으로 방향을 선회하는 것은 'reinventing the wheel' 이다.
사실 첫번째 이유는 일찌감찌 인식했었고 고민을 했지만 필요로 하는 소수 사용자가 있을수도 있으니(바램??) 어느정도까지는 계속하려고 했다. 계속하는데 결정적 장벽이 된 것은 아니다.
진짜 문제는 두번째에 있다. 바로 태터 계열의 고유 '치환자' 이다.
태터계열에서 워드프레스로 첨부파일을 옮기는 작업은 어렵지 않다.
첨부파일을 옮길 때 어려운 부분은 '경로가 변경된다' 는 것인데, 로컬에 첨부파일을 직접 써 버리고 그 경로를 치환자를 태그로 변경할 때 사용하면 작업이 완료된다.
치환자가 그 부분만 변경하면 된다는 이정표가 되기 때문에 오히려 작업에 큰 도움이 된다.
정반대의 경우에는 치환자가 상당한 문제가 된다.
좀 더 풀어 말하면, 태터 계열 백업을 복원하면 첨부파일 경로가 확정되지 않는다는 것이 진정한 문제이다.
그러므로, 첨부파일을 표현하기 위해서는 '치환자에 의존해야 한다'.
워드프레스에서 일반 HTML 태그를 써서 링크나 이미지를 띄워놓고 음악, 동영상을 걸어 놓으면 이를 전부 치환자로 변경해야 한다. 모든 태그를 검사하고, 태그가 참조하는 경로가 첨부파일인지 아닌지 일일히 확인해야 한다. 이건 작업이 귀찮을 뿐, 할 만 한 작업이다.
이거 말고 몇 가지 까다로운 점이 있다. 까다로운 정도가 아니라 사실 첨부파일 처리를 거의 불가능하게 만드는 것이다.
일단, 치환자는 표현하는 데 한계가 있다.
예를 들어 문서 첨부파일을 치환자로 표현하면 어떠한 설명도 링크에 붙일 수 없다. 무조건 파일명이 붙은 객체가 글에 첨부된다. 다시 말해, <a href="첨부파일">첨부파일설명</a> 의 구조를 사용할 수 없다.
그러므로 글 내용을 그대로 복원할 수 없다. 임의로 치환자 바깥으로 뺀다거나 해야 하지만 사용자가 원하는 방향인지는 잘 모르겠다. 복원이 깔끔하게 되는 것은 아니므로... 그리고 처리도 엄청나게 복잡해진다.
게다가, 치환자는 태그로 둘러쌓이면 안된다.(이런 경우 해당 글은 복원이 되지 않는다!!)
스타일 태그들에 둘러쌓인 A 태그나 IMG 태그, 혹은 A 태그 내에 포함된 IMG 태그등을 바로 변환할 수 없다. 바깥으로 빼내야 한다. 이것 또한 글 내용을 그대로 복원할 수 없게 만드는 요인이 된다. 물론 처리의 복잡함은 말할 것도 없다.
치환자로 변환하는 데 드는 노력은 상당한데, 그 결과가 '레이아웃이 변경되거나 일부 내용을 제거한 채로 복원' 이라면 그게 정말 메리트가 있는건지...
현재 버전도 워드프레스 계정에 파일이 그대로 존재한다면 링크가 깨지는 일은 없다. 이 쪽이 당연히 이사 전 글 모습에 가깝다. 그래서 더더욱이나 치환자 변환 작업의 메리트가 없다.
하여튼 오늘 필 받아서 하루종일 첨부파일 작업 하다가 치환자에서 막혀 답을 못 찾아서 짜증나고 답답해서 써 본다.
슬슬 취직 걱정도 되어 가고...
다시 도전할 마음이 생기거나, 멋진 답안이 떠오르기 전 까지는 다른 일을 해야겠다.
'Dev.Think' 카테고리의 다른 글
| 201X 년 나의 일상(미래의 하루 묘사) (2) | 2009/06/09 |
|---|---|
| 개발자의 가치관? 이미지? (2) | 2009/05/03 |
| WPXML2TTXML 작업 무기한 연기 (0) | 2009/04/20 |
| 소프트웨어 기술자 신고제... 이걸 정말 시행한다고? (3) | 2009/02/13 |
| 블로그 재설치... (4) | 2009/01/29 |
| Ruby 공부 시작... (0) | 2009/01/29 |
