A N ARCHITECTURE FOR A WEB - BASED IDE

A Thesis Presented to the Faculty of the College of Computer Studies De La Salle University Manila

In Partial Fulllment of the Requirements for the Degree of Bachelor of Science in Computer Science

by

CO, Richelle Charmaine G. OBALDO, Marc Anthony M. ONG, Audrey Elaine G.

Danny CHENG Adviser

August 31, 2010

Acknowledgements We express our greatest thanks to our adviser Mr, Danny Cheng, and also to Ms. Lesley Abe and Mr. Karlo Campos, for guiding us throughout the research. We would also like to thank the members of the NetCentric Lab - the COREO group, Mobile Social Application Store, and Mobile Social Traveler groups - for sharing our pain and helping us along the way. Also our greatest thanks to our friends: Joyce Dayego, Joyce Sia, Irisse Brofar, Richmond Tan, Jerrick Chua, Jonathan Yiu and our fourth thesis member Elaine de Dios for cheering us on. Special thanks to Mercurial, Brother printers and Sting energy drink for making things a bit easier. Of course, we give our gratitude to our parents for being an inspiration for nishing the research. Lastly, we would like to thank God, for giving us the strength, the wisdom, and the perseverance to accomplish this research.

Abstract Today, cloud computing refers to a style of computing where dynamically scalable resources are put as a service over the Internet. Users do not need to understand the inner mechanisms of these services; they only need to know how to use them. Thus, this advantage of cloud computing is said to be cost-effective as users do not need to worry about hardware costs anymore. There are three types of services that is brought about by cloud computing: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). PaaS typically provides a web-based development environment and a runtime environment with cloud services for developers to use. However, these web-based IDEs are tightly coupled into the vendors systems and services and are proprietary. This research focuses on presenting a web-based IDE as a SaaS which supports the complete lifecycle of building a web application without relying on a specic platform and infrastructure. Keywords: Collaborative computing, Integrated environments, Web-based services

Table of Contents
1 Research Description 1.1 Overview of the Current State of Technology . . . . . . . . . . . . . . . . . . . . 1.2 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 General Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Specic Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Scope and Limitations of the Research . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Signicance of the Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Research Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Software Development Process . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.5 Final Product Increment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.7 Final Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.8 Calendar of Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Review of Related Literature 2.1 Architectures of different IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Benecial Collaborative Features in IDEs . . . . . . . . . . . . . . . . . . . . . . 2.3 Existing IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Programming languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Cloud computing and server integration . . . . . . . . . . . . . . . . . . . 2.3.5 Summary of different IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Related Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 2 2 3 3 3 3 4 4 5 6 6 6 7 8 8 8 9 9 10 10 10 10 11

ii

2.4.1 Eclipse Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Google Docs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 CollabEdit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Theoretical Framework 3.1 Eclipse Plug-in Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Platform Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Google AppEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Google AppEngine Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Java Data Object Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 14 14 16 16 16 17 18 20 21 22 22 23 23 23 24 25 25 25 25 26 26 26 26 27 27 28

3.5.1 JSON Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 JSON Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.5 Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Dojo Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Byte Code Engineering Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 CodeMirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Java Reection API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.10 Java Jar API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.1 Choice of Network Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.2 Consistent Data Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.3 Efcient Branching and Tagging . . . . . . . . . . . . . . . . . . . . . . . 3.11.4 Hackability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 SVNKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 The CtrlSpace Platform: A Web-based Integrated Development Environment

iii

4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 System Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Scope and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Database Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Message Exchange Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5 Client side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.6 Server-side Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.7 Client-side Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.8 Default Web Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.9 Google App Engine Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.10 Globe Labs API Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.11 Default Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.12 Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Open Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Close Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 New le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Save le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.6 Save project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.7 Run Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.8 Deploy Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.9 Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.10 Auto-complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.11 Syntax Highlighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 28 28 29 31 32 32 34 37 39 60 62 64 65 66 70 77 77 77 77 78 78 78 78 78 78 78 79

iv

4.5.12 Undo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.13 Redo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.14 Invite Collaborator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.15 View Collaborators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.16 View File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.17 Edit File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.18 Copy File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.19 Move File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.20 Rename File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.21 Show contents of le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.22 View Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Physical Environment and Resources . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Dojo Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Google AppEngine Software Development Kit . . . . . . . . . . . . . . . . 4.6.3 Byte Code Engineering Library . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 CodeMirror . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5 Java Reection API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6 Java Jar API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.7 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.8 SVNKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Design and Implementation Issues 5.1 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Byte Code Engineering Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Database Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Import Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Results and Observations

79 79 79 79 79 79 79 80 80 80 80 80 80 81 81 81 82 82 83 83 84 84 84 84 84 85 86

6.1 User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86 86 86 87 87 87 88 88 92 94 96 98

6.1.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Fwibble Me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Performance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Functionality Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 New Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.2 New Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 New Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.4 New Enum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 New Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.6 New Java Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.4.7 New CSS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.4.8 New HTML File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.4.9 New JS File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.4.10 New JSP File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.4.11 New Servlet File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.4.12 New Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.4.13 New Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.4.14 Open File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.4.15 Close File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.4.16 Save File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.4.17 Run Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.4.18 Deploy Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.4.19 Auto-complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.4.20 Syntax Highlighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.4.21 Copy File or Folder then Paste . . . . . . . . . . . . . . . . . . . . . . . . 126

vi

6.4.22 Cut File or Folder then Paste . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.4.23 Rename File or Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.24 Delete File or Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.4.25 Import Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 132

7 Conclusion and Recommendations

7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.2.1 Database Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.2.2 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.2.3 Plugin System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.2.4 GUI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A Resource Persons B Personal Vitae C Survey Results References 134 135 136 137

vii

List of Figures
1.1 Scrum Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 The Aurora SDK Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Eclipse Platform Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 jdocong.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 JDO Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8 17 18 19 20 21 22 22 23 23 24 30 32 33 81 82

3.4 Queries executed at once . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Queries built part-by-part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 JSON Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 JSON Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 JSON Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 JSON Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 JSON Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 CtrlSpace Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 CtrlSpace default new project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Class diagram and ERD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 User Interface Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 BCEL Sample Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

List of Tables
1.1 Timetable of Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Useful features in collaboration in IDEs . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Issues regarding collaborative features in IDEs . . . . . . . . . . . . . . . . . . . 2.3 Summary of different IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 FileType data structures and descriptions . . . . . . . . . . . . . . . . . . . . . . 4.2 FileUnit data structures and descriptions . . . . . . . . . . . . . . . . . . . . . . . 4.3 ProjectUnit data structures and descriptions . . . . . . . . . . . . . . . . . . . . . 4.4 User data structures and descriptions . . . . . . . . . . . . . . . . . . . . . . . . 4.5 IProjectNature Interface functions and description . . . . . . . . . . . . . . . . . 7 9 9 11 34 35 35 36 42 43 46 47 48 52 53 54 55 59 59 60 62 63 65 65 66 66

4.6 Command Interface functions and description . . . . . . . . . . . . . . . . . . . . 4.7 Plugin DAO functions and descriptions . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Project DAO functions and description . . . . . . . . . . . . . . . . . . . . . . . . 4.9 File System DAO functions and description . . . . . . . . . . . . . . . . . . . . . 4.10 User DAO functions and description . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Workspace DAO functions and descriptions . . . . . . . . . . . . . . . . . . . . . 4.12 FileType Manager and description . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Project Manager and description . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14 User Manager and description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.15 User Manager and description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Dojo Toolkit functions and their description . . . . . . . . . . . . . . . . . . . . . . 4.17 File Types Register functions and descriptions . . . . . . . . . . . . . . . . . . . 4.18 Default Commands and their description . . . . . . . . . . . . . . . . . . . . . . . 4.19 File Types Registered and their description . . . . . . . . . . . . . . . . . . . . . 4.20 File Types Registered for App Engine Plugin and their description . . . . . . . . . 4.21 File Types Registered for Globe Labs API and their description . . . . . . . . . . 4.22 Command for Globe Labs API and its description . . . . . . . . . . . . . . . . . .

ix

4.23 Add File context information and their description . . . . . . . . . . . . . . . . . . 4.24 Open File context information and their description . . . . . . . . . . . . . . . . . 4.25 Save File context information and their description . . . . . . . . . . . . . . . . . 4.26 Rename File or Folder context information and their description . . . . . . . . . . 4.27 Delete File context information and their description . . . . . . . . . . . . . . . . 4.28 Copy File context information and their description . . . . . . . . . . . . . . . . . 4.29 Cut File context information and their description . . . . . . . . . . . . . . . . . . 4.30 Paste File context information and their description . . . . . . . . . . . . . . . . . 4.31 Editor Manager functions and their description . . . . . . . . . . . . . . . . . . . 4.32 Syntax Highlight functions and their description . . . . . . . . . . . . . . . . . . . 4.33 Begin Code Assist context information and their description . . . . . . . . . . . .

66 67 68 68 69 69 69 70 73 75 76

Research Description

This chapter will discuss a brief introduction to cloud computing, as well as a brief overview of the current state of web-based IDEs, the research objectives of the project, the scope and limitations of the project, and the signicance of the research.

1.1

Overview of the Current State of Technology

In the early days of the networking, diagrams of architectures often depicted the Internet as a cloud. Unknowingly, this would be the root of the computing phenomenon known as cloud computing. We always drew networks as amoeba-like things because they had no xed topology and typically covered varying geographic areas, says Vint Cerf, co-creator of TCP/IP (Scanlon & Wieners, 1999). Cloud computing has the concept of covering up the inner mechanisms of the Internet and has no clear boundaries set, like a physical cloud. In the past, people did not care how messages were sent. It passed through the cloud, coming in from one side and coming out from another. People did not have to worry about the network because the cloud hid it from them (Slack, 2009). The next evolution of cloud computing was the world wide web which provided a cloud over documents. People would load up a URL in their browser and the documents would be served to them from anywhere in the world. At present, the term cloud computing would refer to a style of computing in which dynamically scalable resources are provided as a service over the Internet. Users of cloud computing are people who need not control the cloud, have expertise on it, nor even have knowledge of it. Users need not worry about what happens to all the connections, all the smallest details, and all of the inner mechanisms of what they are using, and instead, focus more on what is tangible to them, moving all of the management to the server. This effectively reduces the management costs of the users. Making sure that data is backed up, software versions are synchronized, spam lters are updated, and many other tasks are a signicant part of web application projects. However, the management cost of having to take care of all of these tasks is high, and is the key motivation for the move to cloud computing (Felten, 2009). The concept of cloud computing incorporates combinations of Software as a Service (SaaS), Hardware or Infrastracture as a Service (IaaS) and Platform as a Service (PaaS). IaaS is the evolution of the traditional private or virtual hosting where resources are provided as a package. In IaaS, these resources are provided and are billed on a basis much like electricity usage, where the cost reects the amount of activity or usage. A PaaS runs on top of the infrastructure, making it easier to put the infrastructure to use. It targets developers, as it provides an integrated development environment, as well as a runtime environment, that provides the facilities to manage the complete lifecycle of building and deploying a web application, including facilities for application design and development, testing, deployment and hosting, as well as team collaboration, source code control and database integration (Pijanowski, 2009). SaaS, on the other hand, would be an application hosted on a remote server that can be accessed through the Internet. The application exists in the cloud, it is available on demand, and it can be consumed from any web browser. In SaaS, the vendor is not only responsible for providing the application, but also for providing the data storage, computational power, and the networking infrastructure needed to support the application. This vendor can utilize a third 1

party IaaS or PaaS to provide such infrastructures, but this does not always have to be the case. The IDEs of PaaS are typically web-based and are integrated into the platform and infrastructure provided by the vendor. However, a web-based IDE can be presented as an SaaS, as in the case of Coderun. Coderun, although not owned by Amazon, is a web-based IDE that is capable of deployment to Amazons EC2 cloud servers. It is a software on the Internet that supports the development and deployment of web applications. However it cannot be classied as a PaaS as it does not provide its own set of cloud services. It is merely a development environment, without a runtime environment (CodeRun, 2009). Some web-based IDEs, as in the case of PhpAnywhere (PhpAnywhere, 2009) are made to merely provide mobility of the development environment, while others take advantage of the web to provide collaboration capabilities (ECCO, 2009). The web-based IDEs today that run on top of PaaS and IaaS are typically proprietary and are locked in to the vendor that provides them. In the case of Coderun, it does not specically run on top of any platform, however it is tightly coupled with its community which provides code sharing, as well as integration into Amazons EC2 Cloud. While there exists web-based IDEs that are integrated into PaaS and IaaS, there exists no web-based IDE that is not tightly integrated into a specic system that is capable of supporting the entire lifecycle of building a web application, including, but not limited to the application design and development, testing, and deployment, as well as team collaboration, source code control, and database integration.

1.2

Research Objectives

This section will state the general and specic objectives of the research.

1.2.1

General Objective

To develop an architecture of a web-based IDE that supports the development of web applications

1.2.2

Specic Objectives

1. To review the architectures of existing web-based IDEs; 2. To study the integration of the web-based IDE to the platform that it will be deployed on; 3. To identify how different feature sets in IDEs work, and what the users need in these feature sets; 4. To identify the requirements of the different projects types supported by the research; and 5. To study the collaborative features that developers use in IDEs

1.3

Scope and Limitations of the Research

The feature sets to be identied are based on the different scales of projects created by developers. The minimal feature sets of a basic 2-tier web application will be initially identied as is the case of a general web application supporting database connections. As the research progress, more feature sets of applications of greater scale will be identied. Further details, like support of code documentation generation, frameworks, collaboration and n-tier architectures among others, about the types of projects concerned will be identied further within the duration of the research as well. The requirements of different project types refer to the project skeleton les, the database types and schema design, and other settings or features that projects need in order to work. Furthermore, the proponents study the collaborative features developers use in IDEs to understand how it can be applied to the architecture to be developed. This collaboration with visual cues such as chat, as well as in passive collaboration such as source code and revision control.

1.4

Signicance of the Research

The research focuses on exploring the presentation of a web-based IDE as an SaaS capable of integrating into existing PaaS and IaaS. Thus, being part of cloud computing, it allows a more cost-effective solution to developing and deploying web applications. Developers do not need to worry about the inner mechanisms of the servers and connections they use, and instead can focus on simply choosing a service and developing their software on the IDE. Additionally, for developers who tend to go out of town or out of the country, this research would allow them to maintain already developed web applications anytime and anywhere, as long as there the developer nds someplace where there is an internet connection. As a software residing on the Internet, a developer would only need to have an internet-capable device to make changes to his or her applications. Being a SaaS, the research will also possibly allow hosting companies to integrate the IDE into their services. This does not necessarily have to be cloud computing, and as such can be used by simple virtual and private hosting companies.

1.5

Research Methodology

This chapter identies the activities that will be performed throughout the duration of the research.

1.5.1

Research Process

During the period from August 2009 to April 2010, the proponents will be iterating over the different architectures of existing IDEs as well as their feature sets. This is done in conjuction

Figure 1.1: Scrum Development Process with the whole software development process as the output will be dependent on existing systems. Each of the software components that will be developed in the duration of the research is subject to criticism and evaluation and these evaluations will also be based on the status of existing research.

1.5.2

Software Development Process

The nature of the research process entails frequent changes within the architectural design of the system, thus the proponents have to adopt to these changes as the research and development progresses. An agile method of software development allows for these necessary changes arising during the development process. The proponents have chosen SCRUM as the development process for this research. SCRUM is an agile process that encourages the progression of projects via a series of iterations called sprints.

1.5.3

Sprint

A sprint is a time-boxed period of software development focused on a list of goals. A sprint can be held together by the whole team in a specic location or can be done separately online. The sprint is directed by a coach, or one of the proponents, who is responsible for the direction of the whole sprint. Sprints can vary in focus. Some sprints can be solely focused on research or processes that are not actual development of the software output, while some sprints can be solely focused on the development of the software output. During each sprint, the proponents create a potentially shippable increment of the system which can either be a working and tested software, an architecture design, or a documentation of what was accomplished during the sprint. The proponents have decided that the time-box for each Sprint will be two weeks. 4

1.5.4

Meetings

Meetings are held by the proponents at different intervals to discuss the current status of the research, as well as the status of the current sprint. Listed below are the different types of meetings.

Scrum Meetings Each 48 hour period during a sprint, a project status meeting occurs. A Scrum is a stand-up meeting and has specic guidelines: 1. The meeting starts precisely, and often there are team-decided punishments for tardiness. 2. Anyone is welcome to attend but only the proponents and the adviser (if present) are allowed to speak. 3. The meeting is time-boxed to 15 minutes. 4. No one is allowed to sit down, as to prevent the meeting from going over the time box. 5. The meeting should happen at the same location and same time every meeting. During the meeting, each proponent must answer three questions: 1. What have you done since yesterday? 2. What are you planning to do by today? 3. Do you have any problems preventing you from accomplishing your goal?

Sprint Planning Meeting At the beginning of a sprint cycle, a sprint planning meeting is held. The following things are to be done in the sprint planning meeting: Identify what tasks need to be completed for the sprint Select what task is to be done by each proponent Prepare the sprint backlog that details the weight and effort required from each task At the end of each sprint cycle, two meetings are held: the Sprint Review Meeting and the Sprint Retrospective.

Sprint Review Meeting During the sprint review meeting, the tasks which were completed and which were not completed will be reviewed. Only the tasks which are deemed completed and working will be presented.

Sprint Retrospective During the sprint retrospective, the proponents will reect on the past sprint. This is to make continous process improvement. In this meeting, two main questions are asked: What went well during the sprint? What could be improved in the next sprint?

1.5.5

Final Product Increment

This stage is an overall assessment of the work. At this point, the team would already have a potentially deliverable output. This work will be subject to tests, evaluation and criticism by the team. In the event that a corrections is found, these will be listed and the team will have to go back to the Prototype Building stage.

1.5.6

Documentation

Documentation is done in every stage of the process. There are 2 types of documentations involved throughout the development process, namely the product backlog and the sprint backlog.

Product Backlog The product backlog is a high-level document for the entire project. It contains broad descriptions of each feature of the system, a to-do list, as well a wish-list, all prioritized by its value or weight in the system.

Sprint Backlog The sprint backlog is a document containing information on how the team will implement features for the next sprint. Features are broken down into tasks and their weight or value is also estimated vis-a-vis its equivalent development effort requirement. Tasks on the sprint backlog are never assigned, but are rather picked from the list by any of the proponents as needed, depending on the weight of the task and the development skills of the proponent.

Burn Down Chart The sprint burn down chart is a publicly displayed chart showing work remaining in the sprint backlog. It gives a quick overview of the sprint progress and is updated everyday. It provides a visualization of the progress for reference purposes.

1.5.7

Final Output

This is the stage wherein the proponents will nalize their research by ironing out the last details, compiling all of the work for the whole duration of the project, and generating the nal output. 6

1.5.8

Calendar of Activities

Table 1.1 shows a Gantt chart of the activities. Each bullet represents approximately one week worth of activity. Table 1.1: Timetable of Activities

Review of Related Literature

This chapter discusses different literature related to the research. The reviews are about the architectures of different IDEs, studies about integrating collaborative features on IDEs, and features and targeted users of different IDEs.

2.1

Architectures of different IDEs

In 2007, a team of students from the University of British Columbia developed a web-based IDE which they named Aurora. Although the IDE itself could not be found, the team uploaded their documentation on the universitys website. They divided the architecture of their IDE into three parts, namely the system, user interface, and the database structure. The system structure made use of the model-view-control architecture which divided the system structure into the application, service, compiler, and persistence layers. The Google Web Toolkit (GWT) was used in the application layer, and was also used to communicate between layers.The user interface architecture was divided into ve composites. One for the menu bar, one for the toolbar, another for the panels, the le explorers, and the last one for the editor. Finally, the database structure makes use of one design pattern called the Data Access Object (DAO) design pattern. MySQL was used as the database management system. Figure 2.1 shows the architecture of the Aurora SDK (Jingwen Ou, 2007).

Figure 2.1: The Aurora SDK Architecture

2.2

Benecial Collaborative Features in IDEs

In 2004, Cheng et al. wrote that there are several points to consider when developing a collaborative system. Some of these include providing peripheral awareness of other programmers and their activities, supporting a variety of communication mechanisms such as text, voice, and visual communication mechanisms, and supporting searching through the saved development

history. These pointers aid to the issue of creating collaborative IDEs, which is choosing the set of collaborative features to integrate. Different developer teams have different cultures and styles in working, so it is benecial if a lot of collaborative features are offered in the IDE. These information further emphasizes the need to identify a usage pattern for this research (Cheng et al., 2004). Similarly, Cubrani and Storey concluded that besides version control in the IDE, a means c of communication proved to be more benecial to people who use collaboration in the IDE. The paper further concluded through tests that version control is easy to use, even for novice programmers. Whitehead (2007) wrote that there are issues that must be taken notice of when developing collaborative systems. This was backed up by Cheng et al. (2004). The article mentioned that there are issues when creating collaborative systems. There is exibility, extensibility, and transitions between individual and group work. Flexibility is basically about being able to support different culture and working styles of different groups of people. Extensibility is about being able to further plug more features into the system. Transitions between individual and group work means that there should be a clean separation between individual work and group work such that if a developer in a team is working on something individually, his/her work must be private unless he/she voluntarily shares his/work to the group. Table 2.1: Useful features in collaboration in IDEs Features Recommended Building collaboration into IDEs Peripheral Awareness, Communication Tools, (Cheng et al., 2004) Searching and Archives Collaboration support for novice Communication Tools team programming (Cubrani & c Storey, 2005) Collaboration in Software Peripheral Awareness Engineering: A Roadmap (Whitehead, 2007)

