자바스크립트는 싱글스레드라 복잡한 화면을 렌더링하면서 MessageBox 로 progress 를 보여줄 경우 재대로 표시가 되지 않는 경우가 있습니다. 이러한 경우에는 Timer 를 통해서 딜레이를 주어서 차례대로 실행하면 원하는 효과대로 처리할 수 있습니다.
진행할 과정들을 나눈 후에 ProgressTimer 를 구현하여 progressRun 메소드에서 실행하도록 한후 ProgressManager 에 추가하는 방식으로 추가된 순서대로 실행을 하도록 하는 방식입니다. 약간의 딜레이가 있을 경우에는 프로세스가 화면 렌더링을 하기전에 즉, 화면이 멈춰보이는 상태 전에 MessageBox 의 progress 를 업데이트합니다.
추가적으로 생성할 때 내부에서 사용할 객체를 넘겨주기 때문에 필요한 객체를 효과적으로 사용할 수 있습니다.
일반적으로 GEF 에서 EditPart 에 EditPolicy.LAYOUT_ROLE 로 editpolicy 를 install 하게 됩니다.
이렇게 처리할 경우 생성이나 이동, 리사이징에는 별 무리 없이 사용할 수 있을 것이라 생각하였으나 한가지 문제가 있었습니다. 다른 자식 피규어와 겹칠경우 정상적으로 이동이 되지 않는 것이었습니다. LAYOUT_ROLE 로는 다른 자식 피규어 위에서 이동하는 것에 대한 이벤트를 잡지 않는 것으로 파악이 되었습니다. 그래서 조금 찾아보니 될 것만 같은 것이 있어서 한번 수정한 후 실행을 해보았습니다.
그냥 한번 해보았을 뿐인데... 원하는 결과가 나와버렸습니다. 그래서 구글에서 좀 찾아보니 아래와 같은 자료가 있었습니다.
Because of the relationship between handles and layouts, it is recommended that thePRIMARY_DRAG_ROLEeditpolicy be installed by the parent'sLayoutEditPolicy, which defines abstract methods for this purpose. If a container changes layout managers during editing, typically the layout policy gets swapped with one for the new layout manager. The new policy then replaces the stalePRIMARY_DRAG_ROLEpolicies on each child.
무신 말씀을 하시는지는 정확하게 파악을 하지 못하였으나 잘 돌아가주시니 감사할 따름입니다.
The DragEditPartsTracker extends basic selection behavior to allow the selected parts to be dragged within their graphical viewer. Dragging the selected parts can result in three potential interactions: move, reparent, and clone. All three use theChangeBoundsRequest, which extends GroupRequest to include a size delta, move delta, and mouse location.
While dragging the selection, if the tracker targets the part's original parent, the request is typed asREQ_MOVE. If the target changes, the interaction becomes a reparent. For a reparent, a request of typeREQ_ORPHANis sent to the old parent, while the new target is sent a request of typeREQ_ADD. When the CTRL key is pressed (ALT on the Mac), the operation is always aREQ_CLONE, which is only sent to the target part.
All of these requests are related in that they require the target to process a rectangle and a mouse location. The LayoutEditPolicy is responsible for handling each of these request types. For layouts which use constraints, each part's original bounds is taken and modified by the size and move deltas to determine a new bounds, for which a corresponding constraint is found. For index-based layouts, the mouse location is used to establish the new index.
AContainerEditPolicycan optionally be used to contribute additional commands (not related to the layout) during ADD, ORPHAN, and CLONE requests.
Resizing
Resizing falls under the same category as changing bounds. Note that when resizing either the top or left sides, the location of the part is also changed. Resizing only makes sense for layouts with constraints, such as XYLayout. TheResizableEditPolicyadds up to eight resize handles to its host. When the Selection Tool is clicked on one of these resize handles, aResizeTrackerperforms a resize on the selected parts understanding "resize". SHIFT and CTRL key modifiers can be used to constrain the resize operation.
The types of handles available on an editpart depend on the layout manager in which its figure is placed. For example, parts inside a table might have handles for adjusting insets, padding, column span, or other attributes. Some layouts don't need any handles, but four corner handles should be added just to indicate selection. Dragging these handles would be the same as dragging the part itself.
Because of the relationship between handles and layouts, it is recommended that thePRIMARY_DRAG_ROLEeditpolicy be installed by the parent'sLayoutEditPolicy, which defines abstract methods for this purpose. If a container changes layout managers during editing, typically the layout policy gets swapped with one for the new layout manager. The new policy then replaces the stalePRIMARY_DRAG_ROLEpolicies on each child.
TheMatchSizeActionmatches the size of the selected parts to that of the primary selected part's size. This action is implemented in a way similar to manually resizing the individual parts, and it uses the same request and type.
TheAlignmentActionuses anAlignmentRequest, which extends ChangeBoundsRequest. When using a ChangeBoundsRequest, the part's current placement in the Control (in absolute coordinates) is passed to the request, which then returns a modified version. Using this pattern, alignment is able to adjust each part's rectangle by different amounts. In most cases, alignment can be treated no differently than a move. This action aligns all selected parts with one of the edges of the primary selected part.
The JavaScriptObject class has been an extremely useful concept because it provides zero-overhead interoperation with external (typically, non-GWT) JavaScript while adding additional value to external JavaScript objects by representing them as actual Java types that are amenable to refactoring, code completion, and Javadoc-style documentation. However, subclassing JavaScriptObject was not generally supported before GWT 1.5 because we weren't sure if it was the right solution, or if we might need to evolve it in breaking ways. This document describes the "old model" prior to GWT 1.5, and the new model, overlay types, which shipped in GWT 1.5 as well as extensions to overlay types that will first ship in GWT 2.0.
The old model used two very different approaches for hosted mode and web mode, but in both cases the point of interest was the boundary point between Java and JavaScript code, when a JavaScript object passes into "the Java world". This boundary point was most often the return value of a JSNI function, but could also occur when a JSNI function accessed Java code through a field assignment, or by passing parameters to a Java function called from JSNI.
In hosted mode, we created an instance of JavaScriptObject (or a JavaScriptObject subclass) as we marshalled the value from JavaScript to Java. This instance served as a Java wrapper for the underlying JavaScript object. It had strong type identity, and handled instanceof, casts, and polymorphic calls through the normal Java mechanisms.
In web mode, we did not wrap the underlying JavaScript object in the traditional sense with a peer object, because that would have impeded performance. Instead, we decorated the underlying JavaScript object with sufficient type information to handle runtime type checks and polymorphic dispatch as needed.
JavaScriptObject 와 관련된 글인 것 같은데 조금 더 읽어봐야겠습니다.
누군가 영어를 잘하신 분이 친절하게 댓글을 달아주신다면.... ㅎㅎㅎ
1.지금까지의 개발 방식과는 다르게 데이터베이스 설계부터 진행하는 것이 아니라 도메인 모델을 설계하고 이를 바탕으로 소스 코드를 확장시켜 나가는 방식을 취한다. GWT와 Spring에 대한 기술적인 이해도 있겠지만 Mock Object를 이용하여 인터페이스를 확장하고 설계를 개선시켜 나가는 방법을 습득해본다.
2.기본적으로 사용하는 기술 요소는 GWT + Spring + Spring JDBC를 기반으로 개발한다. DB는 hsqldb와 같이 가벼운 DB를 사용할 예정이다.
3.GWT를 다루면서 새롭게 등장하고 있는 웹 UI 개발 방향에 대한 이해도를 높일 수 있다.
4.Spring 프레임워크에 대한 기본적인 지식을 습득하고 Spring 프레임워크 기반의 테스트 코드 구현 방법에 대하여 습득할 수 있다.