DB에 접근하기 위해서 트랜잭션은 필수적이다.

그 이유는 예를 들어 한 행을 삽입하는데 그에 대한 각각의 테이블에 각각의 행들이 삽입이 되어 지는 경우를 생각해보자.

만약 한 행이 삽입되는 중 error를 뱉어 낸다면, 처음부터 그 중간점부터 행을 삽입 할 수 없으므로 처음부터 다시 실행해야한다.

하지만 이미 어느 테이블에는 데이터가 들어가 있을 것이고,

어느 테이블에는 데이터가 들어가있지 않게 되므로 데이터 관계의 오류가 생기게된다.

따라서 이 쿼리문들은 하나의 쿼리문 처럼 실행이 되어야한다.

성공하면 전체가 성공(commit)해야하고 실패하면 전체가 실패(rollback) 해야한다.


이를 위해서 트랜잭션이 필요하다.


트랜잭션을 이용한 방법은 aop를 이용한 방법과 @Transactional을 이용한 방법 2가지가 존재한다.

여기서는 @Transactional을 이용한 방법에 대해 알아보도록 하자.


사용방법은 아래와 같다


1. context에

xmlns:tx="http://www.springframework.org/schema/tx" 추가한다.


2. context에

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
     <property name="dataSource" ref="dataSource"/>
</bean>

을 추가하여 transaction을 관리하기 위한 bean을 선언을 한다.


그 후 <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/>
 를 추가 하여 @Transactioal annotaion 한 곳을 찾는다.


3. 원하는 메소드, 클래스에 @Transactional 어노테이션 추가한다.


예를 들어보자

게시판에서 하나의 글이 삭제된다면, 관련 댓글, 첨부파일이 함께 삭제되어야 한다.

따라서 아래와 같이 작성해 주었다.


@Transactional
@Override
public void DeleteBoard(int cd_post) throws Exception {
    // TODO Auto-generated method stub
    sampleDao.DeleteBoard(cd_post);
    sampleDao.DeleteFile(cd_post);
    commentDao.DeleteCommentAll(cd_post);
}


'Programming > Spring' 카테고리의 다른 글

스프링 컨테이너?  (0) 2018.05.14
POJO  (0) 2018.05.14
AspectJ Aop설정방법  (0) 2018.05.14
spring 사용이유?  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13

컨테이너란?

Servlet 컨테이너, EJB 컨테이너와 같은 컨테이너는 보통 인스턴스의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능을 제공하도록하는 것이다.

컨테이너란 작성한 코드의 처리과정을 위임받은 독립적인 존재라고 생각하면 된다.

컨테이너는 적절한 설정만 되어있다면 프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 컨트롤해준다.
(이를 IOC라 한다.)

Servlet 컨테이너는 Servlet의 생성, 생성 후 초기화, 서비스 실행, 소멸에 관한 모든 권한을 가지고 있다.

따라서 개발자들이 직접 Servlet을 생성하고 서비스하지는 않는다.

이처럼 Servlet 인스턴스에 대한 생명주기를 관리하는 기능을 가진다.

또한, Servlet 컨테이너의 web.xml을 보면 Servlet의 구현과는 별도로 각 JSP/Servlet에 대한 Security를 관리해주는 기능을 한다.


 스프링 컨테이너는 스프링 프레임워크의 핵심부에 위치하며, 종속객체 주입을 이용하여 애플리케이션을 구성하는 컴포넌트들을 관리한다.

스프링 컨테이너의 두 종류

1. 빈팩토리 BeanFactory (org.springframework.beans.factory.BeanFactory)

DI의 기본사항을 제공하는 가장 단순한 컨테이너

팩토리 디자인 패턴을 구현한 것. Bean(이하 빈) 팩토리는 빈을 생성하고 분배하는 책임을 지는 클래스

빈 팩토리가 빈의 정의는 즉시 로딩하는 반면, 빈 자체가 필요하게 되기 전까지는 인스턴스화를 하지 않는다 (lazy loading, 게으른 호출)


getBean()이 호출되면, 팩토리는 의존성 주입을 이용해 빈을 인스턴스화하고 빈의 특성을 설정하기 시작. 여기서 빈의 일생이 시작된다.


 BeanFactory factory = new XmlBeanFactory(new FileInputStream("bean.xml"));

 MyBean myBean = (Mybean) factory.getBean("myBean");