Table 2.2: Issues regarding collaborative features in IDEs Issues Building collaboration into IDEs Flexibility, Transition between individual and (Cheng et al., 2004) group work Collaboration in Software Flexibility, Extensibility, Transition between indiEngineering: A Roadmap vidual and group work (Whitehead, 2007)

2.3
2.3.1

Existing IDEs
Portability

Generally all web-based IDEs support portability as the workspace is created and saved on the server, and developers can access the projects any time as long as they have an internetenabled device and a web browser. Examples of web-based IDEs include PhpAnywhere

(PhpAnywhere, 2009), CodeRun (CodeRun, 2009), Aptana (Aptana, 2009), ECCO (ECCO, 2009) and Bespin (Bespin, 2009). This is especially convenient to people who tend to go abroad or out of town, but needs to tend to needed updates in cases of emergency.

2.3.2

Programming languages

Most web-based and desktop IDEs support web based programming languages for developing web applications. For example, PhpAnywhere, CodeRun, and Aptana support PHP; while CodeRun, Aptana, ECCO, and Bespin support other web based progamming languages like JavaScript, HTML. Some of these web-based IDEs like CodeRun even support iPhone code, as well as Facebook Application development.

2.3.3

Collaboration

The most common collaboration feature of IDEs are Version Control Systems. Both CodeRun and Aptana support this, integrating SVN in their systems. An interesting collaborative feature will be that of Jazzs. Jazz is a project of IBM Rational that is aimed to be plugged into, Eclipse. It adds to the features of Eclipse by adding a social network and IM inspired feature that allows people inside a developing group to have an IM-like interface where they could upload their pictures, set up status messages, and chat. Jazz also indicates which les users are editing in real-time so that every member of the group is aware of what everyone else is doing at any given time (Jazz, 2009).

2.3.4

Cloud computing and server integration

Cloud computing offers scalable and virtualized resources as a service over the Internet. This allows users of cloud computing to need not know of the underlying technology behind these services. A few IDEs are capable of integrating projects into these cloud servers. These are mostly proprietary IDEs of which projects are deployed onto proprietary servers. For example, Aptanas cloud integration support is only offered for Aptana Pro users, who benet from oneclick deployment of their projects onto Aptanas web servers. CodeRuns cloud integration is tied up with Amazons EC2 cloud server.

2.3.5

Summary of different IDEs

Based on the IDEs reviewed, it can be observed that the targeted users of most web-based IDEs are web application developers. These IDEs mostly support collaboration, but among those reviewed, only version controlling was found in most IDEs, and Bespin was the only one found with real-time collaboration. There is no IDE reviewed yet that supports chatting. Compared to the number of IDEs that support collaboration, fewer IDEs support server integration. Most IDEs have plug-ins for FTP support, and only CodeRun support direct deployment to Amazon Cloud. Since there is a variation of having these features as plug-ins and some bundled with the IDE itself, this presents a variation in architecture. Table 2.3 shows the summary of different IDEs, their target users, their key feature and cloud server support.

10

System Aptana

Table 2.3: Summary of different IDEs Target Audience Collaboration Web app developers SVN

Bespin CodeRun

Web app developers Web app developers

Real-time collaboration SVN

ECCO PhpAnywhere

Students and teachers PHP developers

Not supported Coming soon

Server Integration FTP support, deploy to Aptana cloud Not supported Deploy to Amazon Cloud (EC2) Not supported FTP support

2.4

Related Systems

This part of the chapter discusses related systems including features that may be integrated in Integrated Development Environments (IDEs).

2.4.1

Eclipse Platform

The Eclipse Platform is a foundation for building development environments as well as other arbitrary applications and tools. It was developed by the Eclipse Foundation and was designed to run natively on multiple operating systems including Microsoft Windows, Macintosh, Linux and other operating systems. The platform being bound together by different components, has the functionality required in order to build integrated development environments (IDE) and with the use of the subsets of these components, it is possible to develop other arbitrary tools and one such example. It was built using the Eclipse Platform as one of its major components as well as a composition of other parts including the Java Development Tools and Plug-in Environment Development. The Eclipse Platform, a composition of components in itself, provides developers the benet of exibility in terms of building applications and tools. The platform is designed to be a universal tool-integration platform which makes it possible for plug-ins and other tools developed using the Eclipse platform to communicate and connect with each other. This also allows for the development of rich applications and tools with a variety of functionalities. The Rich Client Platform (RCP) is one subset of components included in the Eclipse platform. The development of general-purpose applications is made possible with the utilization of the RCP. It is composed of major components including the user interface toolkit, platform runtime and the open services gateway initiative. The components enable the platform to have an extensible user interface to the user and support plug-in architecture and development. (Beaton, 2006) (Rubel, 2006)

UI Workbench The UI workbench denes the extension points for adding new UI components. It also supplies additional toolkits namely the Standard Widget Toolkit (SWT) and the JFace for building user interfaces. In order to extend the UI workbench, the UI services are

11

structed in a way that UI plug-ins can be used to build rich client applications independent from workspace model and resource management. The workbench consists mainly of the perspectives, editors and views. The workbench provides a structure in which an application interacts with the user. From the standpoint of the users, the application window consist visually of components including the editors, views and actions which can be rearranged to suit the needs of the user in line with the task at hand. The perspectives are manifested through the selection and arrangement of these components. (Rubel, 2006)

Editors Editors are similar to le-based system tools which follow the open-save-close lifecycle but they are more tightly integrated to the workbench. Users can open, edit and save domain objects such as records, information and other data using the editors. When active, the editors can also contribute actions to workbench menus and toolbars. (Rubel, 2006)

Views Views provide information on the objects that are related to the task of the user. Likewise it also assists editors in providing information about the documents accessed and edited by the users. Views can also augment other views by providing information on selected objects. Lifecycles of views are also simpler than those of the editors because modication is faster and reects immediately in UI parts that are related to the modied objects. (Rubel, 2006)

Actions Actions are represented as commands that can be triggered by the user using UI elements including buttons, menu items and toolbar items. User commands are independently dened from their exact location in the UI which allows for the development of appropriate widgets for particular actions. This separation allows widgets to be used in several places in the UI; changing where an action is presented can be done without changing the code for the action itself. (Rubel, 2006)

Perspectives Perspectives organize elements in the UI including the views and editors in an arragement specic to the tasks of the user. There are different ways in which these elements are placed in the screen. One can have the editors and views tiled, stacked or detached on screen, depending on the preference of the user. Initially, the perspective controls view and action visibility as well as layout but the user is not limited to only that perspective. The users may opt to customize the arrangement of these components on the screen depending on their preference to better suit the task at hand. Multiple perspectives can be opened in a single window or in separate windows, depending on the preference of the user. The users also have the option of switching perspectives within the window. (Rubel, 2006)

Standard Widget Toolkit The Standard Widget Toolkit is a low-level graphics Java library containing GUI components with native implementations to hide the differences between platforms and operating systems. This allows developers to program using a single API regardless

12

of platform used. Using SWT, the developer can code and develop a consistent set of highperformance widgets regardless of the platform. Unlike the Abstract Window Toolkit (AWT) which does not provide high-level widgets such as trees and rich text and Java Swing which is limited to only emulating high-level widgets, SWT denes a common API for a number of supported window systems solving these problems. Moreover, building UI using AWT would entail having to code differently given various platforms because of its implementation directly with native widgets on all underlying systems. SWT uses native widgets for each window system whenever possible. When native widgets are not compatible on a certain platform, SWT provides a suitable emulation for them. This allows SWT to maintain a programming model consistent for all environments and also being able to show the look-and-feel of underlying native windows as much as possible. Java native libraries complete differ from each platform but the API is identical across all platforms each with distinct implementation. SWT also has other desktop features like drag-and-drop, also allowing SWT widgets to be dragged and dropped into applications not based on SWT. (Rubel, 2006)

JFace JFace builds upon the simple API that SWT provides and an easy-to-use UI abstraction layer. It is a UI toolkit that includes classes that handle common UI programming tasks and is designed to work with SWT without hiding it. JFace includes the usual UI components including dialogs, wizards frameworks, and many others; its notable features would include the viewers, actions, content providers and label providers. Viewers provide object-oriented wrappers around associated SWT components and provide a higher-level semantics as compared to SWT widgets. These viewers are congured with a content provider and a label provider. Content providers are able to translate domain changes into appropriate viewer updates and label providers produce the information string and icon for a certain widget. Viewers can also be congured with element-based lters and sorters. The clients are notied selections and events in terms of domain elements they provide to the viewers. The viewer implementation maps these domain elements and SWT widgets for ltering views and sorting when necessary. Actions are events triggered by users through UI components such as buttons, menu items and toolbar items. The separation in these UI components and actions allows for denition of these actions meaning actions can be reused in different UI components without having to change the code. (Beaton, 2006) (Rubel, 2006)

Open Services Gateway Initiative The Open Services Gateway Initiative (OSGi) is a thin layer in which multiple java-based components interact and cooperate with a single Java Virtual Machine (JVM). Focusing on the plug-in lifestyle, it allows for the installation, update and removal of plug-ins regardless of the device running without disrupting the operation of the device. Its software is composed of libraries or applications that dynamically discover and use other components. The OSGi Framework reduces memory footprint and brings about a faster startup by loading plug-ins on an in-need basis, meaning it only loads plug-ins that are needed for a particular task the user is working on. Standard components including HTTP servlets, XML, conguration, logging, security and administration plug-in compatible implementations of these are

13

available from different vendors with different optimizations. The framework adds the following functionalities to the Eclipse RCP: class-loading layer, a lifecycle layer and a service registry. The class-loading layer denes class-loading policies which is Java-based. The lifecycle layer adds plug-ins also known as bundles that can be dynamically started, stopped, installed, updated and removed. The service registry with a cooperation model for discovering bundles without having to load or execute the bundle. (Rubel, 2006)

2.4.2

Google Docs

Google Docs is a free, web-based collaborative editor offered by Google. It is one of the most popular collaborative today mainly because of its wide range of features, and also the wide range of target users that it services. It offers a word processor, spreadsheet, presentation, and form application that targets working people who tend to do paperwork together, teachers, and also students who need to work together on papers most of the time. The Google Docs word processor is a real-time editor which allows different members of the document to edit the document at the same time. Users share documents with the use of the a link. Both members and non-members of Google are allowed to become viewers or collaborators of a document. One of the problems that have to be solved in simultaneous editing is the possibility that two or more people are editing at one same spot at the same time. Since Google Docs allows collaborators of a document to edit it simultaneously, Google Docs has a conict management that will prevent such a situation. If two or more people are editing the same spot at the same time, Google Docs picks one person who gets to edit that spot, and sends out a notice to the other people that they cannot edit that area yet, as it will result to a conict. Besides plain collaboration, Google Docs offers some more features in its collaborative editor. Inside the editor, there is a spell check function that underlines a word in red if it is mispelled. There are also the usual features of an editor including changing fonts, adding bullets, highlighting, and indentation editing in its editor. Lastly, there is the comment function, which allows collaborators of the project to leave messages with their names and the time they wrote the comment in the editor. Google Docs also automatically saves documents as users type.

2.4.3

CollabEdit

CollabEdit is a free, web-based collaborative editor that is aimed for editing code. There is no need for signup in CollabEdit. To create a new document, users only have to click one button to say that they are requesting for a new document, and another to select the language that they are using. Each time a new document is made, a unique link is made, and users only need to copy and send this code to whomever they wish to share their document with. The editor is real-time collaborative, which means that collaborators of a document may edit the same document at the same time. The editor offers syntax highlighting for several languages like C, C#, C++, Java, HTML,

14

and PHP. Documents are automatically saved as users type. Its way of handling multiple users editing at one spot at the same time is different than that of Google Docs. Since no article could be founf by the proponents that suggests how CollabEdit handles this problem, a test was made. While two users are editing at the same time, there is not notice or warning about the risk of overlapping data. It seems like CollabEdit just takes the last person to edit the spot, and uses it to overwrite all other items written by other users editing the area at the same time. It can be seen just by observing the functions of CollabEdit that its target users are unprofessional progammers or programmers who would just like to discuss their code because CodeRun does not have any functionality to group documents together to make up a project.

15

Theoretical Framework

This section discusses relevant theories and concepts to be used in the course of designing the architecture of the system.

3.1

Eclipse Plug-in Architecture

The Eclipse platform is an open and extensible development environment and as such its functionality is dependent on integrated plug-ins and tools. The platform in itself does not give much end-user functionality and although the platform is able to manage resources in a generic manner, it cannot work with these resources. With the use of tool plug-ins, the platform is able to operate in relation with the plug-ins used. The tool pug-in enables to the platform to deal with these resources in a more specied manner thus providing more specic functionality to end-users. The plug-ins are the basic unit of functionality in the Eclipse platform, it determines whether the platform operates as an IDE or as a general-purpose application. There are many plug-ins made available by the Eclipse foundation but the users have the option to develop and design plug-ins on their own using the Plug-in Development Environment (PDE). The PDE is a project of the Eclipse Foundation which provides tools to create and develop plug-ins. (Beaton, 2006) Plug-ins are coded in Java. Developed and Delivered separately, small tools can be developed using plug-ins whereas complex tools are a composition of plug-ins. Some plug-ins do not contain code, these plug-ins are used for online help and are in the form of HTML pages. Except for the Platform runtime, all components that provide the Eclipse platform its functionality are located in plug-ins. The plug-ins ability to connect with other plug-ins is manifested through its interconnection model. The interconnection model of plug-ins is dened by the ability of the plug-ins to connect with other plug-ins using a manifest le and extension points. Typically, a plug-in contains a manifest le, a Java Archive (JAR) library, some read-only les and other resources. These contents are located in a directory in a le system or at a base URL on a server. The manifest le contains information uniquely identifying the plug-in and its version. It also denes how plug-ins interact and work. The components of the platform are located in the plug-ins. Since the Eclipse platform is an extensible platform, new tools or plug-ins may be integrated in order to add in functionality. The platform runtime will be the one responsible for discovering these new tools in order for it to communicate with other plug-ins when necessary. (Beaton, 2006) (Rubel, 2006) As one of the major components of the Eclipse Platform, the plug-in architecture of Eclipse is considered in the development and building of the system architecture.

3.1.1

Platform Runtime

The platform runtime is illustrated in Figure 3.1. The platform runtime discovers plug-ins through the use of extensions and extension points. Plug-ins declare how they extend to other plug-ins and vice versa, this as well as other information regarding the plug-in are logged in

16

an in-memory registry for plug-ins during startup. Other details including the names of the extensions points, the total number of plug-ins and any errors encountered are also logged into the registry. To reduce memory footprint of the application and to achieve faster startup, the platform runtime dynamically determines which plug-ins are to be used specic to a task. The runtime is implemented using the Open Gateway Services Initiative (OSGi) framework and the framework determines which plug-ins are available when an application is running. (Rubel, 2006)

Figure 3.1: Eclipse Platform Runtime

3.2

Google AppEngine

Google AppEngine is a platform for developing and hosting web applications. It lets users run their web applications on the Google infrastructure. With Google App Engine, users do not need to maintain any servers; they just need to upload the application, and the application is ready to serve its users. Users of the Google AppEngine can use their own domain name, or they can opt for a free sub-domain name on the appspot.com domain. Google AppEngine supports applications written in several languages including Java and Python. With its Java runtime environment, users can build their apps using standard Java technologies like the JVM, Java Servlets, the Java programming language, or JavaScript. There are not set-up costs nor any recurring fees in Google AppEngine. Users only need to pay for what they use. In fact, the rst 500MB used by the application, along with having 500 million page views a month are absolutely free. When users have surpassed their free limits, their bills are calculated by the gigabyte; therefore, users have the power to control the amount of resources that they use, making it possible for them to stay in budget. Google AppEngine was chosen as the server for the research as there are still no existing web-based IDEs that support deployment of web applications to it. (Code, 2009b)

17

Figure 3.2: jdocong.xml

3.3

Google AppEngine Datastore

The Google AppEngine Datastore is not a relational database like MYSQL. Designed with web applications in mind, the Google AppEngine Datasore is able to execute multiple operations at one transaction, and is able to roll back an entire transaction when one of the operations in it fails. This is especially useful for distributed web applications as users may be accessing or manipulating the same data object at the same time. In Java, Google AppEngine implements the Java Data Objects (JDO) and Java Persistence API (JPA) interfaces for modelling and keeping data. These interfaces include mechanisms for dening data objects and for performing queries. Making use of Google AppEngine Datastore also involves the DataNucleus Access Platform, which is an implementation of JDO and JPA, and also has an adapter to Google AppEngine DataStore. JDO makes use of annotations on Java classes to describe how instances of classes are stored in the datastore. Entities are recreated as instances when queried from the datastore. JDO also includes a query interface called JDOQL which can be used to retrieve entities as instances of a class or a data object. Since Google AppEngine was chosen as the server for this research, Google Datastore must be chosen as the database server for this research as AppEngine only supports Google Datastore. Looking into the actual implementation of Google AppEngine Datastore on code, it will require users to have an XML le in the meta-inf folder in the project called jdoconfig.xml. This XML le will tell the DataNucleus Access Platform to use Google AppEngine Datastore as the backend for the JDO implementation. The jdoconfig.xml le should have the following contents shown in Figure 3.2. To use JDO, the JDO and DataNucleus AppEngine plugin JAR les must be in the apps war/web-inf/lib/ directory. JDO allows users to store Java objects into any datastore given a JDO-compliant adapter such as DataNucleus Access Platform. JDO classes represent objects or metadata in the datastore, while instances of the classes are the information to the metadata. When creating JDO classes, Java annotations are used to describe how instances are to be saved in the datastore, as well as how these are retrieved from the datastore. DataNucleus Access Platform associates data classes to JDO implementation, called enhancing the classes. This can be performed through the command prompt by typing the following: java -cp classpath 18

Figure 3.3: JDO Class com.google.appengine.tools.enhancer.Enhance class-les. An example of a segment in a JDO class is illustrated in Figure 3.3. This class has three properties for a Greeting: author, content and date. These three private elds are annotated with @Persistent to tell the DataNucleus to store these elds as properties of objects in the AppEngine Datastore. There must also be getters and setters for each property which will be used by the application - not the JDO. Aside from the properties, there should also be a eld name called Key, which is annotated as both @Persistent and @PrimaryKey. The AppEngine datastore has a notion of entity keys, and can represent keys in several different ways on the object. The key class represents all aspects of AppEngine datasore keys. One of these includes a number reprenting an ID that is set automatically and uniquely. JDO also supports relationships between entities like one-to-one or one-to-many. Each request to the datastore must create a new instance of the PersistenceManager class. This can be done using the PersistenceManagerFactory. It takes time for the PersistenceManagerFactory to initialize; however, users only need to instantiate it once. This can be accomplished by setting instance of the PersistenceManagerFactory in a static variable in a sin-

19

Figure 3.4: Queries executed at once gleton wrapper. For example, when saving an instance of a JDO class, the PersistenceManager class must be instantiated rst using <local persistance class variable>.get().getPersistenceManager(). Then, users must make use of the makePersistent() class of the PersistenceManager to save the instance to the datastore. The makePersistent() method has one parameter, which is the instance of the JDO class that is going to be saved into the datastore. JDOQL queries on the other hand, are normally found in the JSP classes of an application. To prepare a query, an instance of the PersistenceManager class must be obtained, followed by using the newQuery() function. The newQuery() function has a parameter which contains the string of the query to be executed. To execute the query, the execute() function of the Query that the newQuery() function returns must be called which returns a List<> of objects of the result type. The JDOQL syntax is much like SQL syntax with a few minor differences. For example, to select all instances in a given class, the following JDOQL query must be entered: select from class name. To lter the returned instances, the query should be something similar to the following: select from class name where property == value. JDOQL also has different functions such as ordering and ranging queries, among others. (Code, 2009a)

3.4

Java Data Object Query Language

Java Data Object (JDO), which is used by AppEngine Datastore, includes a query language for retrieving objects from a set of criteria. This query language is called JDOQL. It is similar to SQL, but is more appropriate to use for object-oriented databases like AppEngine Datastore. There are two different ways of constructing a query using JDOQL. One of these ways is specifying the complete query in a string. The way is specifying parts of the query by calling methods on the query object. As was discussed in Chapter 3.2, JDOQL queries are prepared by rst obtaining an istance of the PersistenceManager class, which is declared static. The obtained PersistenceManager instance is then used to call the newQuery() function, which prepares a query and returns a Query which can then be used to execute. Figure 3.4 shows how to specify the complete query at once. Figure 3.5, on the other hand, shows how to specify the query part by part. It is shown that the newQuery() function was used to only specify the class name with which the query is targeting. Next, the Query instance obtained using the newQuery() was used to set the lter of the query as well as to specify the ordering.

