Keeping a Simple Development Environment

When going into this project I wanted to create an environment that was very easy for the users to use even if it meant more work on the development end, and I still believe that. Now that I have released the first version of the first application component I believe I fully realise that our users are not just the end users but they are also the developers. I myself have become both and end user and a developer user. When it is easy to contribute code or work to a project more people want to do it. If the development environment requires you to install Django on your laptop even though all you want to do is write some math library in javascirpt, that is a bad development environment. As a result I have tried to keep the environment simple. Django does not like static files, part of the reason why I am leaving all the Django work to Beth, so you cannot just write a web-app in your file-system and expect it to work on Django, you cant even write one using an apache server and expect it to run on just Django. I am not sure exactly what you need to change but there are some elements that do need to be changed. The way it is currently set up is that static files can be accessed but only through absolute paths. The absolute path on the server and the absolute path on your development platform are not going to be the same. So how to fix this problem. In Django the relative paths will not load and in Apache or a file system the absolute paths will not necessarily load. Django has a small fix for the absolute path problem by replacing the root of the absolute path with {{STATIC_URL}} we can create an absolute path with the root from the applications folder. If we include both the absolute path and the relative path depending on which environment you are using one of them will work and the other will not. relative will break on Django but the absolute will work, and  relative will work on everything else but the absolute will not. So by including both we know that the external file will load no matter what environment you are in.

Using JQuery

There are some people in the development community who avoid libraries like JQuery. So this is why we are using JQuery. It provides many features that make javascript simple, like AJAX request and animations. However JQery also has a unique onload method. You use it by passing a function into  $(document).ready(). The reason this is so important is that while docuent.onload can only have one functions set to it, you can add add multiple functions to .ready(). This way we can make plugins and components without having to worry about them overwriting each others onload functions.

Beginnings of the XML Menu and Menu API

A few weeks ago I set out to figure out the best way to create menus in our applications that were easy to use. At first the results were pretty bad. The menus would stack or they would not now up at all. Once I believe i even got one to pertinently stick to the middle of the screen. But now the menus are working quite well. The first alpha of the menu system is what I would call it. It is very simple to use as well. All of this information will be in the wiki as well. Individual menus for each application can be created via XML and different cross application styles can be created using CSS.

Alpha Build of XML Menu

Including the menu in your code

<script type="text/javascript" src="menu.js"></script>
<div id="TitleMenu"></div>

Include the javascript file and then put the menu div where ever you want the main title bar to go. Usually it is put first thing in the body. In later version you will be able to put the menus (or other menus) on the left and right sides of the screen
Creating the menu (in xml):

<XMLMenu>
  <menu name="File" iconsrc="icons/action_forward.gif" version="normal">
    <button name="save" function="save()" enabled="true" iconsrc="icons/action_save.gif" shortcutKey="Ctrl+S" version="normal"> </button>
    <button name="load" function="load()" enabled="true" iconsrc="icons/action_back.gif" shortcutKey="Ctrl+L" version="normal"> </button>
    <break></break>
    <menu name="Feature Select" iconsrc="icons/action_go.gif" version="normal">
      <button name="Feature One"   function="alert('one')"   iconsrc="icons/flag_blue.gif" shortcutKey="Shft+Ctrl+1" version="normal"> </button>
      <button name="Feature Two"   function="feature('two')"   iconsrc="icons/flag_green.gif" shortcutKey="Shft+Ctrl+2" version="normal"> </button>
      <button name="Feature Three" function="feature('three')" iconsrc="icons/flag_orange.gif" shortcutKey="Shft+Ctrl+3" version="normal"> </button>
      <button name="Feature Four"  function="feature('four')"  iconsrc="icons/flag_red.gif" shortcutKey="Shft+Ctrl+4" version="normal"> </button>
      <button name="Feature Five"  function="feature('five')"  iconsrc="icons/flag_white.gif" shortcutKey="Shft+Ctrl+5" version="normal"> </button>
    </menu>
  </menu>
  <menu name="Edit" iconsrc="" version="normal">
    <button name="copy" function="copy()" iconsrc="icons/copy.gif" shortcutKey="Ctrl+S" version="normal"> </button>
  </menu>
</XMLMenu>

the XMLMenu element is the wrapper for the XML menu
The three elements, menu, button, and break, all create different menu elements. If you nest elements inside of a menu element then they will show up as a sub menu. If you try to nest them in any other element (break or button) then they will be ignored. Every menu or button has a name and an image icon associated with them. Buttons have a function to run if they are clicked and all attributes have a version. The version does not do anything right now but in the future it will indicate advanced features of the menu system. XML above is the XML used to create the menu in the screen shot.