2. 어플리케이션 컨텍스트 ApplicationContext (org.springframework.context.factory.BeanFactory)


빈팩토리와 유사한 기능을 제공하지만 좀 더 많은 기능을 제공하는 어플리케이션 컨텍스트


빈팩토리보다 더 추가적으로 제공하는 기능

    국제화가 지원되는 텍스트 메시지를 관리해 준다.
    이미지같은 파일 자원을 로드 할 수 있는 포괄적인 방법을 제공해준다.
    리너스로 등록된 빈에게 이벤트 발생을 알려준다.

따라서 대부분의 애플리케이션에서는 빈팩토리보다는 어플리케이션 컨텍스트를 사용하는 것이 좋다.


가장 많이 사용되는 어플리케이션 컨텍스트 구현체

ClassPathXmlApplicationContext : 클래스패스에 위치한 xml 파일에서 컨텐스트 정의 내용을 읽어들인다.
FileSystemxmlApplicationContext : 파일 경로로 지정된 xml 파일에서 컨텐스트 정의 내용을 읽어들인다.
XmlWebApplicationContext : 웹 어플리케이션에 포함된 xml 파일에서 컨텐스트 정의 내용을 읽어들인다.




 ApplicationContext context = new ClassPathXmlApplicationContext("conf/bean.xml");

 MyBean bean = context.getBean("myBean");

 
빈 팩토리와 애플리케이션컨텍스트의 기능상의 차이점 말고 또 다른 차이점은 다음과 같다.

빈 팩토리 : 처음으로 getBean()이 호출된 시점에서야 해당 빈을 생성(lazy loading)

애플리케이션 컨텍스트 : 컨텍스트 초기화 시점에 모든 싱글톤 빈을 미리 로드한 후 애플리케이션 기동 후에는 빈을 지연 없이 얻을 수 있음(미리 빈을 생성해 놓아 빈이 필요할 때 즉시 사용할 수 있도록 보장)


출처: http://limmmee.tistory.com/13 [심플하게 개발]

'Programming > Spring' 카테고리의 다른 글

@Transactional  (0) 2018.05.15
POJO  (0) 2018.05.14
AspectJ Aop설정방법  (0) 2018.05.14
spring 사용이유?  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13

POJO (Plain Old Java Object)


POJO (Plain Old Java Object) 란 번역하면 '평범한 구식 자바 객체'이다. 도대체 평범하고 구식인 자바 오프젝트가 뭐가 다르고 특별해서 POJO라고 부르는 것일까? 그럼 평범하지 않은 최신의 자바 오브젝트는 무엇인가?

POJO를 이해하려면 POJO라는 단어가 만들어진 역사적 배경을 살펴볼 필요가 있다. POJO는 마틴 파울러가 2000년 가을에 열렸던 어느 컨퍼런스의 발표를 준비하면서 처음 만들어낸 말이다. 마틴 파울러는 EJB(Enterprise JavaBean)보다는 단순한 자바 오브젝트에 도메인 로직을 넣어 사용하는 것이 여러가지 장점이 있는데 왜 사람들이 EJB가 아닌 '평범한 자바 오브젝트'를 사용하기를 꺼려하는지에 대해 의문을 가졌다. 그리고 그는 단순한 오브젝트에는 EJB와 같은 그럴듯한 이름이 없어서 그 사용을 주저하는 것이라고 결론을 내렸고, POJO라는 용어를 만들었다.


EJB와 엔터프라이즈 서비스

자바에서 EJB 기술의 등장은 필연적인 것이었다. 기업의 IT 시스템은 점점 그 중요성이 증대되고 그에 따라 점점 기술이 요구되었으며 자바의 기초적인 JDK만으로는 그것을 충족시킬 수 없었다. 서버 기반의 자바 기술인 J2EE(Java2 Enterprise Edition)가 등장했지만 Servlet, JSP 레벨의 최소한의 서버 프로그래밍 인터페이스만 가지고는 복잡한 엔터프라이즈 애플리케이션을 제작하는데 부담이 적지 않았다.