20

Figure 3.5: Queries built part-by-part Besides ltering and ordering, there are more functions that can be used in JDOQL such as ranging, or using the Extent class. The Extent class represents every object in the datastore of a particular object. It can be obtained using the getExtent() function of the PersistenceManager class, with the object name as the parameter. However, there are certain restrictions with JDOQL. One of these restrictions is that inequality lters are allowed on one property only. (Code, 2009a) Inequality lters include <, <=, >=, and >. For example, this query is allowed: SELECT FROM Person WHERE birthYear >= minBirthYearParam && birthYear <= maxBirthYearParam This query, on the other hand, is not allowed, as inequality lters are used in two different properties: SELECT FROM Person WHERE birthYear >= minBirthYearParam && height >= minHeightParam Another restriction is properties in inequality lters must be sorted before other sort orders. For example, this query is valid: SELECT FROM Person WHERE birthYear >= minBirthYearParam ORDER BY birthYear, lastName While this query is not: SELECT FROM Person WHERE birthYear > minBirthYearParam ORDER BY lastName, birthYear

3.5

JavaScript Object Notation

The JavaScript Object Notation (JSON) is a lightweight text-based computer data interchange format and is used for representing simple data structures and associative arrays (called objects). It is often used for serialization and transmitting structured data over the network and its main application is in AJAX web programming, serving as an alternative to XML. Though 21

it is based on a subset of JavaScript with which it is commonly used with, it is considered to be a language-independent data format. JSON is built on two structures represented either as a collection of names or values, more commonly referred to as an object in most programming languages or an ordered list of values, more commonly referred to as an array in most programming languages. These universal data structures are virtually supported by most programming languages in one form or another which is why these structures were basis for the data interchange format. (JSON, n.d.) The basic data types supported by JSON are Number (integer, real, or oating point) String (double-quoted with backslash escaping) Boolean (true or false) Array (an ordered sequence of values, comma-separated and enclosed in square brackets) Object (a collection of key:value pairs, comma-separated and enclosed in curly braces) null

3.5.1

JSON Object

An object is an unordered set of name and value pairs. The JSON object as seen in Figure 3.6 starts with a left brace { and ends with a right brace }. Each name and value pair is separated by a comma within the braces. Each name is followed by a colon and then its value.

Figure 3.6: JSON Object

3.5.2

JSON Array

An array is an ordered set of values. The JSON array as seen in Figure 3.7 starts with a left square bracket [ and ends with a right square bracket ]. Within the square brackets contain the values separated by commas ,.

Figure 3.7: JSON Array

22

3.5.3

Values

A value in JSON can either be a string in double quotes, a number, an object, an array or it can also be boolean values true or false and null. The structures in Figure 3.8 can be nested:

Figure 3.8: JSON Values

3.5.4

Strings

The strings in JSON is similar to that of those strings in C programming or Java, as seen in Figure 3.9. It is comprised of zero or more unicode characters enclosed in double quotes. For special characters, a backslash escape is used to indicate that its a special character. Characters are represented as single character strings as well.

Figure 3.9: JSON Strings

3.5.5

Numbers

Numbers in JSON are also similar to the numbers in C programming and Java, as seen in Figure 3.10. The only difference would be that the octal and hexadecimal formats are not used in JSON numbers.

23

Figure 3.10: JSON Numbers

3.6

Dojo Toolkit

Dojo is an open-source JavaScript toolkit that is used for developing web appli- cations. Components in the Dojo Toolkit are written in JavaScript, HTML, and CSS. These components are aimed to be encapusalted and reusable components for widgets. The Dojo Toolkit is divided into three main components: the Dojo core, Dijit, and Dojox. Its responsibilities include manipulating the Cascading Style Sheets (CSS), and supporting animation features and drag-and-drop functional- ity, among others. Dijit is Dojos widget library. Some widgets that it offers include menus, trees, tabs, closable tabs,sliding tab containers, and other different kinds of containers which are useful for developing the user interface of an IDE. Lastly, Dojox is a container for developing extensions to the Dojo Toolkit. It is a place to store and test new ideas to add into the toolkit. Some widgets include syntax highlighting for some languages like HTML, JavaScript, CSS, PHP, and it also includes Fisheye, which is a animated toolbar, among others. (Patil, 2009) Dojo is also packaged with Dojo Ofine. It is built on top of Google Gears, a plugin from Google that basically helps web applications work ofine. Some of the functions that Dojo Ofine offers are: an ofine widget that provides network feedback, sync messages, and ofine instructions, among many more a sync framework that stores actions done while ofine and synch them with a server once users are back ofine an automatic network and application-availability detection that determines if the users are ofine or not a slurp() method that automatically scans the web page to gure out which resources users need ofine, like images, stylesheets, scripts, and the like, so that users do not have to manually maintain which resources should be ofine Dojo Storage, which is a hashtable for storing ofine data that aims to be easier to use than the database module that Google Gears provides; in the background, it saves its data into Google Gears integration with the rest of Dojo 24

3.7

Byte Code Engineering Library

The Byte Code Engineering Library or BCEL is intended to provide a way to analyze, create, or manipulate binary Java class les (bytecode). Classes are represented by objects which contain the symbolic information of a given class, which includes the methods, elds, and byte code instructions.

3.8

CodeMirror

CodeMirror is a JavaScript library that can be used to implement an editor in- terface that supports code content for computer programs such as HTML, other markup languages and many other programming languages. CodeMirror supports syntax highlighting for languages that have parsers such as JavaScript, HTML, XML, CSS and others. CodeMirror provides an editor interface that can be con- gured depending on the need of the users.

3.9

Java Reection API

The Java Reection API represents the classes, interfaces, and the objects in the current Java Virtual Machine (JVM). Additionally, the reection API is used by programs which require the ability to modify the runtime behavior of the application running in the JVM. This feature of the API is rather advanced and should only be used by developers who have a good grasp of the fundamentals of the language. The extensibility features of the reection API allows for the use of user-dened external classes in applications. By instantiating extensibility objects using their fully-qualied name, the application may make use of the external class. The API also aids visual development environments by provide information to aid the developer in writing the correct code. For debuggers and test tools, reection can be used to systematically call a discoverable set of APIs dened on a class.

3.10

Java Jar API

The Java Archive le is a platform-independent le format that aggregates nu- merous les into one. atform-independent le format that accumulates multiple les into one. Many Java les such as classes and images can be bundled in a JAR le. The JAR format also supports compression, which reduces the aggregate le size. A JAR le is basically a zip le that contains an optional META-INF directory. It can be created by the command line jar tool or by using the java.util.jar API in the Java platform, and there is no restriction in naming JAR les. JAR les are not just simple archives of java les or classes; rather, they are building blocks of an application. The META-INF, if exists, contains the package and extension conguration data, including security, versioning, extension and services.

25

3.11

Subversion

Subversion (SVN) is a free or open-source version control system initiated by Collabnet Inc back in 1999. It fosters collaboration by managing les, directories, and the changes made to them, such that it allows multiple users to manage the same set of data from different locations at the same time. Subversion also allows its users to recover older versions of their data, or examine the history of how their data was changed. Some of its features are: Direct Versioning - Subversion uses a virtual le system to allow directory versioning such that users can track changes of their directory. True Version History - Subversion allows users to rename or copy their resources so that these resources can be viewed as a new object. Atomic Commits - The concept of atomic commits is where a users commit is either entirely committed or not. This means that partial commits is not allowed. If a problem happens while a user is committing, then the entire process of committing is aborted. Version Metadata - Versioned metadata is the ability to apply key-value tuples to a versioned object. Metadata are also called properties and are versioned just like the objects to which they are applied.

3.11.1

Choice of Network Layers

The access layer of subversion is abstracted allowing for multiple ways to access a reposity. This abstraction allows users to develop their own access method; the users may opt to use existing methods as well. This exibility gives the users preferrence in access methods, depending on what they are more at ease to work with. Another layer of exibility is the use of WebDAV by subversion. This allows for repository interaction over http/https which usually poses no problem when accessing behind a rewall and or proxy.

3.11.2

Consistent Data Handling

Subversion uses a differencing binary algorithm when storing version history; it uses the same process for versioning text and binary les. Subversion stores the les and differences the same on the server regardless of the type. Additionally, it sends differences across the wire in the same manner also regardless of le type.

3.11.3

Efcient Branching and Tagging

Subversion uses something similar to a hard-link on the server side when a branch or tag is created, by this method, subversion is able to take only very small amounts of time and storage regardless of le type.

26

3.11.4

Hackability

Maintainance, extension and integration of subversion into other projects is made easier since it has its own project built with a well-dened C API. Subversion also has bindings for many other languages including Java, Perl and Python.

3.12

SVNKit

SVN is a programmatic solution to use subversion in Java applications. Some of its major features are: Repository access over http(s), svn, svn(+ssh), and le protocols Working copy operations Repository administration which includes the create, load, dump, and replay operations Does not require native binaries Native Subverion congurations are used by default Includes Java Subversion command line client Latest version supports Subverion 1.6.5.

27

The CtrlSpace Platform: A Web-based Integrated Development Environment

This section provides the overall specications and functional requirements of the software to be developed.

4.1

System Overview

CtrlSpace is a platform that provides developers with a web-based multi-user integrated development environment for web applications. The environment is multi-user in the sense that there can be many users working on a single project. The platform also allows users to manage the le system that their projects use with the use of explorer tools in the user interface. Managing the le system means being able to perform basic IO operations on the le system of a workspace, which includes creating, renaming, deleting, copying and moving les and folders. The platform contains a collaboration tool which enable users to work on a single project at the same time. Group projects are collaborated through the use of an access control mechanism. Once a project has been completed, users of the platform can immediately deploy their projects onto Google AppEngine.

4.2

System Objectives

1. To provide a multi-user IDE for the development of web applications supporting collaboration through version control 2. To incorporate a plug-in architecture for certain components of the IDE 3. To provide syntax highlighting and auto complete functions to aid users in coding 4. To provide a facility for users to deploy their projects onto a remote server 5. To allow the users to manage their databases using basic CRUD functions from the user interface 6. To provide a way to maintain the state of the IDE for each user across sessions

4.3

Scope and Limitations

The CtrlSpace platform provides developers with their own online workspaces, and as such, they will need to have their own accounts to use the IDE. However, the security of the workspaces is not the main focus and concern of the system.

28

The system will initially only support Google AppEngine projects. This includes editor support for the Java SE 6 (or Java 1.6) specication, and HTML 4. Other types will be opened as text and will not be parsed as no parser exists for them. Support for more languages and project types can be added through plugins. For the size and count, it is also bound by the server resources. The system supports debugging in the form of identifying compile-time errors. Only the compile-time errors generated by the Java Compiler API will be presented to the user. Run-time error debugging will not be supported as these problems are generally errors in the code or logic of the user, and can be difcult to identify or trace, because the problems can be of many types. Therefore, the system does not support adding breakpoints, variable watching, proling, and step-in and step-out features. The number of users that the IDE can support will depend on the server. The database is designed to support an unlimited number of users, projects, and an unlimited number of users per project, however, this can be bound by physical server resources such as disk space and memory. With the plug-in architecture, developers will be able to add new functionalities to the IDE. On the client side, APIs for extending the UI by creating additional popup menus, support for more explorers, support for new language parsers in the editors, and support for auto-complete mechanisms will be provided. No API support for visual editors will be provided. On the server side, the API exposed will only be that of support for a default project structure, an interface for a debugger, and an interface for a deployer, which are the main components of a project type. This research will focus on making the IDE compatible on Mozilla Firefox and Google Chrome only. The resulting web application will be displayed by default on a new browser tab or window of the same browser that the IDE is running on. Users can copy the URL of the web application on another web browser should they wish to display the web application on another browser.

4.4

Architectural Design

This section presents the internal design of the system. Figure 4.1 presents the complete architecture of the system.

29

30 Figure 4.1: CtrlSpace Architecture

4.4.1

System Structure

The system structure is described by several structures which are either represented physically or logically. These structures describe the organization of the IDE itself, as well as the projects that are created from it.

Platform File Structure The Platform File Structure(PLATFORM ROOT) simply contains all the resources that are served on the web which is needed by the end user to run the IDE. This structure contains the complete Dojo Toolkit package, the CtrlSpace scripts, plugins, CSS stylesheets, images, and HTML les as well as the Servlets that the browser communicates with to send and retrieve information. A default Platform File Structure is composed of the following: %PLATFORM ROOT%/WEB-INF - Folder containing the web.xml deployment description of the system which denes the Servlets, the compiled Java classes and libraries used by the system, and the plugins that are discovered and loaded by the system. %PLATFORM ROOT%/js - Folder containing the both the Dojo Toolkit package and the CtrlSpace scripts organized into folders representing the namespace of each module. For example, the ctrlspace.codemirror.Editor script can be found in %PLATFORM ROOT%/js/ctrlspace /codemirror/Editor.js. %PLATFORM ROOT%/styles - Folder containing all the CSS stylesheet used by the system. %PLATFORM ROOT%/images - Folder containing all the images used by the system. %PLATFORM ROOT%/ctrlspace.jsp - The main IDE le which loads up all the needed resources %PLATFORM ROOT%/registration.jsp - The registration page from which the users can sign up for their own account. %USER DEFINED%/Plugins - Folder containing all the server-side plugins to be loaded by the Plugin Loader. %USER DEFINED%/app-engine-sdk - Folder containing the Google App Engine Java SDK. %USER DEFINED%/CtrlSpace Data - Folder containing all the le data that the Platform generates, which is segregated into: %USER DEFINED%/CtrlSpace Data/CtrlSpace Project Repository - Folder containing all the projects. The sub-directories under this folder represents one project File Structure. %USER DEFINED%/CtrlSpace Data/CtrlSpace VCS Repository - Folder containing all the version control repositories of projects. The sub-directories under this folder represents one Version Control File Structure, regardless of how many users are using it.

Project File Structure The Project File Structure (PROJECT ROOT) refers to the physical structure that represents a project. The Project File Structure exists outside PLATFORM ROOT to ensure that it is inaccessible via the web, limiting access only through the IDE. The default le structure for a Google App Engine project is composed of the following les and folders: 31

Figure 4.2: CtrlSpace default new project Version Control File Structure The Version Control File Structure refers to the physical structure that contains a projects SVN repository. This le structure is generated by the SVN server and should not be modied by any means. The structure is not directly in a one-to-one correspondence of a specic version of a le-to-a-le and is not human-readable. This is because SVN uses the Berkley DB format to represent its repository, and the format is abstracted away from the users through the Repository API.

4.4.2

Database Backend

All information regarding users, projects, workspaces and workspace states are stored inside the database backend. The system will be using MySQL version 5.1 for its backend database. An index of the les will be stored in the database backend, associated with the corresponding project and the user that created them.

4.4.3

Data Structures

The system uses several data structures to represent the actual elements of a development environment. These data structures are used by the different server-side components and have a direct translation to JSON for use on the client-side. Figure 4.3 shows the different data structures.

32

33 Figure 4.3: Class diagram and ERD

Attribute iconName extension parserFiles styleFiles isFolder isOpenable templatePath

options

Table 4.1: FileType data structures and descriptions Description The iconName attribute is the name for the css class w/ the background icon representing that le type. The extension attribute is the le extension of the le type. For example: for Java classes, .java is used and in HTML les, .html is the le extension. The parserFiles attribute denes the parser les that CodeMirror will load. CodeMirror is dened in Section 4.6.3. The styleFiles attribute denes the stylesheets that CodeMirror will load. The isFolder attribute gives a true or false value that indicates whether the instance of this object is a folder or not. The isOpenable attribute gives a true or false vcalue that indicates whether the instance of this object is openable or not. The templatePath is the path pointing to the le with which the template for a specic le type uses. Whenever a user creates a new le, the new le created is written with the contents of the template le. The options attribute is a Map that contains the additional information needed for specic le types.

FileType The FileType data structure represents a le type. It has two attributes: iconName and extension. These are further explained in 4.1

FileUnit The FileUnit data structure represents a le, either physically stored on disk or represented through other means such as a database record or a space in memory. It has twelve attributes namely: leId, creatorId, path, leName, label, content, type, dateCreated, lastModied, projectId, children and isOpenable. These are further explained in 4.2

ProjectUnit The ProjectUnit data structure represents a project. It has eleven attributes: projectId, ownerId, title, description, nature, path, dateCreated, les, sourcePaths, projectOptions, and iconClass. These are further explained in 4.3

User The User data structure represents a user of the system. It has eight attributes: id, username, email, rstName, lastName, lastLogin, lastIp, isLogged. These are further explained in 4.4

4.4.4

Message Exchange Pattern

In order for the client side of the system to communicate with the server side components, there has to be a message exchange pattern that both sides have to follow. The system uses the Bayeux protocol to communicate, and the implementation of the protocol is provided by Dojo Toolkit as a JavaScript API for the client side and a Java API for the server side. 34

Attribute leId creatorId path leName label content type dateCreated lastModied projectId children

isOpenable

Table 4.2: FileUnit data structures and descriptions Description The leId attribute is the id unique to the leUnit. The creatorId attribute is the id unique to the owner of the leUnit. The path attribute is the location of the le, relative to the projects location. The leName attribute is the name of the le. The label attribute is the label that would appear when the le is viewed on the client side (project tree, editor titles) The content attribute is where the contents of the le is stored. The type attribute is the type of the le represented as a FileType object. The dateCreated attribute is the date when the user created the le. The lastModied attribute is the date and time the le was last edited by the user. The lastModied attribute is the date and time the le was last edited by the user. The children attribute is the children of the le in terms of its structure in the repository. The children attribute is an empty list if the les isFolder attribute is false, and contains the directorys children if the isFolder attribute is true. The isOpenable attribute is a boolean variable that indicates whether the le can be opened or not.

Attribute projectId ownerId title description nature path dateCreated les sourceFiles projectOptions iconClass

Table 4.3: ProjectUnit data structures and descriptions Description The projectId is the Id assigned to the project in the database backend. The ownerId is the is assigned to a registered user of CtrlSpace. The title is the name of the project. The description attribue contains the description of the project. The nature attribute is the project type. An example would be Google App Engine Project. The path attribute represents the path wherein the project is located. The dateCreated attribute shows the date the project was created. The les attribute is a list of FileUnit associated with the project. The sourceFiles attribute is a list of relative paths of all les from the serverside. The projectOptions attribute is a Map of values that contain information needed that are specic for that project nature. The iconClass attribute represents the name of the icon corresponding to the nature of the project.

35

Attribute id username email rstName lastName lastLogin lastIp isLogged

Table 4.4: User data structures and descriptions Description The id attribute is the id assigned to the registered user of the system. The username attribute is the registered username of the user. The email attribute is the email address that the user provided upon registration. The rstName attribute is the rst name that the user specied. The lastName attribute is the last name that the user specied. The lastLogin attribute shows the last date and time that the user have logged in into the system The lastIp attribute shows the last IP detected from the user. The isLogged attribute shows a true or false value that indicated whether a user is logged in or not.

Server side The server creates Services, which are classes that extend the BayeuxService superclass that allows the system to listen to message channels and respond to events from these channels accordingly. An example of a Service is seen below, which is the CommandService used in the system: public class CommandService extends BayeuxService { public CommandService(Bayeux bayeux) { super(bayeux, "CommandService"); subscribe("/service/commands", "processRequest"); } public void processRequest(Client remote, Message message) { ServiceHelper helper = new ServiceHelper(getBayeux(), remote, message); ICommand iCommand = helper.getCommand(); iCommand.execute(); } } The class extends the BayeuxService class, which should make a call to the constructor by passing a Bayeux object and a String identier, in this case CommandService. This class is instantiated during the initialization phase of the servlets, in which the Bayeux object can be obtained from by fetching the attribute from the ServletContext: Bayeux bayeux = getServletContext().getAttribute(Bayeux.ATTRIBUTE); new CommandService(bayeux); After the call to BayeuxServices constructor, the service subscribes to one or more channels, in this case /service/commands, and maps the channel to the processRequest method, which should have a signature of: void methodName(Client remote, Message message); 36