Allowed Users and UGRS

Today Asher and I submitted our abstract for Briefcase to the undergrad research symposium. Not much else to say about that 🙂

We also worked on getting allowed_users working. I added a many to many relationship field to the Spreadsheet database model that links with the UserProfile model. Asher changed it so that the owner username and the file primary key can be sent through the url. Now not only can you view a spreadsheet if you are the owner, you can also view someone else’s spreadsheet if you are logged into an account that is in the allowed users list for that file.

Automatic Server Updating

Though I recently wrote a post. I recently struggled with a problem I found more difficult then most.
For a while we manually updated our server. It worked quite seamlessly to any observer.
But now it automaticly gets our code from online, the solution could possibly be considered divine.
So to you all I would like to bestow, our simple PHP code below.

<?php
  echo "Pulling Repo <br>";
  echo exec("cd /home/shared/Briefcase; git pull readonly master");
  echo "<br> Finished";
?>

‘Live Editing’ problems and a possible solution

We are at the stage where I believe that we can implement live coding (and live spreadsheets) however I am running into a few problems. These problems are not actually with the algorithm for syncing code they are with the undo stack (ctrl-z). Here is the problem: when javascript edits a segment of text that the user is able to select then the native undo stack is deleted or made unusable. This makes sense because the computer now has no idea what has been changed by the javascript and cannot justly apply the undo action to data that could be completely different. I have been informed that javascript is getting a standard way of controlling native undo functionality but for now it does not work.

The solution. Create a custom undo stack. This stack would be able to adapt to the changes of external users as well.  This stack would not be too complicated it would be an array of associated ‘region’ values of what the code used to be and what the code is now. This way you get the undo and the redo capabilities. As a result this stack can also be used as a monitor to what has and has not been sent to the server because it contains the regions of typed text already. I just actually came up with that idea now, interesting how just writing out ideas in a blog can help you find solutions.

Asher Glick
Keep Going

Databases

Today I started switching the file system over to django models and linking them with owner users. I didn’t get very far, but I’m meeting with Asher on saturday to make more progress. Some of the stuff I need to do I can’t do without him since I don’t know much about his front end. Hopefully at the end of saturday we will have saving and loading spreadsheets from the database working – including being able to save multiple files.

Also, I actually used something I learned in the database systems class I’m currently taking. Even though django models the database for you based off of your models, you still need to manage the types of relationships to a degree. I started messing with adding a many to many field to the spreadsheet model that would represent the “allowed users” relationship between spreadsheets and user profiles.

Presentation And Realizations

Last Friday (the 10th) we gave a presentation to RCOS.  We were able to learn a lot of things from peers. Two things of importance are where to save the files. Previously we were using a files system, this has been replaced with a database, much better. The other important thing is syntax highlighting. Colin Kuebler with the Koala project has spent a year learning and experimenting with syntax highlighting inside web browsers. While I initially assumed that the style of highlighting he used was inefficient and not-cross browser capable I now find that his method is actually one of the most efficient methods out there. Hopefully one of the next features we will have is the multi user editable content.

The presentation can be found at: Breifcase_Presentation_3

Saving and Loading

Last weekend we got the saving and loading feature to work for the spreadsheet and django using ajax.We will be expanding this feature in the coming weeks to include:

  • Multiple files to be saved by each user
  • Multiple file types to be saved by each user
  • Files can be shared in between users
  • Files can be edited by multiple users at the same time

An API for saving and loading is also going to be developed. This will help when creating more complex applications with more then one central data source. It will be able to take in a variable (or multiple variables) and send an AJAX request to the server. The functions will also be able to get the file via AJAX from the server and parse into it’s individual variables.

Merging, 403s, and Ajax

So today Asher and I worked together for a few hours. We merged my laptop branch back with the master branch. I also changed some of the folder structure and updated the absolute paths needed in the settings file to reflect those changes and the merge.

We mostly worked on implementing saving – aka getting an ajax post request processed in django. For a while we were getting a 403 error. We finally discovered it was because of djangos CSRF protection. After some changes on Asher’s side of things we successfully processed a request. The next step will be sending actual data and storing it on the server.

We also discovered that the server does not like when both of us try to push/pull/commit to github from it…so if our commit/push authors are a mess today that is why. Asher wants to implement a program that will have the server automatically pull the changes down so we can edit on our laptops and have the changes reflect there automatically.