기업업무처리의 IT시스템에 대한 의존도가 높아지면서 시스템이 다뤄야 하는 비즈니스 로직 자체가 점차 복잡해졌다. 애플리케이션 로직의 복잡도와 상세 기술의 복잡함을 개발자들이 한 번에 다룬다는 것은 쉬운일이 아니었다. 예를 들어, 한 개발자가 보험업무와 관련된 계산 로직을 자바로 어떻게 구현해야 하는지에 집중하면서 동시에 시스템 레벨에서 멀티 DB로 확장 가능한 트랙잭션 처리와 보안 기능을 멀티스레드에 세이프하게 만드는 것에 신경써야한다면 여간 부담되는게 아닐 것이다.
많은 사용자의 처리요구를 빠르게 안정적이면서 확장 가능한 형태로 유지하기위해 필요한 로우레벨의 기술적인(트랜젝션 처리, 상태관리, 멀티쓰레딩, 리소스풀링, 보안등) 처리가 요구되었다.

EJB는 이런 문제를 다루기 위해 등장했다. 


(EJB는 대규모 분산 객체 시스템을 구축하기 위한 기술 또는 자바로 서버 측 비즈니스 로직을 작성하기 위한 Enterprise 환경에서의 자바 표준이다. 만약, EJB를 사용하기 위해 웹로직 서버를 이용한다고 하면 프로그램 개발자는 웹로직 서버의 컨테이너를 이용하여 작업을 하게 되는데 이는 트랜잭션의 지원, 보안, 동시 접근 처리 등 비즈니스 로직을 처리하는데 있어 필요한 모든 것을 제공 한다. EJB는 엔티티빈, 메시지 드리븐 빈, 상태유지 세션 빈, 비상태유지 세션 빈등 4가지의 타입이 있다.)


EJB 1.0의 스펙이 제시한 EJB의 비전은 'EJB는 애플리케이션 개발을 쉽게 만들어준다. 애플리케이션 개발자는 로우레벨의 기술들에 관심을 가질 필요도 없다.' 였다. 애플리케이션 개발자들은 다뤄야하는 해당 도메인과 비즈니스 로직에만 집중하면 된다는 것이다. 게다가 EJB는 독립적으로 개발한 컴포넌트들을 서버에 자유롭게 배포하고 서로 연동해 사용하게하는 컴포넌트 기반의 개발 모델을 제시할 뿐더러, 여러 대의 서버에 분산되어있는 모듈간의 리모팅 처리도 개발자들이 거의 신경쓰지 않고 개발 할 수 있게 했다. 더 나아가 벤더별로 제각각 발전시켜 혼란에 빠지기 쉬운 자바의 서버 기술을 일관성있게 구현할 수 있도록 지원하므로 특정 서버에 종속되지 않고 서버간의 이동성을 보장해준다고 약속했다.

그러나, EJB는 불필요할만큼 과도한 엔지니어링으로 실패한 대표적인 케이스였다.

EJB에서는 현실에서 1% 미만의 애플리케이션에서만 필요한 멀티 DB를 분산 트랜잭션을 위해 나머지 99%의 애플리케이션에서도 무거운 JTA기반의 글로벌 트랙잰션 관리 기능을 사용해야 했다. EJB의 혜택을 얻기 위해 모든 기능이 다 필요하지도 않은 고가의 WAS를 구입해야했고, 고급 IDE(Intergrated Development Environment)의 도움없이는 손쉽게 다룰 수 없는 복잡한 설정 파일 속에서 허우적대야 했다. EJB 컴포넌트는 컨테이너 밖에서는 정상적으로 동작할 수 없으므로 개발자들은 끝도없이 반복되는 수정-빌드-배포-테스트의 지루한 과정으로 많은 시간을 낭비해야했다. 가장 최악의 문제점은 EJB 스펙을 따르는 비즈니스 오브젝트들은 객체지향적인 특징과 장점을 포기해야했다는 것이다. 또한, EJB빈은 상속과 다형성등의 혜택을 제대로 누릴 수 없었다.

