Rough Draft of the Project Plan.
diff --git a/GCINewArchitectureGSoC2011.wiki b/GCINewArchitectureGSoC2011.wiki
index fa1f736..f0ff57f 100644
--- a/GCINewArchitectureGSoC2011.wiki
+++ b/GCINewArchitectureGSoC2011.wiki
@@ -8,20 +8,129 @@
 
 ----
 
-= Rough draft of the project plan = 
-== Pre-Coding Phase == 
- * Minor changes to the GCI models to make student/org_admin/mentor to refer to profile
- * Move list generator from gsoc module to the core and fix the corresponding imports
- * A RequestHandler to perform required customizations to handle HTTP requests
- * Construct GCI related URL patterns
- * Access checker specific to GCI
- * Views for Profile and the Program
+=Design and Implementation= 
+==Changes to the existing models== 
+Minor changes have to be made to the GCI models such that fields that refer to student/org_admin/mentor should now refer to profile as we are getting rid of Mentor/OrgAdmin entities and Students are defined by their StudentInfo coupled to the profile.
+===Implementation===
+ * A GCIProfile model will be written which extends soc.models.role.profile and the GCI specific fields are added to this model and the GCIStudentInfo model which is coupled to the student's profile.
+ * If someone is both OrgAdmin and Mentor for the same organization, then we will not need to update the GCIProfile with mentor information (mentor_for field).We assume that an org admin is also a mentor.
+ * After this, the references can be modified, for example 
+{{{
+reference_class=soc.modules.gsoc.models.student.GCIStudent
+}}}
+ is changed to 
+{{{
+reference_class=soc.modules.gsoc.models.profile.GCIProfile 
+}}}
+ * We will then write a script to update each of these references.
 
-==First two weeks of the Coding Phase==
- * Views for Program homepage
- * Organistaion registration, profile and homepage
- * Starting the  Dashboard functionality
- * Templates till this stage
+==Move list generator to the core== 
+As the list generator is required even for the GCI module, we move the list generatorfrom gsoc module to the core.
+===Implementation===
+ * Move gsoc.views.helper.lists to soc.views.lists and fix the corresponding imports
+==RequestData Object==
+A RequestData object that will be created for each request in the GCI module will be written.This extends the soc.views.helper.request_data.RequestData and GCI specific data is added to it.
+===Implementation===
+ * The GCI RequestData object contains the following fields
+  * site: The Site entity
+  * user: The user entity (if logged in)
+  * program: The GCI program entity that the request is pointing to
+  * program_timeline: The GCITimeline entity
+  * timeline: A TimelineHelper entity
+  * is_host: is the current user a host of the program
+  * is_mentor: is the current user a mentor in the program
+  * is_student: is the current user a student in the program
+  * is_org_admin: is the current user an org admin in the program
+  * org_map: map of retrieved organizations
+  * org_admin_for: the organizations the current user is an admin for
+  * mentor_for: the organizations the current user is a mentor for
+  * student_info: the StudentInfo for the current user and program
+ * The RequestData object contains methods like,
+  * getOrganization: To get the specified organization
+  * orgAdminFor: Tells if the user is Admin for the specified Organization
+  * mentorFor: Tells if the user is Mentor for the specified Organization
+  * appliedTo: Tells if the user has applied to a specified organization
+  * isPossibleMentorForTask : Checks if the user is possible mentor for the task in the data
+  * hasCompletedTask : Checks if the user has completed atleast one Task
+  * currentTaskState: Returns the user's current task state
+  * populate: To populate the fields in the RequestData object 
+  
+==Access checker specific to GCI==
+An access checker class that contains helper functions for checking access in the GCI module.
+===Implementation===
+ * Add the required objects to Mutator class to mutate the data object as requested, for example
+{{{
+from soc.modules.gci.models.task import 
+
+class Mutator(object):
+  # unset the data object first  
+  def unSetAll(self):  
+    self.data.task = unset 
+  
+  #kwargs which define a Task
+  def taskFromKwargs(self):
+    id = int(self.data.kwargs['id'])
+    self.data.task = GCITask.get_by_id(id, parent=self.data.profile) 
+}}}
+  * After finishing with the mutator class, we can have access checker methods like,
+   * isTaskInURLValid -> Checks if task in URL exists
+   * canStudentClaimTask -> Checks if the student can claim a Task.
+
+==URL Patterns==
+The GCI related URL Patterns should be created, they will be discussed in the implementation.
+===Implementation===
+ * The patterns will be returned in any of the following ways
+  * namedLinkIdPattern -> Returns a link ID pattern consisting of named parts
+  * namedIdBasedPattern -> Returns a url pattern consisting of named parts whose last element is a numeric id
+  * namedKeyBasedPattern -> Returns a url pattern consisting of named parts whose last element is a string representation of a Key instance
+
+==Redirects==
+A helper view for constructing GCI related redirects which can be used in other views for redirecting.
+===Implementation===
+ * A RedirectHelper class will be written for constructing required redirects.
+ * Here we set args/kwargs for a url_pattern.<TYPE> redirect, where TYPE can be organisation, profile,document etc
+  * For example,
+{{{
+self.kwargs['survey'] = survey
+}}} 
+ * Other methods that help redirects will be.
+  * urlOf -> Returns the resolved url for a name
+  * url -> Returns url of current state
+  * to -> Redirects to resolved url for name
+ * specific methods to set the _url/_url_name for particular redirects
+  * For example,
+{{{
+def homepage(self):
+  self.program()
+  self._url_name = 'gci_homepage'
+  return self
+}}}  
+ 
+==Site Menus==
+For now, the views for the site menus can be similar to that of the GSoC site menus with certain minor changes.
+
+==Required Views==
+The following are the basic views required, This section will be updated as the views are written.
+ * Public Task view
+ * Task subscription
+ * Work submission
+ * Program settings view
+ * Profile
+ * Admin
+ * Org application 
+ * Org Profile
+ * Org Homepage
+ * Dashboard
+ * Document
+ * Assign Mentor
+ * Student Ranking
+==Implementation==
+ * All the views will be basically have the following
+  * djangoURLPatterns -> To return required url pattern for the view
+  * checkAccess -> To check if a user has access to this view
+  * templatePath -> Returns the path to the template to be rendered
+  * context -> Returns the current context of the view
+ * A view will have other required methods specific to that view.
 
 ----