Where the rst parameter represents the client which sent the message, and the second parameter represents the message sent. Inside the processRequest method, the CommandService passes the Message along with the Client to a ServiceHelper class, which is able to determine the associated command with the service. The ServiceHelper class is beyond the description of the Message Exchange Pattern. Every time a service receives messages on a channel, it can respond to the client who sent the message as well as send a message to the whole channel. To send a message to the client, the service can make a call to the deliver() function of the Client class, which can be used as follows: public void processRequest(Client remote, Message message) { remote.deliver(fromClient, channel, message, messageId); } The rst parameter of the deliver function is a Client object which represents the source of the message to be delivered to the remote client. This parameter can be null, which means that it is the server who sent the message. The channel parameter is a String which tells the remote client which channel the message is being sent to. The original source channel can be obtained by calling message.getChannel() on the message object. The third parameter is the message to be sent, which can either be a String or a Map of String to Objects, which is converted into a JSON object. The last parameter is the message ID, which can normally be set to null for the server to auto-generate the ID. To send a message to a channel, the service can make a call to the publish() function of the Channel class, and the Channel can be obtained by calling Bayeux.getChannel(channel name). The publish function can be used as follows: public void processRequest(Client remote, Message message) { Channel ch = getBayeux().getChannel(message.getChannel()); ch.publish(fromClient, message, messageId); } The rst parameter of the publish function is a Client object which represents the source of the message to be delivered to the target channel. This parameter can be null, which means that it is the server who sent the message. The second parameter is the message to be sent, which can either be a String or a Map of String to Objects, which is converted into a JSON object. The last parameter is the message ID, which can normally be set to null for the server to auto-generate the ID.

4.4.5

Client side

The client side uses the dojox.cometd package, provided by Dojo, which allows the clients to deliver messages to channels, as well as to listen to events from these channels.

37

The dojox.cometd package is initialized by the ctrlspace.IDE JavaScript class and a reference to it can be obtained by making a call to the getCometD() function of the IDE object, as follows: var cometd = IDE.getCometD(); // perform cometd functions here. The cometd object performs several functions, including initializing a handshake with the server, listening and publishing to channels, and disconnecting from the server. The handshake function initializes a connection to the server, providing credentials which the server must validate against. The client must listen on the /meta/handshake channel in order to receive messages related to handshake status. Upon failure of validation, the server responds with a failure message, which advices the cometd object to not perform another automatic handshake. Upon success of validation, the server responds with a success message, and the client can perform operations based on these conditions. The following code demonstrates how the handshake is performed: var cometd = IDE.getCometD(); cometd.addListener(/meta/handshake, function(message) { if (message.success == true) { // Handshake success! } else { // Handshake failed } });