그럼에도 EJB가 계속 사용되었던 이유는, 엔터프라이즈 애플리케이션에서 반드시 필요로하는 주요한 엔터프라이즈 서비스들을 애플리케이션 코드와 분리해서 독립적인 서비스로 사용할 수 있게 만들어줬다는 점이다. 비록 불완전하고 불필요한 복잡도가 남아있긴 했지만 선언적인 트랜잭션 관리나 역할 기반의 보안 기능들을 제공했다. 한편으로는 '개발자들이 로우레벨의 기술적인 문제에 신경쓰지 않고 비즈니스 로직에 충실히 개발하게 함으로써 애플리케이션 개발을 손쉽게 만들어 준다'는 처음 약속을 어느 정도 지켰다고 볼 수 있었다. 하지만 EJB 문제는 앞서 지적한 것처럼 한편으로는 애플리케이션 개발의 복잡도를 제거하면서 다른 한편으로는 더 많은 문제와 복잡성을 가지고 왔다는 것이다.

결국 EJB는 형편없는 생산성과 느린 성능, 불필요한 기술적인 복잡도등으로 자반의 엔터프라이즈 개발에 대한 불신을 가중시켰다. 마틴 파울러는 EJB와 같은 잘못 설계된 과도한 기술을 피하고, 객체지향 원리에 따라 만들어진 자바 언어의 기본에 충실하게 비즈니스 로직을 구현하는 일명 POJO 방식으로 돌아서야 한다고 지적했다. POJO 방식의 개발은 EJB가 잃어버린 소중한 가치인 객체지향적인 설계와 자동화된 테스트의 편의성, 개발생산성 등을 회복시켜 줄 수 있는 길이기 때문이다.


결국 POJO를 정리하자면,


특정 규약(contract)에 종속되지 않는다. (Java 언어와 꼭 필요한 API 외에 종속되지 않는다.)
특정 환경에 종속되지 않는다.
객체지향원리에 충실해야 한다.

POJO를 사용하는 이유

코드의 간결함 (비즈니스 로직과 특정 환경/low 레벨 종속적인 코드를 분리하므로 단순하다.)
자동화 테스트에 유리 (환경 종속적인 코드는 자동화 테스트가 어렵지만, POJO는 테스트가 매우 유연하다.
객체지향적 설계의 자유로운 사용이 가능하다

앞에서 강조한것처럼 EJB를 사용하지 말고 POJO를 쓰자는 것이 EJB 이전의 방식으로 돌아가는 것을 의미한다면 또 다른 문제가 발생할 수밖에 없다. 여전히 복잡한 로우레벨의 API를 이용해 코드를 작성해야하고, 많은 기술적인 문제를 애플리케이션 코드에 그대로 노출시켜 개발해야 한다면 기껏 POJO로의 복귀 덕분에 얻은 많은 장점을 놓칠 수 밖에 없다. 그래서 등장한 것이 바로 POJO 기반의 프레임워크이다.

POJO 프레임워크

POJO를 이용한 애플리케이션 개발이 가진 특징과 장점을 그대로 살리면서 EJB에서 제공하는 엔터프라이즈 서비스와 기술을 그대로 사용할 수 있도록 도와주는 프레임워크, 나아가 기존의 EJB에서보다 훨씬 더 세련되고 나은 방법을 제공한다.
(많은 POJO 프레임워크가 있지만 그 중에서 가장 대표적인 것을 꼽으라면 하이버네이트와 스프링을 들 수 있다.)

스프링 프레임워크

스프링 : POJO 프레임워크 중 하나이며, 자바 애플리케이션 개발을 위한 포괄적인 인프라를 제공하는 자바 플랫폼이다.
스프링을 사용하면 POJO로 어플리케이션을 만들고 엔터프라이즈 서비스를 비침투적으로 POJO에 적용할 수 있다.


스프링 플랫폼의 이점에 대한 예제

트랜잭션 API를 사용하지 않고도 데이터베이스 트랜잭션에서 자바메소드를 실행하도록 만든다.
원격 API를 사용하지 않고도 로컬 자바메소드를 원격 프로시저로 만든다
JMS API를 사용하지 않고도 로컬 자바메소드를 메시지 핸들러로 만든다.



출처 : http://limmmee.tistory.com/m/8?category=654011

        http://iamreo.tistory.com/entry/EJB간략개요 [흔적s]

'Programming > Spring' 카테고리의 다른 글

@Transactional  (0) 2018.05.15
스프링 컨테이너?  (0) 2018.05.14
AspectJ Aop설정방법  (0) 2018.05.14
spring 사용이유?  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13

스프링의 프록시 AOP 대신 AOP 전용 프레임워크인 AspectJ의 AOP를 사용할 수 있다. 

AspectJ AOP는 스프링과 달리 프록시를 타깃 오브젝트 앞에 두지 않는다. 

대신 타깃 오브젝트 자체를 조작해서 부가기능을 직접 넣는 방식이다. 

마치 처음부터 타깃 오브젝트의 클래스에 부가기능을 가진 소스코드가 있었던 것처럼 만들어 준다. 

메소드 실행 지점만 조인 포인트로 사용할 수 있는 프록시 방식의 스프링 AOP에서는 불가능한 다양한 조인 포인트와 고급 기능을 이용할 수 있다. 

대신 별도의 빌드 과정이나 바이트코드 조작을 위한 로드타임 위버 설정과 같은 부가적인 작업(Weaving)이 필요하다.



pom.xml에 AspectJ를 설정한다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<!-- AspectJ -->
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjrt</artifactId>
    <version>${org.aspectj-version}</version>
</dependency>    
 
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjweaver</artifactId>
    <version>${org.aspectj-version}</version>
</dependency>
 
<dependency>
    <groupId>org.aspectj</groupId>
    <artifactId>aspectjtools</artifactId>
    <version>${org.aspectj-version}</version>
</dependency>
cs



root-context.xml에 aspectj를 설정해준다. 


1
2
<aop:aspectj-autoproxy/
<bean id="loggerAspect" class="com.(...).LoggerAspect" />
cs


이때, bean으로 등록 해주어야 하는데 이는 component-scan을 할때 stereo type중에 AspectJ는 없기 때문에 component-scan에 걸리지 않게 된다. 

그러므로 bean을 따로 등록 해주어야 한다.



이제 클래스를 정의해주고 설정을 해주기만 하면된다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@Aspect
public class LoggerAspect {
    protected Logger log = LoggerFactory.getLogger(LoggerAspect.class);
    
    @Pointcut("execution(* com..Controller.*Controller.*(..))")
    public void pointCut() {}
    
    @Before
    
    @After
    
    @Around("pointCut()")
    public Object logPrint(ProceedingJoinPoint joinPoint) throws Throwable {
        String type = joinPoint.getSignature().getDeclaringTypeName();
        String name = "";
     
        if (type.indexOf("Controller"> -1) {
            name = "Controller  \t:  ";
        }
        log.debug(name + type + "." + joinPoint.getSignature().getName() + "()");
        return joinPoint.proceed();
    }
 
}
cs



사용하고자 하는 클래스에 @Aspect를 설정한다.


@Pointcut을 사용하여 적용할 클래스 경로를 설정한다.




@Before/ @After / @Around

Pointcut이 실행될 시점을 정한다.

@Before : Pointcut실행되기 이전

@After : Pointcut실행되기 이후

@Around : 둘다




@Before/ @After / @Around시점에 해당하는 객체를 JoinPoint객체로 받아온다.


JoinPoint객체안에서 원하는 값을 뽑아와서 AOP에 필요한 항목을 검사하거나 원하는 로직을 실행시킨다.


return joinPoint.proceed();으로 joinPoint객체를 리턴시킨다.

'Programming > Spring' 카테고리의 다른 글

스프링 컨테이너?  (0) 2018.05.14
POJO  (0) 2018.05.14
spring 사용이유?  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13
jstl 간단 사용법  (0) 2018.05.13

1. DI(의존성주입), IoC(제어 역전)

보통 클래스 내부에서 new 로 객체의 인스턴스를 받아서 사용하는 방식은 모듈간의 강한결합을 불러오기 때문에, 변경이나 확장 등에서 자유롭지 못하다.


하지만 생성자, setter 등으로 외부에서(IoC) 생성된 객체의 인스턴스를 받아서 사용만(DI)하는 구조로 개발을 해 놓으면 변경이 있을때 해당하는 부분의 클래스만 변경이 가능하다.

2. AOP

자바는 하나의 클래스에 대한 수직적인 흐름만 제어할 수 있는 반면 스프링을 쓰면 특정 클래스들에 대한 수평적인 제어가 가능해 진다. 가령 *Controller.do 패턴이 들어오면 전처리로 A 빈 클래스를 실행하라는 선언이 가능하다. 수직적인 제어로 불완전 했던 Java 가 스프링을 만나며 수직, 수평 제어 모두 가능하게 되었습니다.



이를 위해서 IOC 컨테이너가 이미 다 구현해 놓았다. 그렇기 때문에 Spring은 개발하기 편한 환경을 제공해 준다.


<결론>

스프링이 IoC를 실현하는 방법으로 대표적인 것이 그 유명한 DI와 AOP가 있으며, 우리 개발자가 할 일은 스프링이 관리할 것들에 대한 메타정보만 작성해서 주면 되고, 나머지 시간은 비즈니스 로직에 더 집중하면 된다.


Spring Bean 등록

너가 만든 객체들 중에 내가 관리해야 할 녀석들을 알려줘, 

java, xml, annotation 등 상관없어 너가 편한 방식으로 나에게 메타정보를 작성해서 알려줘


DI(Dependency Injection)

객체(Bean)들간의 의존성은 생성할 때 내가 다 의존성을 넣어 주고, 관리하도록 할게 ! 너는 나에게 그 메타정보만 작성해서 알려줘 


AOP(Aspect Oriented Programming)

반복적으로 적용되는 횡단 관심사(Aspect)도 내가 다 적용시켜줄게, 너는 어떤 로직(advice)을 어떤 녀석(point cut)에게 붙여주면 되는지 나에게 메타정보만 작성해서 알려줘





Bean 

 IoC방식으로 관리하는 오브젝트. Managed object라고 불리기도 한다.

스프링은 Bean 객체의 생성 및 제어를 담당한다.


Bean FactoryA

 IoC를 담당하는 핵심 Container다. Bean 등록, 생성, 조회 기능을 한다.

Bean Factory를 직접 사용하지는 않고, 이를 확장한 Application Context를 사용한다.


Application Context

 Bean Factory를 확장한 IoC Container 이다. 


Configuration metadata

 IoC 컨테이너를 사용하기 위한 configuration 정보들이 들어있다.

청사진 (blueprint) 로 볼 수 있다.


IoC Container

 Bean Factory, ApplicationContext를 IoC Container라고 부른다.

Container 라는 단어 자체가 IoC의 뜻을 내포하고 있다.

흔히 말하는 '스프링' 은 IoC Container 와 같은 표현이다.



출처: http://feco.tistory.com/111 [wmJun]

'Programming > Spring' 카테고리의 다른 글

POJO  (0) 2018.05.14
AspectJ Aop설정방법  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13
jstl 간단 사용법  (0) 2018.05.13
jQuery 간단 사용법  (0) 2018.05.13

event.preventDefault()


preventDefault 를 이해하기 위해서는 a 태그를 유심히 봐야 합니다. 위 슬라이드에 표시된 a 태그는 내부적으로 href="#" 속성을 가지고 있습니다. href 속성은 웹브라우저에게 a 태그 클릭시 이동하여야할 페이지를 나타냅니다.

예를 들면) <a href="http://ismydream.tistory.com" onclick="...">창조적고찰 블로그</a> 처럼 사용합니다.

위 a 태그는 click 이벤트 또한 가지고 있기 대문에 a 태그를 클릭했을 때는 차례대로 두가지 행동을 하게 됩니다.

첫번째 click 이벤트를 실행합니다.

두번째는 브라우저에게 href 에 표시된 곳으로 이동하도록 합니다.

href="#" 속성을 넣은 이유는 a 태그에는 click 이벤트가 있으니 click 이벤트만 실행하고 웹브라우저는 이동하지 말아라 하는 의도로 설정한 값입니다. 이렇게 하게 되면 클릭시에는 click 이벤트만 실행되고 웹브라우저가 이동하지는 않게 됩니다. 제가 생각하기에는 좀 꼼수 같기도 합니다.

근데 여기서 한가지 주의해야 할 점이 있습니다. href="#" 은 웹브라우저가 다른 곳으로 이동하지는 않지만 스크롤이 있는 곳에서는 페이지 상단으로 이동하게 됩니다. href="#~~~" 으로 사용하는것을 앵커(닻) 라고 하는데 href="#" 은 웹브라우저의 최상단을 가리키는 앵커입니다.


글을 작성할때나, 회원가입을 할때 버튼 한번 클릭할때마다 페이지가 쭉 위로 올라가는 경험을 해보신분들은 그 짜증스러움을 익히 아시리라 생각합니다. ㅠㅠ

 이 브라우저 행동을 막기위해서 사용하는게 preventDefault 입니다.

preventDefault 는 a 태그 처럼 클릭 이벤트 외에 별도의 브라우저 행동을 막기 위해 사용됩니다.


출처: http://ismydream.tistory.com/98 [창조적고찰]



event.stopPropagation()


- a태그 부모태그는 실행시키지 않는다

실행이 전파되는 것을 막는 메소드


참고 : http://programmingsummaries.tistory.com/313

'Programming > Spring' 카테고리의 다른 글

AspectJ Aop설정방법  (0) 2018.05.14
spring 사용이유?  (0) 2018.05.14
jstl 간단 사용법  (0) 2018.05.13
jQuery 간단 사용법  (0) 2018.05.13
IOC / DL / DI  (0) 2018.05.13

         <c:choose>
                <c:when test="${fn:length(list) > 0}">
                    <c:forEach items="${list}" var="row">
                        <tr>
                            <td>${row.ID}</td>
                        </tr>
                    </c:forEach>
                </c:when>
                <c:otherwise>
                    <tr>
                        <td colspan="4">no data</td>
                    </tr>
                </c:otherwise>
            </c:choose>


데이터 조회해오고 화면에 뿌려줄때 쓰는 jstl문법입니다.



'Programming > Spring' 카테고리의 다른 글

spring 사용이유?  (0) 2018.05.14
event.preventDefault() / event.stopPropagation()  (0) 2018.05.13
jQuery 간단 사용법  (0) 2018.05.13
IOC / DL / DI  (0) 2018.05.13
Spring Framework  (0) 2018.05.12

ajax

$.ajax({
                url: "/sample/board_list/next_page",
                type: "GET",
                data: param,
                success: function(data){
                   
                ...
                   
                },
                error: function(request, status, error){
                    console.log(error)
                }
            });


id="list" 자식 태그 제거하기

$("#list").empty();


id="list" 에 a추가하기

$("#list").append(a);



클릭 이벤트 정의

$("#write").on("click", function(e) {
         fn();
});


만약 자바스크립트로 동적으로 html을 만들었다면 위의 이벤트 정의가 먹히지 않는다. 이유는 해당 html이 그려지고 난다음 jQuery가 정의되는데 이벤트를 정의한 id가 삭제되면 jQuery는 연결되어있는 연결고리가 없어지게 된다. 이는 이후에 같은 아이디를 만들어도 연결되지 않는 다는 것을 뜻한다. 그렇기 때문에 아래와 같은 방법을 사용해야한다.

 

$(document).on("click","#write", function(e) { //제목
         fn();
});



a태그중 name이 page인

"a[name='page']" 친구들을 정의한다.


this는 js의 this로 현재 태그를 받아온다.

$(this) jQuery의 this로 this의 객체형이다. parent()를 사용해서 부모태그를 얻을 수 있다.



val() / text() / html()

val()은 textarea의 값을 받아올때 쓰인다.

text() / html()는 자바스크립트의 innerHTML()처럼 쓰인다.



jstl로 받아온값을 자바스크립트 변수로 담는법

total_page_cnt = <c:out value="${page}"/>;


'Programming > Spring' 카테고리의 다른 글

event.preventDefault() / event.stopPropagation()  (0) 2018.05.13
jstl 간단 사용법  (0) 2018.05.13
IOC / DL / DI  (0) 2018.05.13
Spring Framework  (0) 2018.05.12
CRUD구현하기 - Back end  (0) 2018.02.16

+ Recent posts