The client can listen to unlimited number of channels, however, it will not receive any message until it has completed a successful handshake. Just the same, no matter how many messages the client publishes to a channel, the messages will not be sent until the client completes a successful handshake. The following code demonstrates the publish function, which requests a call to a server-side command through the CommandService. The CommandService, as seen in the server-side section of the Message Exchange Pattern, listens on the /service/commands channel. This is where the client should publish the message: var cometd = IDE.getCometD(); var listenChannel = /service/commands/ + IDE.getClientID() + /ctrlspace.IDE; cometd.addListener(listenChannel, function(message) { if (message.success == true) { // Load the workspace! } else { IDE.getConsole().error("Workspace failed to load."); } }); 38

cometd.publish(/service/commands, { command: load-workspace, replyTo: listenChannel }); The code above makes a request to the CommandService to execute the command associated with the IDE load-workspace, which is the LoadWorkspaceCommand. Another parameter is given, replyTo, which is used by the LoadWorkspaceCommand to reply to. The server-side services dont necessarily have to reply to the same channels they receive messages from. In this case, the LoadWorkspaceCommand replies to the same channel the cometd object added a listener to. When the message from the server arrives, the client then evaluates the status of the request based on the message, and performs actions accordingly.

4.4.6

Server-side Components

This section discusses the different server-side components of the IDE. It discusses their purpose and usage in the system.

Plugin System CtrlSpace incorporates a plugin architecture for certain components of the user interface and the server-side application. The plugins for the user interface and the serverside application have their own specied formats, respectively. This is because user interface plugins are client-side and can only run client-side scripts, while server-side application plugins can only run server-side programs.

Loader The server-side plugin loader is responsible for loading the plugins on the server-side using the system class loader. It scans the plugin directory specied in the server conguration for .jar les that provide additional functionality to the IDE. These .jar les contain different classes such as new Commands or classes that register new File Types, together with a Plugin manifest le which is discussed in the Plugin section. The plugin loader is started during the servlet context startup event which is listened to by a ServletContextListener. public static URLClassLoader csClassLoader; public void contextInitialized(ServletContextEvent event) { ServletContext context = event.getServletContext(); // Scan the plugins directory PlatformConfig config = PlatformConfig.getPlatformConfig(); String pluginDirectory = (String) config.get("storage.plugins"); Map<String, URL> plugins= scanDirectory(pluginDirectory); URL[] jars = getURLs(plugins); csClassLoader = new URLClassLoader(jars, ClassLoader.getSystemClassLoader()); 39

Iterator<String> it = plugins.keySet().iterator(); while (it.hasNext()) { String activator = it.next(); csClassLoader.loadClass(activator); IActivator activeClass = (IActivator) Class.forName(activator); activeClass.activate(); } } Scan directory traverses the plugin directory, reads each .jar les manifest and returns a Mapping of the Activator classes fully qualied name to the URL of the plugin .jar. When this mapping is returned, the getURLs() function simply gets all the URL values from the mapping and returns it as an array, passing it to the constructor of a new URLClassLoader, signifying that this class loader will try to nd the classes that it needs from the specied .jar URLs. After the URLClassLoader is instantiated, the Activator classes are instantiated by iterating through the plugins map, and passing the fully qualied names to the loadClass function of the URLClassLoader. When the loadClass function is called, the Activator class les are loaded into the JVM, and they are then instantiated by calling the Class.forName function. Since Activator classes all implement the IActivator interface, they all have the activate() function which can be called for the plugins to perform any initializations that they might need. These initializations may include registering new File Types, Commands, Services, as well as performing database operations that the plugin might need. The URLClassLoader is exposed as a public static attribute, thereby allowing plugins to instantiate other plugins by using this class loader instead of the default system class loader. By using this class loader, other plugins are able to nd and load the classes contained inside the plugin .jar les.

Plugin A plugin is a collection of Java classes that perform related operations. The plugins can also expose its components to other plugins so that it can be reused. To better describe what a plugin does, take the Google App Engine plugin which is provided with the system. The Google App Engine plugin is composed of an IProjectNature, which is the equivalent of having your own project type, several helper classes that perform tasks related to Google App Engine such as registering the Java Class, Enum, and Interface le types, Processor classes that use the AddFileCommand provided by another plugin, as well an Activator class which is called when the plugin is loaded in order for the plugin to perform initialization tasks such as registering the le types and creating an options table to associate ports and Google accounts with projects.

Manifest File The plugin manifest le is a short JAR manifest le which contains information about the plugin. The manifest le simply contains the Author, Name, and the Activator that it uses to initialize the plugin. Manifest-Version: 1.0 40

Plugin-Author: CtrlSpace Plugin-Name: Google App Engine Plugin Plugin-Activator: com.google.appengine.Activator The manifest le is read by the scanDirectory function outlined in the Plugin Loader section, by using the Java JAR API. JarFile jar = new JarFile(jarURL); Manifest mf = jar.getManifest(); Attributes attr = mf.getAttributes(); String pluginName = attr.get("Plugin-Name"); From the following code, the .jar le is simply read by using the JarFile object, and the Manifest le is read by calling the getManifest() function. Subsequently, attributes are obtained by using the getAttributes() function of the Manifest object, which is actually a Mapping of keyvalue strings.

Activator The Activator is a class within a plugin package that implements the IActivator interface, providing a single function, activate() that performs initialization procedures for a plugin. The Manifest le may or may not specify an Activator class for the plugin, and that determines whether the plugin requires initialization procedures or not. In case the Activator class is specied, it is loaded using Java Reection, as seen in the Loader code: IActivator activeClass = (IActivator) Class.forName(activator); activeClass.activate(); On some plugins, such as the Default Web and Google App Engine plugin, the Activator class registers the le types provided by the plugin to the system. For example, the Google App Engine plugin Activator class registers le types by calling a method from another class, JavaTypes.registerFileTypes() from the activate() function.

Plugin Classes Plugin classes may vary from Commands to Services, as well as any type of Java class that may perform operations needed by the plugin.

API and Interfaces The system provides Interfaces that allow developers to extend the functionality of the IDE by following conventions. Although these interfaces may be limited, almost everything can be done by using them, from responding to client command requests, to pushing data to the clients from the server, to creating new project types. IProjectNature Interface - this interface allows developers to create their own project type which is associated with a project upon creation. The interface provides standard functions that the ProjectManager calls whenever a function related to modifying projects is called. These are further explained in 4.5 41

Table 4.5: IProjectNature Interface functions and description Function ProjectUnit getProject(ProjectUnit projectUnit) throws Exception; description ProjectUnit createProject(ProjectUnit projectUnit, Map<String, Object> options) throws Exception; FileUnit openFile(ProjectUnit projectUnit, String path) throws Exception; FileUnit saveFile(ProjectUnit projectUnit, String lePath, String contents) throws Exception; Process run(ProjectUnit projectUnit, Map<String, Options> options) throws Exception; void deploy(ProjectUnit projectUnit, Map<String, Object> options) throws Exception; void addFile(ProjectUnit projectUnit, FileType leType, String leName, String leLocation, Map<String, Object> leOptions) throws Exception; Description This function creates a project specied by the projectUnit parameter. The map of options are for additional information specic the the project nature of the project created.

This function opens a le specied by the path parameter. The path is relative to the ProjectUnits path.

This function saves a le specied by the user. The contents of the le is contained in the contents parameter. The lePath parameter is the path to which the contents must be saved. The lePath is relative to the projectUnits path.

This function runs the project, which is represented by the projectUnit. The map of options are for additional information specic the the project nature of the project created.

This function deploys a project, which is represented by the projectUnit parameter. The options parameter contains information needed specic to the project type deployed. For example, Google App Engine require the registered email address and password of the developer to deploy Google App Engine application. This function is called to create new les. The projectUnit identies to which project the new le will be created. The leType will dene which type of le is to be created. The leName indicates the desired name of the new le. The leLocation is the path in the project to which the le will be created. Lastly, the leOptions are additional options the developer wants to add in including templates.

Command Interface - The system provides interface that allows developers to dene a

42

command that can be called from the server or client side. Having a command interface exposed allows the developers to create reusable commands which can be used by other plugins. The ICommand interface only provides a single function, execute(), which performs the actual task. ICommand is usually implemented by a more useful class which allows the passing of parameters to the constructor.These are further explained in 4.6 Table 4.6: Command Interface functions and description Function void execute(); Description This function performs a specic task dened by the user, and all exceptions that may occur must be caught within the command. The function does not return anything.

There is a default command type provided by the system, called CometCommand which can be extended by developers in order to provide client plugins the ability to interact with the server. Commands that are executed from the client and that require execution of server-side commands are executed by the CommandService which is discussed in the services section. The constructor of CometCommand takes in three parameters, a Bayeux object, a Client object, and a Message object, which contains information about the request, the user, and the data passed. CometCommands are not instantiated directly but are rather instantiated within the CommandService, which provides the three parameters. Once instantiated, the command has access to the request using bayeux. getCurrentRequest(), has access to the remote client that made the request using the Client object, and the message passed using the Message object. An example of a command is the AddFileCommand, provided by the Default Web plugin, which simply put adds a le to the project. The AddFileCommand is generalized in such a way that any type of le can be added, even if it requires additional parameters. This way, the command can be utilized by other plugins that provide a new le type and needs a way to create that type of le from the client. In order for the Command to be recognized by the service, it has to be registered rst, typically done in the Activator class, by invoking the addCommand function of the HttpCommandMappings class. HttpCommandMappings.addCommand("command-name", "fully.qualified.command.Name"); In the case of the AddFileCommand, it is: HttpCommandMappings.addCommand("add-file", "com.ctrlspace.defaultweb.AddFileCommand");

Services Services are server-side components that provide listen and publish to channels where clients can also listen and publish. Although the service mechanism still uses the tra43

ditional request-response model, the requests used in this mechanism is a long-polling type, wherein a request stays open for 60 seconds before terminating and reconnnecting again. This ensures that clients that send data can instantly, and can do so without creating another connection to the server. In the same way, since the requests are long-lived, the server can send responses any time, except during the small interval every 60 seconds wherein the client reconnects. Because of this, the communication between the client and server appears faster. There is an abstract service provided, called BayeuxService, that provides the functions that allow developers to subscribe and listen to channels. The only usable function in the service is subscribe. subscribe(String channelName, String functionName) - This function subscribes the services to the channel, allowing it to listen for messages on that channel. When a message is received, the function with a name of functionName is called. In order to be called, the function has to have the following signature, assuming the functionName is process. process(Client remote, Message message); For example, if a service has to listen to a chat room channel, and simply needs to publish to another channel any incoming message, then it has to implement the following methods: public ChatRoomService() { subscribe("/chat/incoming", "sendMessage"); } public void sendMessage(Client remote, Message message) { filterMessage(message); getBayeux().getChannel("/chat/room1", false).publish(remote, message, null); } First, the ChatRoomService subscribes to the /chat/incoming channel, and tells the service mechanism that it should invoke the sendMessage() function when a message arrives. In the sendMessage function, the message is rst passed through a lter, before being published into the /chat/root1 channel.

Command Service The command service is the service that listens to client-side requests for invoking f server-side commands. It listens on the /service/commands channel and has a single method, processRequest, which answers the requests. public void processRequest(Client remote, Message message) { BayeuxServiceHelper helper = new BayeuxServiceHelper(getBayeux(), remote, message); ICommand iCommand = helper.getCommand(); iCommand.execute(); }

44

The processRequest function creates a BayeuxServiceHelper, which does nothing more than looking up the command specied and returns it. Afterwards, processRequest calls its execute() function. The BayeuxServiceHelper takes the command parameter from the request, looks up the type associated with that command and instantiates that type. Map<String, Object> data = (Map<String, Object>) message.getData(); String action = (String) data.get("command"); String type = HttpCommandMappings.getCommand(action); Class<?> clazz = null; clazz = Class.forName(type); Constructor<?> constructor = null; constructor = (Constructor<?>) clazz.getConstructor(Bayeux.class, Client.class, Message.class); ICommand command = (ICommand) constructor.newInstance(bayeux, remote, message); return command; The command is looked up from the HttpCommandMappings, which as discussed earlier, allows registering of new commands into the system. The command service can only instantiate a CometCommand, which takes a signature of Command(Bayeux, Client, Message) as seen in the getConstructor() call.

ConsoleService The console service does nothing more than creating the console channel that listens for console requests from the client, which as of now has actually no function at all. However, since the ConsoleService has reserved the /service/console channel, commands can now publish to the /service/console/<user id> channels which map to the channels wherein clients listen for console events. This allows the server to push console data into the client without the client specically requesting for any data. For example, when the CreateProjectCommand command is invoked, it publishes a message to the /service/console/<user id> channel, telling the client that the project has been created, and the client logs this into the console accordingly. Bayeux bayeux = getBayeux(); HttpSession session = bayeux.getCurrentRequest().getSession(); User user = (User) session.getAttribute(HttpAttributes.CURRENT_USER); .getChannel("/service/console/" + user.getId(), " Directory " + project.getPath() + " has been set up for the project. "); The <user id> section of the channel was obtained from the current requests current session attribute CURRENT USER, which is available in the Bayeux Object.

Data Access Objects Data Access Objects (DAOs) are those that have the only direct access to the database in the system. The Data Access Objects are classied among the following:

45

Table 4.7: Plugin DAO functions and descriptions Function Description addPlugin(String pluginID, String data) Adds a plugin getPlugins() Retrieves all plugins

Plugin DAO The Plugin DAO is responsible for adding and retrieving client-side plugins from the database. In order for the system to discover custom client-side plugins, it has to be stored in the database, and the Plugin DAO provides functions to add and retrieve information about these plugins. It has two functions, namely: addPlugin and getPlugins. These are further explained in 4.7

Project DAO The Project DAO is responsible for adding projects to the database as well as retrieving projects from the database. Its functions include: createProject, getProject, openProject, getProjects and checkAccess. These are further explained in 4.8

File System DAO The File System DAO is responsible for creating, opening, saving, renaming, deleting, and copying les and folders. Its functions include: createFile, createFolder, openFile, saveFile, rename, delete, and copyFile. The File System DAO does not work with the backend database of the system as les are not kept in databases; rather, it handles dealing with les and folders directly. These are further explained in 4.9

46

Function createProject(int userid, String projectName, String path, String nature): ProjectUnit

Table 4.8: Project DAO functions and description Description This function is used to insert new project details into the database given the userId, projectName, description, path and nature. The userId attribute is the id of the project owner. The projectName attribute is the name supplied by the owner. The description attribute is the project description. The path attribute is the location of the project and the nature is the nature of the project. The return type is a projectUnit where the information of the newly created project is stored. The Project DAO creates a connection to the database and performs the following query: INSERT INTO projects VALUES (NULL, userId, projectName, nature, description, path, current date). This creates the database entry of the project and will reect on the list of projects a user has. However, this does not actually create physical representation of the project, since the Project DAO does not know the specic implementation details of the project created. This function is used to retrieve a particular project given a projectId. The projectId attribute is the id of the project. The return type is a ProjectUnit where the information of the retrieved project is stored. The Project DAO creates a connection to the database and performs the following query: SELECT * FROM projects WHERE projectId = projectId.

getProject(int projectId): ProjectUnit

getProjects(int userId): List<Integer>

This returns the project that has the associated ID as ProjectUnit. getProjects(int userId): List<Integer> This function is used to retrieve the projects of a certain user given the userId. The userId attribute is the id of the owner. The return type is a list of integers containing the project ids of a user. The Project DAO creates a connection to the database and performs the following query: SELECT * FROM projects WHERE projectId = ?

checkAccess(int userId, int projectId): boolean

This returns the project that has the associated ID as ProjectUnit. checkAccess(int userId, int projectId): boolean This function is used to check whether a user is able to access a project given the userId and the projectId. The userId attribute is the id of the owner and the projectId attribute is the id of the project. The return type is a boolean indicating whether or not the user has access to the project specied. The Project DAO creates a connectoin to the database and performs the following query: SELECT * FROM projects WHERE projectId = ? This returns the result whether the user has access or not as boolean.

47

Table 4.9: File System DAO functions and description Function createFile(String leName, String template, Map<String, String> replace): File Description This function is used to create a new File. The leName is the name of the le. The template is the contents of the template used to ll up the newly created le. The replace parameter contains the strings that is to be changed in the template along with the corresponding strings that will replace them. This function then returns the newly created le. The following shows how the createFile function works: The File System DAO rst creates a File representation given a path: File newFile = new File(fileName); It checks if the template is simply an empty string: if (template.equals("")) { newFile.createNewFile(); return newFile; } If so, it creates the le and returns the le immediately. It then checks if the replacements map is not empty, and processes it accordingly, by replacing all the matches in the template with the corresponding replacement value: if (replace != null) { Set<String> keys = replace.keySet(); Iterator<String> keyIterator = keys.iterator(); while (keyIterator.hasNext()) { String key = keyIterator.next(); String replacement = replace.get(key); // Replace all occurrences of key in template template = template.replace(key, replacement); } } After the replacements stage, the nal template is written to a physical le using a BufferedWriter, and is returned, as shown below: BufferedWriter bw = null; bw = new BufferedWriter(new FileWriter(newFile)); bw.write(template); bw.close(); return newFile; Continued on next page

48

Function createFolder(String folderName): File

Table 4.9 continued from the previous page Description This function is used to create a new folder. The folderName parameter is the folder name. This function returns the newly created folder. The following shows how the createFolder works: The File System DAO rst creates a File representation given a path: File newFile = new File(folderName); It then creates the folder: The File System DAO rst creates a File representation given a path: folder.mkdirs();

openFile(File le):String

Afterwards, it returns the newly created folder. This function opens a le specied by the le parameter. It then returns a String containing the contents of the le. The following shows how the openFile function works: The File System DAO rst instantiates a BufferedReader using the le inputted as parameter. BufferedReader input = new BufferedReader(new FileReader(file)); It then reads the contents of the le and then transfers it to a StringBuilder object. while ((line = input.readLine()) != null) { contents.append(line); contents.append(System.getProperty("line.separator")); }

saveFile(File le, String contents): void

Lastly, it returns the contents of the le. This function is used to save les specied by the le parameter. The contents parameter is the contents of the le to be saved. The following shows how the saveFile function works: The File System DAO rst checks if the le inputted as parameter is null, if it does not exist, if it is not a le, or if it cannot be written. If the le is either on of these, then it generates an exception. If not, it instantiates a Writer object with the le specied, then writes its intended contensts as specied by the paramters into it. Writer output = new BufferedWriter(new FileWriter(file)); output.write(contents); Continued on next page

49

Function rename(File oldFile, File newFile): File

Table 4.9 continued from the previous page Description This function is used to rename a le or folder. The oldFile representes the original le or folder while the newFile contains the new name for the le or folder. This function returns the newly modied le or folder. The following shows how the rename function works: The File System DAO simply takes the oldFile parameter and then renames it to the newFile parameter. oldFile.renameTo(newFile);

delete(File void

le):

delete(File le): void This function is used to delete les or folders specied by the le parameter. The following shows how the delete function works: The File System DAO simply deletes the le specied in the parameters: file.delete();

copyFile(File sourceFile, File destFile, boolean overwrite): File

copyFile(File sourceFile, File destFile, boolean overwrite): File This function is used to copy les or folders. The sourceFile parameter is the le or folder to be copied in its original location. The destFile species the location in which the contents of the sourceFile is to be copied. The overwrite parameters denes if a duplicate le is to be overwritten in case the sourceFile which is to be put into the same location as another le with the same name. The following shows how the copyFile function works: The File System DAO rst checks if the destination le exists. boolean fileExists = destFile.exists(); If the destination le exists and the overwrite setting is true, the File System DAO copies the le using Java NIO. FileChannel source = new FileInputStream(sourceFile).getChannel(); FileChannel destination = new FileOutputStream(destFile).getChannel(); destination.transferFrom(source, 0, source.size()); Continued on next page

50

Function copyDirectory(File sourcePath, File destinationPath, boolean copyStructure, boolean includeSubDirectories)

Table 4.9 continued from the previous page Description This function is used to copy a directory from a specied source to a specied destination. The sourcePath represents the directory to be copied. The destinationPath represents the location in to which the sourcePath is to be copied into. copyStructure yields a true or false value to indicate if the structure of the directory is to be copied or not. The includeSubDirectories is also a true or false value that indicates if the subdirectories should be included in the copying or not. The following shows how the copyDirectory function works: The File System DAO rst checks if the sourcePath is a directory, if the destPath is a folder, and if the destPath exists. If so, it then puts the children of the sourcePath into an array of Files. File[] subfiles = sourcePath.listFiles(); For every item in the array, if the item is a directory and includeSubDirectories is true, then it sets the new directory path according to whether the copyStructure value is true or not, then calls itself again into a recurssion, passing the items absolute path as the sourcePath and the new destination path as the destPath. The rest of the boolean values follow. if (f.isDirectory() && includeSubDirectories) { String newDestinationPath = ""; if (copyStructure) { newDestinationPath = destinationPath.getAbsolutePath() + File.separator + f.getName(); } else { newDestinationPath = destinationPath.getAbsolutePath(); } copyDirectory(f.getAbsolutePath(), newDestinationPath, copyStructure, includeSubDirectories); However, if the item is not a directory, then the File System Dao calls the copyFile function instead, giving the items absolute path as the sourcePath and the destPaths absolute path + the items le name as the new destPath.

User DAO The User DAO is responsible for creating, updating, verifying and retrieving the users from the database. Its functions include: createUser, userExists, updateUser, getUser and getUserFromCredentials. These are further explained in 4.10

51

Table 4.10: User DAO functions and description Function createUser(String username, String password, String email, String rstName, String lastName): User Description This function is used to insert the new user details into the database given the username, password, email, rstName and lastName. The username attribute is the desired username of the user. The password attribute is the password in which the user will use to verify himself or herself. The email attribute is the email address of the user. The rstName attribute is the rst name of the user. The lastName attribute is the last name of the user. The User DAO creates a connection to the database and performs the following query: INSERT INTO users VALUES (NULL, ?, ?, ?, ?, ?, NOW(), 0) userExists(String username): boolean This creates the database entry of the user. This function is used to verify whether a certain user exists or not given the username. The username attribute is the name of the user in the IDE. The User DAO creates a connection to the database and performs the following query: SELECT * FROM users WHERE username = ? LIMIT 1 updateUser(int id, String username, String email, String rstName, String lastName, Date lastLogin, long lastIp): void This returns the result whether the user exists in the database as boolean. This function is used the update the details of a certain user given the id, username, email, rstName, lastName, lastLogin and lastIp. The id attribute is the id of the user. The username attribute is the name of the user. The email attribute is the email address of the user. The rstName attribute is the rst name of the user. The lastName attribute is the last name of the user. The lastLogin attribute is the date when the user last logged in the IDE. The lastIp attribute is the last IP address of the user. The User DAO creates a connection to the database and performs the following query: UPDATE users SET username = ?, email = ?, firstName = ?, lastName = ?, lastLogin = ?, lastIp = ? WHERE userId = ? getUser(int User id): This updates the entry in the database. This function is used to retrieve the details of a user from the database given the id. The id attribute is the id of the user. The User DAO creates a connection to the database and performs the following query: SELECT * FROM users WHERE userId = ? This returns the user associated with the id as User. Continued on next page

52

Table 4.11: Workspace DAO functions and descriptions Function Description loadWorkspace(int userid) Loads all the les left open by the user specied by the user Id. openFile(int user, int projectId, String path) Marks the le represented by the path relative to the project represented by the projectId as open. closedFile(int user, int projectId, String path) Marks the le represented by the path relative to the project represented by the projectId as closed.

Function getUserFrom Credentials(String username, String password): User

Table 4.10 continued from the previous page Description This function is used to retrieve the details ofa user from the database given the username and password. The username attribute is the name of the user in the IDE. The password attribute is the password in which the user will use to verify himself or herself. The User DAO creates a connection to the database and performs the following query: SELECT * FROM users WHERE username = ? AND password = ? This returns the user associated with the username and password as User.

Workspace DAO The Workspace DAO is responsible for managing the state of the IDE as the user loads and leaves it. In order for the state of the IDE to be preserved, it has to be stored in the database, to be later on loaded upon launching of the IDE. Currently, only the list of opened les are maintained in the database. The Workspace DAO provides three functions to manage the workspace state of the user: loadWorkspace, openFile, closeFile. These are further explained in 4.11

Managers Managers perform the logic for the internal components of the system. The managers perform the tasks on the different data structures rst hand, and then passes the modied data structures to the specic plugins that require them.

FileType Manager The FileTypeManager is responsible for managing the available letypes into the system. It simply contains a map of Strings to FileTypes loaded into memory whenever a plugin registers different le types. The map is created whenever the server is started and is generated as the server loads the different plugins that register le types. The manager provides three functions that can be used by any server-side component. These are further explained in 4.12

53

Table 4.12: FileType Manager and description Function registerFileType (FileType leType) Description This function registers the le type in to the system, by simply mapping the type name of the le type using: registeredFileTypes.put(fileType.getTypeName(), fileType); FileType getFileType(String typeName) This function returns the FileType associated with the given typeName. If the typeName is not found, the manager returns a com.ctrlspace.defaultweb.types.Unknown, which represents an unknown le type. The following code represents how the FileType Manager performs the function: FileType fileType = registeredFileTypes.get(typeName); if (null == fileType) { return registeredFileTypes .get("com.ctrlspace.defaultweb.types.Unknown") ; } return registeredFileTypes.get(typeName); FileType getFileTypeFromExtension(String extension) This function returns a FileType from a given extension. This function must only be used whenever the caller has no information regarding the specic type name that it needs, as this can be inaccurate since different types may register the same extension name, in which case this function returns the rst match. If the le extension does not correspond to any le type, the function returns a FileType of com.ctrlspace.defaultweb.types.Unknown, which represents an unknown le type. The following code shows how the FileType Manager searches FileTypes: FileType fileType = registeredFileTypes.get(typeName); if (null == fileType) { return registeredFileTypes .get("com.ctrlspace.defaultweb.types.Unknown") ; } return registeredFileTypes.get(typeName);

Project Manager The Project Manager is responsible for dealing with the functionalities that concern the projects. It is the mediator between the Project DAO and the user interface. These are further explained in 4.13

54

Table 4.13: Project Manager and description Function createProject(int userId, String title, String description, String projectNatureString, Map<?, ?> options): ProjectUnit Description This function is responsible for calling the ProjectDAO to add the new project into the database as well as calling the IProjectNature to create the actual project. The userId parameter is the userId assigned to the user upon registration. The title parameter refers to the name of the project. The description is the description of the project. The projectNatureString refers to the project nature of the project, and the options parameter is the additional information needed for specic types of projects. Before calling the ProjectDao to add the project into the database, the createProject function rst generates a hash value using the userId, current timestamp and project name. It then uses this hashed value as the path to which the project is to be created. This is to ensure that all project paths are unique regardless of project name. String path = Security.SHA1(userId + new Date().toString() + title); ProjectUnit projectUnit = dao.createProject(userId, title, description, path, projectNatureString); Afterwards, it calls the IProjectNature to create the project according to the project nature specied. IProjectNature project = (IProjectNature) Class.forName(projectNatureString).newInstance(); ProjectUnit modifiedProjectUnit = project.createProject(projectUnit, options); Continued on next page

55

Function getProject(int userId, int projectId): ProjectUnit

Table 4.13 continued from the previous page Description This function retrieves the project using the userId and the projectId. The userId is the assigned id given to a user upon registration. The projectId is the assigned id given to a project upon creation. The ProjectManger rst checks if the user has access to the said project. boolean hasAccess = dao.checkAccess(userId, projectId); If the user has access to the project, the ProjectManagercalls the getProject function of the ProjectDao which returns a ProjectUnit object representing the project. It then instantiates an IProjectNature depending on the nature of the project retrieved, calling the getProject() function of the project nature to perform more modications to the ProjectUnit object to be returned to the caller. ProjectUnit projectUnit = dao.getProject(projectId); IProjectNature project = (IProjectNature) Class.forName(projectUnit.getNature()).newInstance(); ProjectUnit modifiedProjectUnit = project.getProject(projectUnit); return modifiedProjectUnit; Afterwards, it returns the modiedProjectUnit, which is a combination of the project retrieved from the database, as well as any modications done by the IProjectNature, such as retrieving les and getting IProjectNature-specic options. This function is similar to the getProject function; however the difference is that instead of retrieving one specic project, this function retrieves all projects under a given userId. First, the ProjectManager calls the getProjects function of the ProjectDao which returns a list of Integer under the userId. Then for each item in the list, the ProjectManager calls its getProject function, making the item the projecId parameter of the getProject function. List<ProjectUnit> projects = new ArrayList<ProjectUnit>(); List<Integer> projectIDs = dao.getProjects(userId); for (Integer i : projectIDs) { projects.add(getProject(userId, i)); } return projects; Continued on next page

getProjects(int userId): List<ProjectUnit>

56

Function openFile(int userId, int projectId, String path): FileUnit

saveFile(int userId, int projectId, String lePath, String contents): FileUnit

Table 4.13 continued from the previous page Description This function is used to open a specied le. The userId is the assigned id of a user upon registration. The projectId is the assigned id of a project. First the ProjectManager checks if the user has access to the specied project. If the user has access to the project, It calls the getProject function of the ProjectDAO which wil return a ProjectUnit object representing the project. Then, the nature of this projectUnit is used to instantiate an IProjectNature which will open the le depending on what its project nature is. This function is used to save a specid le through the userId, the projectId, the lePath which species the path of the le intended to be saved, and the contents parameter which contains the contents of the le to be saved. The ProjectManager rst checks if the user has access to the specied le. If the user has access, the ProjectManager rst calls the getProject method of the ProjectDao and then calls the saveFile methjod of the IProjectNature to save the le according to its project nature. ProjectUnit projectUnit = dao.getProject(projectId); IProjectNature project = (IProjectNature) Class.forName(projectUnit.getNature()).newInstance(); FileUnit saveFile = project.saveFile(projectUnit, filePath, contents); Finally, the ProjectManager returns the newly saved le represented by a FileUnit. This function is used to run a project given the userId, projectId and port. The userId attribute is the id of the user. The projectId attribute is the id of the project. The port attribute is the port to be used in running the project. The function rst checks whether the user has access to the project: if (hasAccess == true) Then it instantiates a new ProjectUnit and gets the project using the getProject function with the projectId as its parameter. ProjectUnit projectUnit = dao.getProject(projectId); An instantiation of IProjectNature is then made and the project nature of the projectUnit is instantiated. IProjectNature project = (IProjectNature) Class.forName(projectUnit.getNature()).newInstance(); A new Process p is instantiated and assigned to the value in which the run function is called and a process is to be returned. Process p = project.run(projectUnit, port); The Process p is returned. return p; Continued on next page

runProject(int userId, int projectId, int port): Process

57

Function deployProject(int userId, int projectId, String email, String password, String applicationId, String proxy): void

Table 4.13 continued from the previous page Description This function is used to deploy a project to the Google App Engine Server given the userId, projectId, email, password, applicationId and proxy. The userId attribute is the id of the user. The projectId attribute is the id of the project. The email attribute is the email address of the user. The password attribute is the password of the user corresponding to his or her e-mail address. The applicationId attribute is the application id in Google App Engine. The proxy attribute is the proxy if any. The function rst checks whether the user has access to the project: if (hasAccess == true) Then it instantiates a new ProjectUnit and gets the project using the getProject function with the projectId as its parameter. ProjectUnit projectUnit = dao.getProject(projectId); An instantiation of IProjectNature is then made and the project nature of the projectUnit is instantiated. IProjectNature project = (IProjectNature) Class.forName(projectUnit.getNature()).newInstance(); The deploy function is then called through the project nature object, project. project.deploy(projectUnit, email, password, applicationId, proxy);

User Manager The user manager manages all the user accounts known by the system. It is responsible for checking the user account information when logging in, for validating user information whenever a session is restored, and it is responsible for identifying users. These are further explained in 4.14

58

Table 4.14: User Manager and description Function createUser(String username, String password, String email, String rstName, String lastName): User Description This functions creates a new user. The UserManager rst checks if the user exists. boolean userExists = dao.userExists(username); If the user exists, the function returns a null. if (userExists) { return newUser; } If the user does not exist yet, the password is hashed, and the createUser method of the ProjectDao is called, adding the records of the new user into the database. String hashedPassword = null; hashedPassword = Security.SHA1(password); newUser = dao.createUser(username, hashedPassword, email, firstName, lastName); updateUser(User user): void getUser(String username, String password): User This function is used to change some attributes about the user in the records. The user parameter represents a user with all correct values for that specic user. The UserManager simply calls the updateUser.method from UserDao. This function identies a user using his or her username and password. The function simply hashes the password rst and then use this and the username as parameters for the getUser function from the User DAO.

Session Manager The Session Manager manages all the sessions that are active in the system. It keeps track of the logged in users, mapping their current client ID to the account, as well as the data that they are using throughout the session. These are further explained in 4.15 Table 4.15: User Manager and description Function getUser(String clientId) mapClient(string clientId, User user) removeClient(string clientid) addAttribute(String clientId, String key, Object value) Description Returns the User object associated with a client Id Maps a client id to a user Removes a User from the list of active sessions, along with the data used in the users session Adds the specied key to value mapping to the specied Users session data

Continued on next page

59

Function removeAttribute( String clientId, String key) getAttribute(String clientId, String key)

Table 4.15 continued from the previous page Description Removes the specied key to value entry in the specied Users session data

Gets the value associated with the key from the specied Users session data

Plugin Manager The Plugin Manager is responsible for installing and activating plugins on the y. When a user uploads a plugin bundle, the Plugin Upload Servlet passes this le into the Plugin Manager which unpacks the contents of the bundle to their appropriate locations. Afterwards, it activates the plugins to allow users to work with the plugins without requiring a server restart. install - File toProcess, installs the plugin bundle represented by the File argument. It unpacks the les inside the bundle to their appropriate locations, and calls on the Plugin DAO to add the client side plugins to the database. Afterwards, it registers the server-side plugins provided by the bundle to the systems ClassLoader.

4.4.7

Client-side Components

This section discusses the different client-side components of the IDE. It discusses their purpose and usage in the system.

Dojo Toolkit Dojo Toolkit provides the user interface components of the IDE. It also provides the communication between the user interface components and the services on the server-side. The toolkit provides the cometd package, in dojox.cometd, which allows the client-side component of the system to subscribe and publish to the channels provided by the server-side Services. The usage of these functions is outlined in 4.16 Table 4.16: Dojo Toolkit functions and their description Function subscribe() var cometd = dojox.cometd; cometd.subscribe (/channel/name, function(message) alert(message + received!);); Description The rst parameter is the channel name to subscribe to, while the second parameter species the function with the message argument as the function that will be executed whenever a message arrives.

Continued on next page

60

Function publish() var cometd = dojox.cometd; cometd.publish (/channel/name, message:message, someOtherData: [1, 2, 3]);

Table 4.16 continued from the previous page Description The rst parameter is the channel name to publish to, while the second parameter is the data to be passed, and can be either an Integer, String, Object or Array. The Services on the server-side converts these into the appropriate types for Java.

Workspace Loader The workspace loader is responsible for loading the state of the workspace as the user has left in the previous session. It makes a request to the server with the command load-workspace and the server executes the LoadWorkspaceCommand, returning the list of opened les that the user has left open in the previous session.

Plugin System system.

The plugin system consists of a plugin loader and the plugins used by the

Plugin Loader The plugin loader is responsible for loading the plugins in the client side as well as storing the already initialized plugin into a map which allows it to be reused without reinstantiating it. The plugin loader makes a request to the server, with the command get-plugins in which the server responds with a list of all the plugins enabled. An example plugin is shown below: { plugins: [ { id:"ctrlspace.core.commands.NewCommand", extensions: [ "ctrlspace.core.commands.Command" ], commandClass:"ctrlspace.core.commands.NewCommand" } ] }

Plugin A plugin is any javascript le that registers itself by using the dojo.provide() function. With the provide function, dojo is able to locate the javascript les by parsing the name space and converting it into a path. For example: dojo.require("ctrlspace.core.commands.NewCommand"); 61

Function registerHtml() registerXml() registerCss() registerJs() registerFolder() registerDefault()

Table 4.17: File Types Register functions and descriptions Description registers the HTML le type com.ctrlspace.defaultweb.types.Html registers the XML le type com.ctrlspace.defaultweb.types.Xml registers the CSS le type com.ctrlspace.defaultweb.types.Css registers the JS le type com.ctrlspace.defaultweb.types.Js registers the Folder le type com.ctrlspace.defaultweb.types.Folder registers the default and unknown le com.ctrlspace.defaultweb.types.Unknown

type

This function would make a request to the /ctrlspace/core/commands/NewCommand.js, instantiates the command and stores it into the map, which can be accessed using the IDE.getPlugin() function. var newCommand = IDE.getPlugin("ctrlspace.core.commands.NewCommand"); newCommand.execute(); The code above demonstrates how the newCommand is loaded from memory and executed.

4.4.8

Default Web Plugin

Default web plugin includes an activator class that calls on functions to register le types. It also includes a list of commands including: AddFileCommand, OpenFileCommand, CopyCommand, CutCommand, PasteCommand, DeleteCommand and RenameCommand.

File Types Registered The default web plugins Activator class calls on to several functions which register le types. These are further explained in 4.17

Commands These are the default commands of the default web plugins. These are further explained in 4.18

62

Table 4.18: Default Commands and their description Command AddFileCommand Description A generic CometCommand which registers the command name add-le. It takes ve parameters, replyTo, leType, leName, lePath, and options, which allow it to create the le requested accordingly. FileType is the fully qualied type name of the le, such as com.ctrlspace.defaultweb.types.Html, lePath is the path of the le relative to the project, leName is the name of the le to be created, and options is a map of string to object values that clients may want to add to the le. There is a default option available, called preprocessor which species a fully qualied name to a class implementing the IAddFileProcessor, allowing the class to pre-process the request before creating the le. The most important use of this is allowing the use of template replacements. ReplyTo is the channel name to which the AddFileCommand will send its reply, as it is a generic command and therefore clients must tell the command which channel it should send replies. The OpenFileCommand makes use of two parameters passed from the clientside: the project id and the path of the le that is to be opened. The OpenFileCommand calls the openFile command of the ProjectManager to retrieve the le contents represented by the FileUnit data structure. It then returns these information to the client-side through a JSON string. The CopyCommand makes use of two paramters passed from the client-side: the projectId and the path where to le or folder to be copied is located. The CopyCommand used the Clipboard object from the Java DataTransfer library to store the path of the le or folder. The CutCommand makes use of two parameters that are passed to it from the client-side: the projectid and the path where the location of the le or folder to be cut is located. It calls the copy command and sends a bpolean attribute called isCut to tell the system to delete the le or folder from its origianl place after it is pasted. The PasteCommand maes use of two parameters that are passed to it from the client-side: the project id and the path where the location to which the le or folder is to be pasted. It accesses the local Clipboard created by the Clipboard object of the Java DataTransfer library to retrieve the location of the le to be pasted. It then copies this le into the destination specied. The DeleteCommand makes use of two parameters passed to it from the client-side: the project id and the path where the le or folder to be deleted is located. If the folder to be deleted is not empty, it traverses its children to delete these as well before deleting the folder itself. The renameCommand makes use of two parameters passed to it from the client-side: the projectid, the new name, and the path to the le or folder to be renamed. The renameCommand replaces the old name of the le or folder specied by the path in the parameter with the new which is also specied in the paramaters passed to it.

OpenFileCommand

CopyCommand

CutCommand

PasteCommand

DeleteCommand

RenameCommand

63

4.4.9

Google App Engine Plugin

IProjectNature The Google App Engine provides the AppEngineProject IProjectNature which registers a new project nature of the type com.google.appengine.AppEngineProject. The AppEngineProject nature implements the IProjectNature in such a way that the les created are stored on the le system and structures the project to conform it to the Servlet standard. This is because the Google App Engine server requires this type of structure, and to be able to run and deploy this type of project to the server, this structure must be followed. The project nature implements the createProject method by making a call to a private setupFileSystem() method which uses the File System DAO to create the le structure. // Create folder structure String projectPath = fsPath + File.separator + projectUnit.getPath() + File.separator; // Create src folder structure String src = projectPath + "src" + File.separator; String srcMETAINF = src + "META-INF" + File.separator; String srcServlets = src + "servlets" + File.separator; fsDao.createFolder(src); fsDao.createFolder(srcMETAINF); fsDao.createFolder(srcServlets); // Create WebContent folder structure String webContent = projectPath + "WebContent" + File.separator; String webINF = webContent + File.separator + "WEB-INF" + File.separator; String webINFLib = webINF + "lib" + File.separator; String webINFClasses = webINF + "classes" + File.separator; fsDao.createFolder(webContent); fsDao.createFolder(webINF); fsDao.createFolder(webINFLib); fsDao.createFolder(webINFClasses); // Copy libraries File libs = new File(config.get("appengine-sdk.path") + File.separator + "lib" + File.separator + "user"); File libs2 = new File(config.get("appengine-sdk.path") + File.separator + "lib" + File.separator + "shared"); fsDao.copyDirectory(libs.getAbsolutePath(), webINFLib, false, true); fsDao.copyDirectory(libs2.getAbsolutePath(), webINFLib, false, true); In addition to the folder structure, default les and servlets are also created.

64

File Types Registered The Google App Engine plugins Activator class calls on to several functions which register le types. These are further explained in 4.19 Table 4.19: File Types Registered and their description Function registerClass() registerEnum() registerInterface() registerServlet() registerFilter() registerListener() registerPackage() registerEmpty Package() Description registers the class le type com.google.appengine.types.Class registers the enum le type com.google.appengine.types.Enum registers the interface le type com.google.appengine.types.Interface registers the servlet le type com.google.appengine.types.Servlet registers the lter le type com.google.appengine.types.Filter registers the listener le type com.google.appengine.types.Listener registers the package le type com.google.appengine.types.Package registers the empty package le type com.google.appengine.types. EmptyPackage

Command The App Engine plugin includes three commands namely: AutoCompleteCommand, RunCommand and DeployCommand. These are further explained in 4.20 Table 4.20: File Types Registered for App Engine Plugin and their description Command AutoComplete Command() Description The AutoCompleteCommand makes use of three parameters: codeState, lineNumber, variable nameand the project id. The codeState parameter is the current contents in the code editor as well as the current position of as well as the current position of the cursor. The AutoCompleteCommand makes use of the Java Compiler Tree APi to parse the code and retrieve the data type of the given variable name specied in the parameters. It takes into consideration the external resources imported into the project, the inherent java libaries, primitive data types and the classes inside the package of the given le. The autocomplete function then uses the Java Reection API to retrieve the list of methods and its parameters. It then arranges all these into a JSON string to be given to the client side. If the data type detected by the Compiler Tree APi does not fall under the four categories mentioned above, the autocomplete function simply returns an empty JSON string.

4.4.10

Globe Labs API Plugin

Globe Labs API Plugin includes an activator class that calls on functions to register le types. It also includes the command AddSupport.

File Types Registered The Globe Labs API plugins Activator class calls on to several functions which register le types. These are furhter explained in 4.21

65

Table 4.21: File Types Registered for Globe Labs API and their description Function registerSMS() registerMMS() registerLBS() Description registers the SMS le type com.globelabs.types.SMS registers the MMS le type com.globelabs.types.MMS registers the LBS le type com.globelabs.types.LBS

Command The Globe Labs API Plugin includes an AddSupportCommand. It is further explained in Table 4.22 Table 4.22: Command for Globe Labs API and its description Command AddSupport Command Description The add support command simply imports the Restlet libraries into the /WEBINF/lib/ folder of the project selected. By doing so, the SMS, MMS and LBS le types are able to carry out their functions which utilize the Restlet API to consume the web services provided by Globe Labs.

4.4.11

Default Plugins

Commands

Add File Each le type has its own add command in the client side. When the user clicks the Submit button on the dialog box for adding the le, the createFile function of the command retrieves the context information of the command then passes these to the server with these parameters as shown in 4.23 Table 4.23: Add File context information and their description Parameter url command projectId leName packageName handleAs load error Description ctrlspace.cong.projectManagerUrl The command string (example: create-class, create-jsp) The id of the project The le name of the class being created The path to the package where the le is to be created json What to do if creation of le is successful What to do if the creation of le is unsuccessful

The url, command, and handleAs parameters are readily dened already. The projectId is retrieved by getting the projectId of the last item on the project explorer that is focused. projectId = IDE.getUI().tree.lastFocused.item.projectId[0];

66

The leName and packageName is retrieved by the leName and packageName specied in the user interface text box. var classFileName = this.classFileName.value; var packageName = this.tree.lastFocused.item.label[0]; These pieces of information are passed to the server side where the CommandService class accepts these information. To match the command of the client side to the proper function in the server side, the CommandService accepts the information passed by the client side and reads the command parameter. It then matches the command parameter to its corresponding Command class in the server side. In this case it is the AddFileCommand class. The CommandService calls the execute function of the AddFileCommand class. The execute function of the AddFileCommand class calls the addFile function of the Project Manager. The Project Manager then calls the addFile function of IProjectNature. The functions in IProjectNature are extended by the different project types supported in the system. For example, if the current project type is Google App Engine Project, then the addFile function of Google App Engine Project type is executed. The addFile function of the Google AppEngine Project type calls the addFile function of the FileSystemDAO.

Open File When the user clicks the Submit button on the Add Filter Dialog box, the createFolder function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.24. Table 4.24: Open File context information and their description Parameter url command projectID lePath Description ctrlspace.projectManagerUrl open-le The id of the project The path of the le to be opened

The url and command parameters are readily dened. The projectId is retrieved from the last item focused on the project explorer. The lePath is retrieved from the lePath attribute of the last item focused on the project explorer. IDE.getUI().getEditors().openEditor(targetItem["projectId"][0], targetItem["path"][0], targetItem["label"][0], targetItem["iconClass"][0]);

Save File When a user presses the Ctrl + S hotkey on an editor, the saveEditor function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.25

67

Table 4.25: Save File context information and their description Parameter url command projectID lePath contents Description ctrlspace.projectManagerUrl save-le The id of the project The path of the le to be opened The contents of the le to be saved

The url and command parameters are readily dened. The projectId and contents are retrieved from the editor in which the le is located in. projectId: editor.projectId, filePath: editor.path, contents: editor.getEditor().getCode()

Rename File or Folder When a user clicks Submit on the rename le or folder dialog box, the rename function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.26 Table 4.26: Rename File or Folder context information and their description Parameter url command projectID leName path Description ctrlspace.projectManagerUrl rename The id of the project The new name of the le or folder The path of the le or folder to be renamed

The url and the command parameter are readily dened. The projectID is obtained from the last tree item focused, the leName is user input from the text eld in the rename dialog, and the path is also obtained from the last tree item focused. var var var var lastItemSelected = IDE.getUI().getTree().getLastItemSelected(); id = lastItemSelected.item.projectId; path = lastItemSelected.item.id; fileName = this.fileName.value;

Delete File When a user clicks Delete button form the right click menu, the delete function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.27

68

Table 4.27: Delete File context information and their description Parameter url command projectID path Description ctrlspace.projectManagerUrl delete The id of the project The path of the le or folder to be deleted

The url and the command parameter are readily dened. The projectID is obtained from the last tree item focused, the leName is user input from the text eld in the rename dialog, and the path is also obtained from the last tree item focused. var lastItemSelected = IDE.getUI().getTree().getLastItemSelected(); var id = lastItemSelected.item.projectId; var path = lastItemSelected.item.id;

Copy File When a user clicks Copy button form the right click menu, the delete function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.28 Table 4.28: Copy File context information and their description Parameter url command projectID path Description ctrlspace.projectManagerUrl copy The id of the project The path of the le or folder to be copied

The url and the command parameter are readily dened. The projectID is obtained from the last tree item focused, the leName is user input from the text eld in the rename dialog, and the path is also obtained from the last tree item focused. var lastItemSelected = IDE.getUI().getTree().getLastItemSelected(); var id = lastItemSelected.item.projectId; var path = lastItemSelected.item.id;

Cut File When a user clicks Cut button form the right click menu, the delete function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.29 Table 4.29: Cut File context information and their description Parameter url Description ctrlspace.projectManagerUrl Continued on next page

69

Parameter command projectID path

Table 4.29 continued from the previous page Description cut The id of the project The path of the le or folder to be copied

The url and the command parameter are readily dened. The projectID is obtained from the last tree item focused, and the path is also obtained from the last tree item focused. var lastItemSelected = IDE.getUI().getTree().getLastItemSelected(); var id = lastItemSelected.item.projectId; var path = lastItemSelected.item.id;

Paste File When a user clicks Paste button form the right click menu, the delete function retrieves the context information of the command then passes a request to the server with these parameters shown in 4.30 Table 4.30: Paste File context information and their description Parameter url command projectID path Description ctrlspace.projectManagerUrl paste The id of the project The path of the le or folder to be copied

The url and the command parameter are readily dened. The projectID is obtained from the last tree item focused, and the path is also obtained from the last tree item focused. var lastItemSelected = IDE.getUI().getTree().getLastItemSelected(); var id = lastItemSelected.item.projectId; var path = lastItemSelected.item.id;

4.4.12

Widgets

Project Tree The project tree is an extension of the dijit.Tree widget provided by the Dojo Toolkit. It is provided to the system under the ctrlspace.ui.tree.ProjectTree class and contains additional functions that are needed to be able to use the default dijit.Tree like a project explorer. The Project Tree is provided as part of the default plugin that comes with the system and is also part of the base UI, which can be accessed by making a call to getTree() of the UI component, as in the example below: var projectTree = IDE.getUI().getTree(); projectTree.refresh() // perform functions on the tree

70

When the project tree is loaded, it makes a call to the server-side GetProjectsCommand which returns a JSON-encoded list of all projects of the user. Each project in the list contains the project information, such as the projectId, title, nature, and iconClass, as well as the complete list of les inside the project. The list is simply lled with the client-side JSON representation of the server-side ProjectUnit data structure. The tree is populated by rst making a call to the server-side CommandService, specifying a command of get-all, and passing no arguments. The CommandService returns the JSON-encoded list of ProjectUnits. This list is then passed to the constructor of a dojo.data. ItemFileReadStore(), which creates a datastore that a Forest Tree Model can use. The Forest or Tree Model is what the tree uses to populate its data. Any changes made to the model will reect on the tree. Once theItemFileReadStore is instantiated, it is passed to the constructor of a dijit.tree.ForestModel(), along with another parameter, childrenAttr, which species the key name in the JSON-encoded list to be used as a parent for sub-sequent elements inside the ProjectUnit. Once the call is made Being a widget, the tree can also listen to browser events that may occur to a regular DOM node. The tree listens to the onContextMenu and onDblClick events, allowing it to provided functionalities whenever these types of events occur inside the project tree area. In order to listen to these events, the widget must either override the functions or simply connect the events to a function, and can be done in the following way: dojo.declare("ctrlspace.ui.tree.ProjectTree", [dijit.Tree], { // Define class extending dijit.Tree onDblClick: function(targetItem, node, event) { // Simply override the onDblClick function, and it will be automatically called } }); or dojo.declare("ctrlspace.ui.tree.ProjectTree", [dijit.Tree], { // Define class extending dijit.Tree constructor: function(options) { dojo.connect(this.domNode, "ondblclick", dojo.hitch(this, this.myFunction); }, myFunction: function(targetItem, node, event) { } }); The difference of the two codes is that the former restricts you to following the convention of simply overriding onDblClick. This is useful if you only want to take one action when a double clieck is performed. Using the dojo.connect() function, you can connect the events to many functions, so that double clicking the tree would call many functions. It also allows you to have different function names other that onDblClick. In the trees onDblClick event, the parameters targetItem, node, and event are passed. Their uses are described below: paki table nlng targetItem - this parameter contains the object 71

associated with a certain node. Because nodes of the tree can only be a ProjectUnit or FileUnit node, this parameter is simply the client-side representation of the data that represents the node that was clicked. For example, the targetItem might contain the following data: {"id":"bin","path":"bin","label":"bin", "type":"com.ctrlspace.defaultweb.types.Folder", "iconClass":"csIcons folderIcon","parserFiles":[], "styleFiles":[],"projectId":1,"isOpenable":false} Which is actually a JSON representation of the FileUnit data structure. node - this parameter points to the widget that the node clicked represent. This widget is a dijit. TreeNode. This is an internal component of the dijit.Tree widget and is normally not used. It is provided only for low-level access to the actual item clicked. Event - this parameter contains information about the right click event, which contains the shiftKey and ctrlKey attributes, as well as the X and Y attributes. The descriptions of the attributes are given below: shiftKey - if the shift key was being held when the double click was performed ctrlKey - if the ctrl key was being held when the double click was performed X - the X location where the double click event occured Y - the Y location where the double click event occured In the ProjectTrees case the onDblClick event was used in the following way: dojo.stopEvent(event); // File is openable if (targetItem[isOpenable][0] == true) { IDE.getUI().getEditors().openEditor(targetItem["projectId"][0], targetItem["path"][0], targetItem["label"][0], targetItem["iconClass"][0]); } The function dojo.stopEvent() simply stops the event from bubbling up, meaning the double click event will not be passed up to the browser, which performs its own actions following a double click event. Instead, the event will only be used by ProjectTree if it occured inside the tree. The rest of the code simply checks if the target item clicked is openable, and calls the EditorManager to open an editor with the parameters taken from the targetItem.

Editor Manager The EditorManager is responsible for communicating with the server with regards to operations involved with Editors. Its three main functions are outline shown in 4.31

72

Table 4.31: Editor Manager functions and their description Function closeEditor Description This function is actually not the function that closes an Editor in the sense that it removes it from the user interface, but rather, this function removes the specied editor from the list of opened editors. It then makes a call to the server-side closeFile, specifying the projectId and lePath of the closed editor. This function is responsible for opening an editor, from the process of retrieving the le from the server up to instantiating an EditorPane widget and placing it in the Editors tab. This is the function called when double clicking an item in the Project Tree, and accepts as parameters the projectId, le path, title, and iconClass of the le that will be opened. The code is outlined below: var editor = this.getEditor(projectId + "_" + path); if (editor == null) { var newEditor = new ctrlspace.ui.editor.EditorPane({ title: title, iconClass: iconClass, closable: true, path: path, projectId: projectId }); var xhr = dojo.xhrGet({ url: ctrlspace.config.projectManagerUrl, content: { command: "open-file", projectId: projectId, filePath: path }, handleAs: json }); xhr.addCallback(dojo.hitch(this, this.openEditorSuccess)); } else { this.selectChild(editor); } The openEditor function rst checks if the le requested to be opened is already open. If it is already opened, it simply focuses the editor. Otherwise, it instantiates a new EditorPane, which creates a new Editor tab with the loading icon. It then makes a call to the open-le command of the server, passing the projectId and lePath. Once the response has been received, the callback function openEditorSuccess is called, which subsequently initializes the Editor Pane by nally instantiating the CodeMirror widget inside the Editor Pane. Continued on next page

openEditor

73

Function

Table 4.31 continued from the previous page Description var contentArea = new CodeMirror(editor.domNode, { id: response.id + _iframe, content: response.content, parserfile: response.parserFiles, stylesheet : response.styleFiles, path : "js/ctrlspace/codemirror/", textWrapping: false, indentUnit: 4, tabMode: "shift", height: "100%", onChange: dojo.hitch(editor, editor.onEditorChange), cursorActivity: dojo.hitch(editor, editor.onCursorActivity), lineNumbers: true }); editor.setEditor(contentArea); editor.setAutoComplete(response.autoComplete); this.selectChild(editor); The response from the server is actually a FileUnit data structure, and the CodeMirror instantiated uses properties from this FileUnit, such as getting the parserFiles and styleFiles and using these les for the syntax highlighter. Finally, it assigns the CodeMirror instance to the EditorPane and focuses on the editor. This function is responsible for saving the contents of an Editor. It simply makes a call to the save-le command on the server, passing the projectId, lePath and the contents of the le to be saved. var saveRequest = dojo.xhrPost({ url: ctrlspace.config.projectManagerUrl, content: { command: "save-file", projectId: editor.projectId, filePath: editor.path, contents: editor.getEditor().getCode() }, load: dojo.hitch(this, this.saveEditorSuccess), handleAs: "json", sync: true });

saveEditor

Editor Pane Code editors are implemented inside the Editor Pane. These are implemented as Dojo Widgets using the CodeMirror library. It uses a modied version of the syntax highlighter of CodeMirror. Code editors are also plugins as there can be many types of code editors with different syntax highlighting and auto-complete capabilities packaged together.

74

Syntax Highlight The syntax highlighter uses the parser interface from CodeMirror, allowing for different parsers for each language to be developed. An editor may have one or more parsers loaded. Once an editor is opened or the contents of an editor is changed, a syntax highlighting event takes place. Depending on the type of the le, a parser designed for the le type parses the contents of the le and assigns each token to a token type. These token types are then applied the CSS class designed specially for that token type. The CSS stylsheet assigns colors for each token type and these colors reect on the code editor. In order to create a parser, the following interface must be supported, this is shown in 4.32 Table 4.32: Syntax Highlight functions and their description Function make (string stream) electricChars Description A function that given a string stream, creates a parser.

An optional string attribute containing characters that, when typed, should cause the indentation of the current line to be recomputed.For example, curly braces in C-like languages. congure (object) An optional function that can be used to congure the parser. rstIndentation(chars, An optional function that is used to determine the proper indentation of the rst current, direction) line of a document. When not provided, 0 is used.

When the make method is called with a string stream, it should return an iterator: an object with a next method which when called, will consume input from the string stream and produce a token. A token is simply an object representing a signicant part of the string stream. It has the following attributes: value - The actual value of the text it stands for style - The corresponding CSS class that should be used to style the text.This can be anything, except that any whitespace at the start of a line should always have the class whitespace. The iterator must also be able to distinguish and create newline token objects, which has an indentation property which is a function that is used to determine the indentation of the next line. Similar to the rstIndentation() function, it takes the text of the rst token in the next line, the current indentation level, and the direction of indentation. To achieve a purely client-side auto-complete functionality, a more complex parser must be created. Fortunately, CodeMirror has already provided parsers for JavaScript and HTML. The auto-complete functionality was separated from the syntax highlighter to enable more simple and complex auto-complete systems. For example, an auto-complete suggestion list might be generated only by having a hard-coded list of suggestions given a code state, or it might be generated on the by actually parsing the le and analyzing the related les to see if getting suggestions from these les is also possible.

Auto-complete Auto-complete functionality can be either client-side or server-side, depending on the implementation. The implementation of the auto-complete functionality of CtrlSpace for Java source codes is server-side and client-side, as it needs to be able to read the class signatures of the core Java classes as well as any custom class that the user creates.

75

Auto-complete can be triggered by the ctrl + space hotkey. An auto-complete module must implement the following methods: beginCodeAssist() - Determines the context of the auto-complete event and calls on list(context) to generate a list of code hints to render on screen The beginCodeAssist() determines the context of the the auto-complete event. In the provided default auto-complete plugin for Java classes, this is implemented by checking the previous tokens from the position of the cursor in the editor. It simply looks back until the beginning of the line and tries to determine which token the variable name is that an auto-complete suggestion is needed for. It then passes this context information, consisting of the line number, the variable name, and the current code state to the list() function to generate a list of code hints, which it renders on a drop down list on screen. The list() function can either simply return a hard-coded list of suggestions or actually perform parsing of les to generate suggestions. An example of how auto-complete works for Java is outlined below: The following shows how the auto-complete functionality works: Given the following code: private static String str = "test"; str. An auto-complete event takes place when the user presses the hotkey Ctrl + Space after str.. The beginCodeAssist() function searches for the variable intended for the auto-compelte function. This is done by parsing the content of the line the cursor is in. Starting from the current position of the cursor going backwards, the contents of the line is parsed until the parser reaches a space. for (i is in the current position of the cursor - 2 until the end of the line){ get the current character in the index i from the line. if (the character is not a space) append that character to the "identifier" string else end the loop } The str variable is then the variable name which used the auto-complete function. Afterwards, the beginCodeAssist builds the context information in JSON format with the following parameters shown in 4.33 Table 4.33: Begin Code Assist context information and their description Parameter url command codeState lineNumber Description ctrlspace.cong.projectManagerUrl auto-complete the code inside the editor The current line number of the cursor Continued on next page 76

Parameter variableName projectId handleAs sync

Table 4.33 continued from the previous page Description The variable name which used the auto-complete function. This is retrieved by the parsing discussed earlier. The id of the project. json true

Console The Console is implemented simply as an extension of a regular dijit.layout.ContentPane, which can only contain HTML or other widgets. The implementation of the Console widget uses HTML as its content and only provides four functions, clear(), getText(), setText() and append() respectively. The console widget also listens at the /service/console/<user id> channel and all messages received on that channel is appended to the console.

Problems Table The Problems Table is implemented as a dijit.Grid widget and is only updated whenever the Run or Deploy commands are called, as these commands are the only commands that perform a build on the project and errors can only be detected during compilation.

Dialogs The Dialogs are implemented as custom widgets following a certain template provided by the system. The plugins use this template to implement their own dialog widgets, only modifying certain elements of the template by adding or removing labels and input boxes.

4.5
4.5.1

System Functions
New Project

This function allows users to create new projects. Upon choosing this function, users will be asked to specify certain project details like the project name.

4.5.2

Open Project

This function enables users to display and edit a specic project that they are a member of.

4.5.3

Close Project

This function disables users to edit it, and it also removes the project from view on the explorer and the editor. If the project is not saved yet, a notication will be sent to the users asking them if they want their project to be saved rst before being closed.

77

4.5.4

New le

This function lets users add a le to the project that they are currently working on. Files provided are those that are supported by the IDE only. Upon choosing this function, users will be asked to specify the le name and type.

4.5.5

Save le

This function saves the current version of the le into the IDE database.

4.5.6

Save project

This function saves the current version of the whole project into the IDE database.

4.5.7

Run Project

This function executes the project that is currently being edited. If more than one project is open, the user will be asked to choose which one to execute. Running the project will show the resulting web application in a web browser. By default, the application will be displayed in a new Firefox tab or window, but if users wishes to run their applications on another web browser, they must copy the URL into the other said browser. The system logs and outputs will be displayed separately in the console of the IDE.

4.5.8

Deploy Project

This function deploys the project into the server. Currently, CtrlSpace only supports Google App Engine Projects. When users choose this function, they will be asked to input the host name, username, and password, after which a new Firefox tab or window will appear showing the current output of his/her web application. The system logs and outputs will be separately displayed in the console of the IDE.

4.5.9

Search

This function asks users for a certain string and nds all matching strings in the IDE except for labels in the user interface design.

4.5.10

Auto-complete

This function enables users to browse through possible functions that they can use given a variable. This function is used when the user types a . beside a variable and then presses

78

the Ctrl+Space hotkey. The system will place a drop down box beside the cursor showing the possible methods that the user can use. Additionally, this function provides a searching feature wherein the user may search for specic functions they have in mind by typing into the drop down box. The drop down box will then lter the choices applicable.

4.5.11

Syntax Highlighting

This function color codes each literal in the source code of the project by the type of literal of the programming language that they are using.

4.5.12

Undo

This function can be used in the editors. It enables users to undo their actions.

4.5.13

Redo

This function can be used in editors. It enables users to re-execute the actions that they have done, but have undid.

4.5.14

Invite Collaborator

This function allows the user to add a collaborator to the project.

4.5.15

View Collaborators

This function allows the user to view all collaborators of the project.

4.5.16

View File

This function can be done in the File explorer. It enables users to view the les of their projects.

4.5.17

Edit File

This function can be done in the File explorer. It enables users to edit the les in their projects.

4.5.18

Copy File

This function can be done in the File explorer. It enables users to duplicate a le. 79

4.5.19

Move File

This function can be done in the File explorer. It enables users to move a given le into another location inside the project.

4.5.20

Rename File

This function can be done in the File explorer. It enables users to change the name of a given le.

4.5.21

Show contents of le

This function can be done in the File explorer. It enables users to open the le, showing the contents of it in an editor.

4.5.22

View Database

This function is accessed through the database explorer. Using this function, users are able to view the contents of the database in the IDE. Different restrictions apply depending on the database vendor. In the case of Google AppEngine DataStore, users can only view the contents of the database by executing JDOQL.

4.6
4.6.1

Physical Environment and Resources

Dojo Toolkit was chosen to create the user interface design of the research because it has the basic widgets needed to compose an IDE. These widgets can be easily customized and extended for more functionality. Figure 4.4 shows the skeleton of the user interface of the IDE using Dojo widgets. In addition to this, Dojo provides a namespace system similar to the Java package system, which is a familiar environment for the proponents. With this package system, widgets and classes can be easily separated into modules which allows for easier modular development and separation of tasks. Dojo Toolkit also provides a package called Dojo Ofine which is built on top of Google Gears. Dojo Ofine will be used to cache the resources used by the IDE to minimize the subsequent loading times after the rst launch. It will also be used for keeping the state of the IDE across sessions, allowing users to resume from where they last left off in a project.

80

Figure 4.4: User Interface Skeleton 4.6.2 Google AppEngine Software Development Kit

The Google AppEngine SDK will be used for running and deploying Google AppEngine projects built from the IDE. The SDKs built-in web application server allows the system to run the created projects separately from the IDEs web server. The SDK also contains the Google AppEngine DataStore which provides the same DataStore used in the actual Google AppEngine servers hosted at appspot.com. Because of this, the whole SDK is actually able to mimic the exact environment that the Google AppEngine servers use, and deploying would actually require no additional conguration if a project is run on the SDK. Additionally, the SDK provides an upload tool which allows the project to be directly deployed to the appspot.com servers, which will be used by the system accordingly.

4.6.3

Byte Code Engineering Library

BCEL will be used for the auto-complete functions of the IDE. Using BCEL, it is possible to generate the list of method signatures as well as elds from an already compiled class le. This will be used for classes that are not part of the Java core specications. To retrieve information from the class le, the following, as shown in Figure 4.5, may be done.

4.6.4

CodeMirror

In the system, CodeMirror will be used as the base engine for the syntax highlighter of the IDE. Since it includes a powerful parser engine that is able to parse large text les in a very short time, the engine will be used and extended for the editors that the IDE will support. In order to integrate CodeMirror with the system, it will be transformed into a Dojo package and the main editor interface will be transformed into a JavaScript class following the Dojo 81

Figure 4.5: BCEL Sample Code standards as shown below: dojo.provide("ctrlspace.codemirror.Editor"); dojo.declare("ctrlspace.codemirror.Editor", null, { // transform the original code here // into the Dojo format for classes }); The parser engine of CodeMirror will be extended to support symbol tables which will be used for the auto-complete functions.

4.6.5

Java Reection API

The server-side plugins will only be loaded when it is needed, therefore, run-time loading of classes is needed. This is achieved through the Java Reection API. Assuming the plugin .jar le is already loaded through the Java Jar API, and the manifest le is read by the Plugin Registry, the classes can be loaded through reection using two different methods: Class.forName(fully.qualified.className); Class clazz = fully.qualified.className.class; clazz.newInstance();

4.6.6

Java Jar API

The Java Jar API will be used to load les from .jar archives. This is to support the plugin system as the plugin les will be packaged in .jar archives. Additionally, the Jar API will be used to create .war les when deploying the projects.

82

4.6.7

Subversion

Subversion will be used for collaboration in the IDE. The concept of branches allow project members to create separate cheap copies of the project and merge it again with the main line of development after their tasks have been completed.

4.6.8

SVNKit

The system makes use of SVNKit to incorporate subversion into Java applications. Several functions from the SVNKit library will be used, including retrieving the repository tree and its contents, committing, updating, and creating repositories.

83

Design and Implementation Issues

This chapter discusses the issues encountered while implementing the project. It also discusses the solutions or alternatives employed by the proponents.

5.1

Google Web Toolkit

Google Web Toolkit (GWT) was initially the toolkit used to create the user interface of the IDE, however due to the text editors limited customizability at its time of release, it did not allow the proponents to tailor the editor according to the needs of the IDE. Additionally, the client and server coordination of GWT is tighty bundled such that it is more complicated for the proponents to create support for client-side plugins. On the other hand, Dojo Toolkit allow for easier support in creating client-side plugins, at the same time, its widgets are customizable enough for the proponents to alter them to t the needs of the IDE. The only drawback to this decision was that Dojo widgets dont have the exact look and fell across different browsers which is what GWT boasts. Because of this several discrepancies are noticeable when the IDE is viewed on different browsers.

5.2

Byte Code Engineering Library

Byte Code Engineering Library (BCEL) was initially intended to support the auto-complete functionality of the IDE by reading the binary class les, however it was not used any longer as the Java Reection API covered this functionality. Instead, the Java Reection API was used as it is already packaged in the Java Software Development Kit. This allowed lesser physical resources needed to develop the IDE.

5.3

Database Explorer

The database explorer cannot be implemented because access to the Google Appengine server cannot be accessed. Only the App Engine projects are allowed to access the contents of the databases corresponding to it.

5.4

Import Library File

The Dojo FileUploader widget is used to implement the client side of the import library le. It is supposed to implement a lter the types of les that is displayed in the le picker that it instantiates. However, there seems to have a problem with it as it does not properly lter the types of les displayed. As an alternative, the proponents created a server-side checker to lter out unwanted le types.

84

5.5

Architecture

The architecture was changed from the previous design to allow more exibility for future developers of the system. The previous architecture focused on providing plugins more on the client side, but with the introduction of the Command system, the IDE can now be extended in almost every way. The Dojo Ofine component was taken out because it was unnecessary as of the moment in implementing a stable architecture. The Service system was also introduced to lessen the communication latency between the server and the client, because this allows the browsers to create long-lived HTTP requests to the server which only reconnects every 60 seconds. By using this kind of request-response model, the client and remain connected to the server and send commands instantaneously without needing to create another connection. With the service system, the server can also push data to the client without the client explicitly requesting for information. Therefore, events on the server-side can be sent to the client for the client-side plugins use or simply for the users information.

85

Results and Observations

This section presents the test cases used by the proponents to test the system. It includes input or conditions for testing, the expected results as well as the actual results.

6.1

User Acceptance Testing

The user acceptance testing was conducted with eight people as the testers. They were asked to create web applications of their own using the IDE and at the same time pay attention to using as much features in the IDE as they could. Afterwards, all of them were asked to answer a survey about their experience. The survey focused on the user interface, the functionalities, and the overall suitability of the IDE to the user needs.

6.1.1

User Interface

One of the questions in the survey asked if the user interface of the IDE is intuitive. Eight out of the eight testers answered yes. However, two out of eight stated that while the user interface was intuitive, its design was cluttered. All testers agreed that the components used in the user interface are appropriate for their use, and that they are correctly placed in the IDE. With regards to the suitability of the IDEs user interface to the functionalities, all testers also agreed that the user interface is suitable to creating, developing, running, deploying, and version control features of the IDE. The survey had a space dedicated for the comments and suggestions of the testers to further improve the user interface. Some of the comments say that the user interface look like that of other IDEs so it is easier to use, and that it looks clean and organized. Suggestions, on the other hand, requests more keyboard shortcuts, and draggable tabs.

6.1.2

Functionality

The functionality section of the survey reviewed if the functionalities that the users used during their testing worked properly, starting with the creation of projects and les, using the autocomplete, syntax highlighting, running, until the deploy functionality. Out of the eight testers, all agreed that the functionalities from the creation of projects and les up to the running feature worked. For the deploy functionality, one out of eight users answered that the functionality did not work. For each functionality tested, there is also spaces allotted for the testers to specify any problems encountered while making use of the functionality. Problems encountered with regards to creating projects and les include not being able to create a project on the rst try

86

and not being able to create a JSP le. There were one problem encountered each for autocomplete and syntax highlighting. The problem encountered for auto-complete is that it did not work at rst try; while the problem encountered for syntax highlighting is that the coloring was not correct once the user typed a string with a series of quotation marks in java in a JSP le. The run feature had two problems to two testers. One of which is a suggestion that there is a keyboard shortcut for it, and another saying that there was no notication that there had been a syntax error on the testers code causing the testers application not to run. There were no problems encountered in the deploy feature.

6.1.3

Suitability

The last section of the survey tackled the overall suitability of the IDE to the users needs. One of the questions was what additional features should the IDE have to make it more suitable for developers to use. Answers include keyboard shortcuts, auto-import, syntax error detection, auto-generation of closing brackets in the editor, generation of javadocs, auto-completion of HTML tags, as well as highlighting of partner tag, and visual editors for creating user interface. In a range of 1 -5, with 5 being the highest, ease of use of the IDE garnered a 4.25 average, and suitability to the needs of the users received a 4.38 average. Lastly, the survey asked the testers if they would use the IDE themselves, and eight out of eight testers answered yes.

6.2

Fwibble Me

Fwibble Me is a site where the users friends will post questions for them to answer. Logging in the site will require the user to have a google account. Upon successful login, the user can navigate to his or her friends page and ask questions. Using the Globe API, Fwibble Me can send an SMS message to alert the user that he or she has just received a new question. The proponents used CtrlSpace to develop Fwibble Me. The creation of the project and les function was used as it was needed for the application. The proponents also ran the project to see the progress of their work as they go along. The project was also deployed using the IDE and it is successfully hosted at the App Engine Server and the url is as follows: http://fwibbleme.appspot.com.

6.3

Performance Testing

This testing was done to test the performace of the IDE on the server. The proponents gathered 15 people to use the IDE deployed to the server. The rst thing that the testers did was to registe and there were not any problems met during that time. However, when the testers were asked to log in at the same time, the database crashed due to too many connections. This problem has already been remedied by using pooling to reuse connections to the database. However, the proponents would still like to use 15 users as a maximum accommodation for the current server.

87

6.4
6.4.1

Functionality Testing
New Project The user clicks the New menu item followed by the AppEngine Project option. A dialog box with project nature tree, project name text eld appears and Finish button. A dialog box with project nature tree, project name text eld appears and Finish button The user selects the Google AppEngine Web Project option as the project nature. The Google AppEngine Web Project option is clickable highlighted when clicked. The Google AppEngine Web Project option is clickable highlighted when clicked. The user inputs a valid project name into the project name text eld. A valid project name can only contain underscores, spaces, and alphanumeric characters. The inputted project name appears in the text eld. The inputted project name appears in the text eld.

Input Expected Results: Actual Results:

Input Expected Results: Actual Results:

Input

Expected Results: Actual Results:

Input

The user inputs a valid project name in the text eld and clicks the Finish button. Continued on next page

88

Expected Results:

Table 6.34 continued from the previous page The dialog box closes. The project is created. A record of the project is created in the database. The project is created with its corresponding components and stored under the CtrlSpace Data folder in the repository. The project explorer in the user interface refreshes, showing the newly created project with the correct project name and its components.The following components are automatically created once a project is created: <ProjectName> - bin - src -- META-INF --- jdoconfig.xml -- servlets --- HelloServlet.java - WebContent -- WEB-INF --- classes --- lib ---- appengine-api-1.0-sdk-1.3.1.jar ---- appengine-api-labs-1.3.1.jar ---- appengine-jsr107cache-1.3.1.jar ---- appengine-local-runtime-shared.jar ---- datanucleus-appengine-1.0.5.final.jar ---- datanucleus-core-1.1.5.jar ---- datanucleus-jpa-1.1.5.jar ---- geronimo-el_1.0_spec-1.0.1.jar ---- geronimo-jpa_3.0_spec-1.1.1.jar ---- geronimo-jsp_2.1_spec-1.0.1.jar ---- geronimo-jta_1.1_spec-1.1.1.jar ---- geronimo-servlet_2.5_spec-1.2.jar ---- jdo2-api-2.3-eb.jar ---- jsr107cache-1.1.jar ---- LICENSE ---- repackaged-appengine-ant-1.6.5.jar ---- repackaged-appengine-ant-launcher-1.6.5.jar ---- repackaged-appengine-commons-el-1.0.jar ---- repackaged-appengine-commons-logging-1.1.1.jar ---- repackaged-appengine-jasper-compiler-5.0.28.jar ---- repackaged-appengine-jasper-runtime-5.0.28.jar --- appengine-web.xml --- logging.properties --- web.xml -- index.jsp The status message Project created successfully is shown. Continued on next page

89

Actual Results:

Table 6.34 continued from the previous page The dialog box closes. The project is created. A record of the project is created in the database. The project is created with its corresponding components and stored under the CtrlSpace Data folder in the repository. The project explorer in the user interface refreshes, showing the newly created project with the correct project name and its components.The following components are automatically created once a project is created: <ProjectName> - bin - src -- META-INF --- jdoconfig.xml -- servlets --- HelloServlet.java - WebContent -- WEB-INF --- classes --- lib ---- appengine-api-1.0-sdk-1.3.1.jar ---- appengine-api-labs-1.3.1.jar ---- appengine-jsr107cache-1.3.1.jar ---- appengine-local-runtime-shared.jar ---- datanucleus-appengine-1.0.5.final.jar ---- datanucleus-core-1.1.5.jar ---- datanucleus-jpa-1.1.5.jar ---- geronimo-el_1.0_spec-1.0.1.jar ---- geronimo-jpa_3.0_spec-1.1.1.jar ---- geronimo-jsp_2.1_spec-1.0.1.jar ---- geronimo-jta_1.1_spec-1.1.1.jar ---- geronimo-servlet_2.5_spec-1.2.jar ---- jdo2-api-2.3-eb.jar ---- jsr107cache-1.1.jar ---- LICENSE ---- repackaged-appengine-ant-1.6.5.jar ---- repackaged-appengine-ant-launcher-1.6.5.jar ---- repackaged-appengine-commons-el-1.0.jar ---- repackaged-appengine-commons-logging-1.1.1.jar ---- repackaged-appengine-jasper-compiler-5.0.28.jar ---- repackaged-appengine-jasper-runtime-5.0.28.jar --- appengine-web.xml --- logging.properties --- web.xml -- index.jsp

90

Input Expected Results:

Actual Results:

The user inputs an invalid project name into the project name text eld. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user inputs and invalid project name and clicks the Finish button The Finish button is clickable but with no results. The dialog box does not close. The Finish button is clickable but with no results. The dialog box does not close.

91

6.4.2

New Folder The user clicks the New menu item followed by the Folder option or right click and select Newfollowed by Folder. A dialog box containing two text elds for the source le destination and the folder name and a Finish button appears. A dialog box containing two text elds for the source le destination and the folder name and a Finish button appears. The user inputs a source le path into the source le destination text eld. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs a valid folder name. A valid folder name may only contain spaces, underscores, and alpha-numeric characters. The folder name inputted appears on the text eld. The folder name inputted appears on the text eld.

Input Expected Results: Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

92

Input Expected Results:

Actual Results:

The user inputs an invalid folder name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The user inputs a source le destination (example: src/com) and a valid folder name, then clicks the Finish button. The user inputs a source le destination (example: src/com) and a valid folder name, then clicks the Finish button. The user inputs a source le destination (example: src/com) and a valid folder name, then clicks the Finish button. The user inputs a source le destination (example: src/com/ctrlspace/commands) and a valid folder name, then clicks the Finish button. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. In the example, the commands folder is created under the ctrlspace folder which is under the com folder. If ctrlspace and com are not existing yet, these folders is created. The status message Folder successfully created. appears. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. In the example, the commands folder is created under the ctrlspace folder which is under the com folder. If ctrlspace and com are not existing yet, these folders is created. The status message Folder successfully created. appears. The user inputs an invalid source le destination (with special characters) and a valid folder name, then clicks the Finish button. The dialog box closes, and the status message: Folder creation failed. appears. The dialog box closes, and the status message: Folder creation failed. appears. The user inputs a valid source le destination and a folder name that already exists. The dialog box closes, and the status message: Folder already exists. appears. The dialog box closes, and the status message: Folder already exists. appears.

Input Expected Results: Actual Results:

Input

Expected Results:

Actual Results:

Input

Expected Results: Actual Results:

Input Expected Results: Actual Results:

93

6.4.3

New Package The user clicks the New menu item followed by the Package option or right click and select New followed by Package. A dialog box containing a text eld for the package name appears. A dialog box containing a text eld for the package name appears. The user inputs a valid source le path into the source le destination text eld. A valid source path may only contain alphanumeric characters, dots, and underscores. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs an invalid source le path into the source le destination text eld. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain underscores, dots, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain underscores, dots, and alpha-numeric characters.

Input Expected Results: Actual Results: Input

Expected Results: Actual Results: Input Expected Results:

Actual Results:

94

Input Expected Results:

Actual Results:

The user inputs a valid source le destination (example: com), then clicks the Finish button. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. The status message Package successfully created. appears. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. The status message Package successfully created. appears.

Input Expected Results:

Actual Results:

The user inputs a valid source le destination (example: com.ctrlspace.commands), then clicks the Finish button. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. In the example, the commands folder is created under the ctrlspace folder which is under the com folder. If ctrlspace and com are not existing yet, these folders is created. The status message Package successfully created. appears. A new folder is created to its corresponding path in the CtrlSpace Data folder in the repository. The project explorer refreshes, showing the newly created folder with the correct name. In the example, the commands folder is created under the ctrlspace folder which is under the com folder. If ctrlspace and com are not existing yet, these folders is created. The status message Package successfully created. appears.

Input Expected Results: Actual Results:

The user inputs a source le destination that already exists. The dialog box closes, and the status message: Package already exists. appears. The dialog box closes, and the status message: Package already exists. appears.

95

6.4.4

New Enum The user clicks the New menu item followed by the Enum option or right click and select New followed by Enum. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid le name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The inputted le name appears on the text eld for the le name. The inputted le name appears on the text eld for the le name.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

96

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results:

Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. A new enum le is created in the right path. The project tree refreshes and shows the newly created enum le. The status message: Enum created successully. appears. The dialog closes, but no new enum class is created.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and an invalid le name, then clicks the Finish button. The dialog box closes, and the status message: Enum creation failed. appears. The dialog box does not close.

97

6.4.5

New Interface The user clicks the New menu item followed by the Interface option or right click and select New followed by Interface. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid le name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The inputted le name appears on the text eld for the le name. The inputted le name appears on the text eld for the le name.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

98

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. A new interface le is created in the right path. The status message: Interface created successully. appears. A new interface le is created in the right path. The status message: Interface created successully. appears.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and an invalid le name, then clicks the Finish button. The dialog box does not close. The dialog box does not close.

99

6.4.6

New Java Class The user clicks the New menu item followed by the Java Class option or right click and select New followed by Java Class. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid le name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The inputted le name appears on the text eld for the le name. The inputted le name appears on the text eld for the le name.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

100

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. A new java class le is created in the right path. The status message: Java Class created successfully. appears. A new java class le is created in the right path. The status message: Java Class created successfully. appears.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and an invalid le name, then clicks the Finish button. The dialog box does not close. The dialog box does not close.

101

6.4.7

New CSS File The user clicks the New menu item followed by the CSS option or right click and select New followed by CSS. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. The user inputs a source le path into the source le destination text eld. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

102

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user enters a valid source le path and a valid le name then presses the Finish button. A new CSS le is created in the right path. The status message: CSS created successully. appears. A new CSS le is created in the right path. The status message: CSS created successully. appears.

103

6.4.8

New HTML File The user clicks the New menu item followed by the HTML option or right click and select New followed by HTML. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. The user inputs a source le path into the source le destination text eld. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs a source le path into the source le destination text eld.The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input

Expected Results: Actual Results:

104

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user enters a valid source le path and a valid le name then presses the Finish button. A new HTML le is created in the right path. The status message: HTML File created successfully. appears. A new HTML le is created in the right path. The status message: HTML File created successfully. appears.

105

6.4.9

New JS File The user clicks the New menu item followed by the JS option or right click and select New followed by JS. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. The user inputs a source le path into the source le destination text eld. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

106

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user enters a valid source le path and a valid le name then presses the Finish button. A new JS le is created in the right path. The status message: JS File created successfully. appears. A new JS le is created in the right path. The status message: JS File created successfully. appears.

107

6.4.10

New JSP File The user clicks the New menu item followed by the JSP option or right click and select New followed by JSP. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a text eld for the le location and a text eld for the le name appears. The project folders contain the server-side les of the project. The user inputs a source le path into the source le destination text eld. The source path specied appears on the text box. The source path specied appears on the text box. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

108

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that Project name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user enters a valid source le path and a valid le name then presses the Finish button. A new JS le is created in the right path. The status message: JSP File created successfully. appears. A new JS le is created in the right path. The status message: JSP File created successfully. appears.

109

6.4.11

New Servlet File The user clicks the New menu item followed by the Servlet option or right click and select New followed by Servlet. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

110

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. A new servlet le is created in the right path. The status message: Servlet created successfully. appears. A new servlet le is created in the right path. The status message: Servlet created successfully. appears.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. The dialog box does not close. The dialog box does not close.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a le name which already exists, then clicks the Finish button. The status message: Servlet already exists. appears. The status message: Servlet already exists. appears.

111

6.4.12

New Filter The user clicks the New menu item followed by the Filter option or right click and select New followed by Filter. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. A dialog box containing a tree of the project folders and a text eld for the le name appears. The project folders contain the server-side les of the project. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

112

Input Expected Results:

Actual Results:

The user inputs an invalid le name. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. A new lter le is created in the right path. The status message: Filter created successfully. A new lter le is created in the right path. The status message: Filter created successfully.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a valid le name, then clicks the Finish button. The dialog box does not close. The dialog box does not close.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a le name which already exists, then clicks the Finish button. The status message: Filter already exists. appears. The status message: Filter created successfully. appears.

113

6.4.13

New Listener The user clicks the New menu item followed by the Listener option or right click and select New followed by Listener. A dialog box containing a tree of the project folders and a text eld for the le name appears. There is a next button wherein if clicked, will show the options to customize the template of the listener le. A dialog box containing a tree of the project folders and a text eld for the le name appears. There is a next button wherein if clicked, will show the options to customize the template of the listener le. The user selects a member of the project tree. The selected option is clickable highlighted when clicked. The selected option is clickable highlighted when clicked. The user inputs a valid folder name. A valid le name may only contain spaces, underscores, and alpha-numeric characters. The le name inputted appears on the text eld. The le name inputted appears on the text eld.

Input Expected Results:

Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

114

Input Expected Results: Actual Results:

The user inputs an invalid le name. A warning message beside the text eld appears stating that The value entered is not valid. A warning message beside the text eld appears stating that The value entered is not valid.

Input

Expected Results: Actual Results:

The user selects a package path through the project tree, a valid le name, and then clicks on the checkbox options needed corresponding to the template the user desires, then clicks the Finish button. A new listener le is created in the right path. The status message: Listener created successfully. appears. A new listener le is created in the right path. The status message: Listener created successfully. appears.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and an invalid le name, then clicks the Finish button. The dialog box does not close. The dialog box does not close.

Input Expected Results: Actual Results:

The user selects a package path through the project tree and a le name which already exists, then clicks the Finish button. The status message: Listener already exists. appears. The status message: Listener created successfully. appears.

115

6.4.14

Open File Double-click a le from the project tree in the project explorer. A new code editor appears showing the contents of the selected le. The code editor also displays line numbers. A new code editor appears showing the contents of the selected le. The code editor also displays line numbers.

Input Expected Results: Actual Results:

116

6.4.15

Close File The exit button of a selected code editor is clicked. The code editor is closed and disappears. The code editor is closed and disappears.

Input Expected Results: Actual Results:

117

6.4.16

Save File The contents of the code editor is changed. Ctrl + S hotkey is pressed. An asterisk appears to signify that changes have been made to the contents of the le. When the hotkey is pressed, the asterisk disappears and the changes made reects on the actual le in the repository. An asterisk appears to signify that changes have been made to the contents of the le. When the hotkey is pressed, the asterisk disappears and the changes made reects on the actual le in the repository.

Input Expected Results:

Actual Results:

118

6.4.17

Run Project A project with no syntax errors is selected followed by clicking the Project menu item then the Run Project option. A new browser or browser tab appears showing the application. A new browser or browser tab appears showing the application. A project with syntax errors is selected followed by clicking the Project menu item then the Run Project option. The console shows the syntax errors committed. The console shows the syntax errors committed.

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

119

6.4.18

Deploy Project A project is with no syntax errors is selected followed by clicking the Project menu item then the Deploy Project option. A dialog box appears with text elds for email, password, application id and proxy. A dialog box appears with text elds for email, password, application id and proxy. The user inputs a valid email address. The inputted email address will appear on the text box. The inputted email address will appear on the text box. The user inputs invalid characters in the email text eld. A message stating Invalid E-mail Address is shown beside the email text eld. A message stating Invalid E-mail Address is shown beside the email text eld.

Input Expected Results: Actual Results:

Input Expected Results: Actual Results: Input Expected Results: Actual Results:

120

Input Expected Results: Actual Results:

The user inputs the correct email address, password, application id and proxy (optional). The project is deployed to the AppEngine Server. The project is deployed to the AppEngine Server.

Input Expected Results: Actual Results:

The user inputs the incorrect email address or password or application id and or proxy (optional). The project is not deployed to the AppEngine Server. The project is not deployed to the AppEngine Server.

121

6.4.19

Auto-complete A primitive data type is instantiated (example: String s;). The variable of the instantiated primitive data type is typed with a dot after it (example: s.), then the Ctrl + space hotkey is pressed. The methods corresponding to the primitive data type appears in a drop down box beside the variable. The methods corresponding to the primitive data type appears in a drop down box beside the variable. A variable with a data type imported (either by external resources or objects from another package) is instantiated (example: arraylist called list). The variable of the instantiated data type is typed with a dot after it (example list.), then the Ctrl + space hotkey is pressed. The methods corresponding to the primitive data type appears in a drop down box beside the variable. The methods corresponding to the primitive data type appears in a drop down box beside the variable. A variable with a Object from the same package is instantiated. The variable of the instantiated data type is typed with a dot after it, then the Ctrl + space hotkey is pressed. The methods corresponding to the primitive data type appears in a drop down box beside the variable. The methods corresponding to the primitive data type appears in a drop down box beside the variable.

Input

Expected Results: Actual Results:

Input

Expected Results: Actual Results:

Input

Expected Results: Actual Results:

122

Input

Expected Results: Actual Results:

A variable with an unknown data type is instantiated. The variable of the instantiated data type is typed with a dot after it, then the Ctrl + space hotkey is pressed. Nothing happens. Nothing happens.

Input Expected Results: Actual Results:

Once the dialog box appears, and an option is selected. The method and its parameters is printed to the place of the cursor. The method and its parameters is printed to the place of the cursor.

123

6.4.20

Syntax Highlighting A CSS le is opened. The contents of the CSS le are color-coded: violet for the @ sign and values, black for indentiers, blue for color codes, yellow for color codes, and red for strings. The contents of the CSS le are color-coded: violet for the @ sign and values, black for indentiers, blue for color codes, yellow for color codes, and red for strings. A Java le is opened. The contents of the Java le are color-coded: black for indentiers, yellow for comments, red for strings, blue for keywords, and violet for punctuations. The contents of the Java le are color-coded: black for indentiers, yellow for comments, red for strings, blue for keywords, and violet for punctuations. A JS le is opened. The contents of the JS le are color-coded: green for punctuations and operators, violet for keywords, black for variables, blue for variable denitions, yellows for comments, and red for strings. The contents of the JS le are color-coded: green for punctuations and operators, violet for keywords, black for variables, blue for variable denitions, yellows for comments, and red for strings.

Input Expected Results:

Actual Results:

Input Expected Results:

Actual Results:

Input Expected Results:

Actual Results:

124

Input Expected Results:

Actual Results:

An HTML, XML or JSP le is opened. The contents of the le are color-coded: violet for tag names, black for punctuations, green for attributes, yellow for comments, and blue for cData. The contents of the le are color-coded: violet for tag names, black for punctuations, green for attributes, yellow for comments, and blue for cData.

125

6.4.21

Copy File or Folder then Paste A le or folder is selected and right-clicked, followed by selecting the Copy menu item. Then another folder is selected, followed by selecting the Paste menu item. The le or folder chosen to be copied is copied into the folder selected. This is reected in the repository. The project tree refreshes, showing the updated contents of the projects. The le or folder chosen to be copied is copied into the folder selected. This is reected in the repository. The project tree refreshes, showing the updated contents of the projects.

Input

Expected Results:

Actual Results:

126

6.4.22

Cut File or Folder then Paste A le or folder is selected and right-clicked, followed by selecting the Cut menu item. Then another folder is selected, followed by selecting the Paste menu item. The le or folder chosen to be copied is copied into the folder selected and is deleted from the location it was originally placed. This is reected in the repository. The project tree refreshes, showing the updated contents of the projects. The le or folder chosen to be copied is copied into the folder selected and is deleted from the location it was originally placed. This is reected in the repository. The project tree refreshes, showing the updated contents of the projects.

Input

Expected Results:

Actual Results:

127

6.4.23

Rename File or Folder A le or folder is selected and right-clicked, followed by selecting the Rename menu item. A dialog box with a text eld for the new name of the selected le or folder appears. A dialog box with a text eld for the new name of the selected le or folder appears. A valid le or folder name is entered on the text eld. The inputted value appears on the text eld. The inputted value appears on the text eld. An invalid le or folder name is entered on the text eld. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters. The text eld becomes yellow and a warning icon on the right side of the text eld appears. A warning message beside the text eld appears stating that File name can only contain spaces, underscores, and alpha-numeric characters.

Input Expected Results: Actual Results:

Input Expected Results: Actual Results: Input Expected Results:

Actual Results:

128

Input Expected Results: Actual Results:

A valid le or folder name is entered and the Submit button is clicked. The le or folder name selected is changed. The project tree refreshes and the updated information is reected on the tree. The le or folder name selected is changed. The project tree refreshes and the updated information is reected on the tree.

Input Expected Results: Actual Results:

A valid le or folder name is entered and the Submit button is clicked. Nothing happens. Nothing happens.

129

6.4.24

Delete File or Folder A le or folder is selected and right-clicked, followed by selecting the Delete menu item. The le or folder is deleted. The project tree refreshes and the updated contents is reected on the tree. The le or folder is deleted. The project tree refreshes and the updated contents is reected on the tree.

Input Expected Results: Actual Results:

130

6.4.25

Import Library A element of the project is selected and right-clicked, followed by selecting the Import Library menu item. A dialog box appears with a Browse button and a Submit button. When the Browse button is clicked, a le picker appears, enabling the user to select a le to be uploaded. A dialog box appears with a Browse button and a Submit button. When the Browse button is clicked, a le picker appears, enabling the user to select a le to be uploaded. A le is selected, then the Submit button is clicked. If the le selected is a JAR le, then it is added to the WebContent/WEB-INF/lib folder of the project. If not, then nothing happens. If the le selected is a JAR le, then it is added to the WebContent/WEB-INF/lib folder of the project. If not, then nothing happens.

Input Expected Results:

Actual Results:

Input Expected Results:

Actual Results:

131

Conclusion and Recommendations

This chapter presents explanations and justications on how the objectives of the project were and were not met. This chapter also includes the recommendations of the proponents regarding possible improvements of the project in the future so as it may be an avenue for new research.

7.1

Conclusion

CtrlSpaces objective is basically to create a web-based IDE that besides allowing its users to create, edit, and run their projects, it also provides syntax highlighting and auto-complete functionalities for the users. Another objective is to allow users to deploy their project immediately to the Google App Engine Server in attempt to make deployment of applications easier for the users. It also aims to provide version control functionality and database management through the user interface for the users. The most important objective of CtrlSpace however, is the implementation of a plugin architecture where components for different features may be added by other developers who would like to extend this work. The objectives of syntax highlighting and auto-complete were met. The syntax highlighting feature supports highlighting for Java, HTML, CSS, among others. The auto-complete feature, on the other hand, supports retrieving methods from external resources of a project, classes from the same package as the given le, and imported libraries from the Java library. The objective to deploy projects was also met as users can deploy their created App Engine projects as long as they register their applications with Google App Engine. The plugin architecture was also met as plugins for le types, project types, syntax highlighter, and auto-complete functionalities are supported. The plugin architecture was also developed to support the Globe API. However, one of the objectives namely supporting a database explorer for Google App Engine projects was not met. This is due to the fact that the DataStore of a project (which is the database representation of App Engine projects) cannot be accessed by anything other than the App Engine project corresponding to itself. However, there are possibilities of going around this limitation which will be discussed in the recommendations part of this research.

7.2

Recommendations

This section discusses suggested endeavors for future developers who wish to extend this project.

7.2.1

Database Explorer

Due to the fact that the DataStore of a project cannot be accessed by external projects, the database explorer cannot be implemented currently in this project. However, there might be a way around this limitation if there is a mechanism embedded in the Google App Engine projects

132

when they are created. This mechanism may be a tool that allows external resources to access the contents of the DataStore of that project.

7.2.2

Plugins

Future developers are encouraged to make use of the plugin system of CtrlSpace and create more of the different types of plugins that CtrlSapce offers including le types, project types, syntax highlighters, and auto-complete functionalities. This would expand the capabilities of the IDE and hopefully attract a wider range of users.

7.2.3

Plugin System

The plugin system may be further rened by other developers especially since it is the most important feature of the architecture. Its design may be modied to be able to make creating plugins easier for other developers. Future developers who would like to continue the project may also create an environment for aiding the creation of plugins. They may create a community where tutorials, collections of plugins, and forums are present to aid plugin developers in their work. This would expand the range of projects CtrlSpace can support and hopefully would make the IDE not limited to only Google App Engine projects and made more available to users.

7.2.4

GUI Interface

Currently, CtrlSpace does not support a GUI interface, but it would be greatly benecial if future developers would add this to the IDE as it is supposed to make it easier for IDE users to create their user interfaces. Thus, the IDE may be lifted closer to the standards like that of Eclipse and Netbeans, and also would hopefully attract more users.

Refactoring Several components of the system are still coded in such a way that it is not quite understandable to future developers. By refactoring the code furthermore, the functionality of the system will remain but the design and the way it is coded will be more extensible, scalable and readable.

Javadoc Aside from the user and technical manual to be created, a Javadoc is useful especially for this kind of project because it presents to the developers an easier to read documentation of the system functions that are available to them.

133

Resource Persons

Mr. Danny C. Cheng Adviser College of Computer Studies De La Salle University-Manila [email protected] Mr. Karlo Shane O. Campos Panelist College of Computer Studies De La Salle University-Manila [email protected]

134

Personal Vitae

Ms. Richelle Charmaine G. Co 1027 Benavidez Street, Binondo, Manila, 1006 (+632) 244 8585 [email protected] [email protected] Mr. Marc Anthony M. Obaldo 162 Maginhawa Street, Sikatuna Village, Quezon City, 1101 (+632) 433 3812 [email protected] [email protected] Ms. Audrey Elaine G. Ong 12 Labo Street corner Maria Clara Street, Santa Mesa Heights, Quezon City, 1114 (+632) 740 2039 [email protected] [email protected]

135

Survey Results

See Attached table.

136

References
Aptana. (2009). Aptana - the leading ide for web app development. Retrieved on July 30, 2009 from Aptana web site: http://www.aptana.com/. Beaton, W. (2006). Eclipse platform technical overview. Retrieved on November 02, 2009 from http://www.eclipse.org/articles/Whitepaper-Platform-3.1/ eclipse-platform-whitepaper.html. Bespin. (2009). Bespin - code in the cloud. Retrieved on July 30, 2009 from Mozilla Labs web site: http://bespin.mozilla.com/. Cheng, L.-T., Souza, C. R. de, Hupfer, S., Patterson, J., & Ross, S. (2004). Building collaboration into ides. Queue, 1(9), 4050. Code, G. (2009a). Data java api overview. Retrieved on November 02, 2009 from http://code.google.com/appengine/docs/java/datastore/overview.html# Transactions and Entity Groups. Code, G. (2009b). What is google appengine? Retrieved on November 02, 2009 from http:// code.google.com/appengine/docs/whatisgoogleappengine.html. CodeRun. (2009). About coderun. Retrieved on July 30, 2009 from CodeRun web site: http:// www.coderun.com/About/Tour/. Cubrani , D., & Storey, M. A. D. (2005). Collaboration support for novice team programming. In c Group 05: Proceedings of the 2005 international acm siggroup conference on supporting group work (pp. 136139). New York, NY, USA: ACM. ECCO. (2009). Ecco, a web-based ide inside your browser. Retrieved on July 30, 2009 from ECCO web site: http://ecco.sourceforge.net/. Felten, E. (2009). What economic forces drive cloud computing? Freedom to Tinker . Retrieved on August 28, 2009 from http://www.freedom-to-tinker.com/blog/felten/ what-economic-forces-drive-cloud-computing. Jazz. (2009). Ibm jazz overview. Retrieved on July 30, 2009 from IBM Rational web site: http://www.ibm.com/software/rational/jazz. Jingwen Ou, M. R., Mahdi Najaran. (2007). Aurora sdk: A web based integrated development environment. JSON. (n.d.). Json. Retrieved on November 02, 2009 from http://json.org/. Patil, S. (2009). Introduction to the dojo toolkit, part 1: Setup, core, and widgets. Retrieved on November 02, 2009 from "http://www.javaworld.com/javaworld/jw-01-2009/jw-01 -introduction-to-dojo-1.html". PhpAnywhere. (2009). About php anywhere, coding on the go. Retrieved on July 30, 2009 from PhpAnywhere web site: http://phpanywhere.net/about. Pijanowski, K. (2009). Understanding public clouds: Iaas, paas, & saas. Retrieved on August 28, 2009 from http://www.keithpij.com/Home/tabid/36/EntryID/27/Default.aspx. Rubel, D. (2006). The heart of eclipse. Queue, 4(8), 3644. Scanlon, J. H., & Wieners, B. (1999). The internet cloud. Retrieved on August 28, 2009 from http://www.thestandard.com/article/0,1902,5466,00.html. Slack, S. (2009). Is there value in cloud computing? Retrieved on August 28, 2009 from http://www.ibm.com/developerworks/opensource/library/ar -valuecloudcomputing/index.html. Whitehead, J. (2007). Collaboration in software engineering: A roadmap. In Fose 07: 2007 future of software engineering (pp. 214225). Washington, DC, USA: IEEE Computer Society.

137