The purpose of this page is to create an outline, guide, etc.. of requirements and features for each iteration of the SAIL Authoring tool.
It sure is a smurfy day.
The first version of the authoring tool is be to the implementation of the Customizer-centric view of authoring. Preceding the customizer-centric implementation will be the composer-centric view.
Customizer Implementation Code Name: Brainy
Customizer Scenario
The Customizer is some one by definition opens up an already made unit and edits properties of activities and other modules on that unit. They save the unit and deploy.
- For example: Nadin the Customizer opens up the How Do Earth and Space Plants Grow? unit. She finds that the A Litte About Plants step is utter rubbish and wants to insert her own information about growing earth plants. Nadin brings up a wizard that guides her through adding her information in welformed html to the step. Once the information is to her liking, Nadin closes the wizard and deploys the unit to her class.
Requirement Builds
The purpose of the requirement builds will like an evolving production prototype. What this means different feature sets, UI layouts, etc.. will be experimented with to provided continual feedback in the evolution of the authoring tool. However, none of the code will be thrown away or developed haphazardly.
Version 0.1 RB1 - Requirements build 1 (RB1).
Version Features
- Welcome Screen
- Wizards to create spaces/folders/whatever with a project.
- Some navigation thingy that represents a folder/space/whatever and a collection of projects.
- some information view that display meta information about a project.
- Uses the Eclipse Forms where possible. Giving a 'web' feel.
Sub Iteration 0.0.1
- Create New space Wizards as part of the Authoring Tool Wizards collection.
- Create navigation thingy View
- Show created projects in thingy view as links
COMPLETED
- New Project Wizard reads xml file of units and imports them in a wizard table, user is able select a unit from the table and has the ability to name their customized unit.
- New Project Wizard creates a project and an empty unit file based on the name the user has choosen to call their customized unit in their workspace.
- Project wizard has ability to create multiple projects in a space/folder/whatever
- Information view displays project information
Version 0.2 RB2 - Requirements build 2 (RB2).
Features
- Develop project editor similar to:
- This editor will:
1. Parse a curnit xml file. DONE
2. Introspect podules and create curnit model. Under Development
3. Display podules in editor. DONE
4. Generate editor editing pages based on podule properties. DONE
5. write changed model back to file. DONE
Version 0.3 RB3 - Requirements build 3 (RB3).
1. Intergrate project creation with editing.
Future versions
- Ability to launch a wizard from a step/activity
- Ability for the step/activity to be modified from wizard input.
- more to come...
Todo's
Todo's that are needed in future iterations.
Wizards
- Error checking
- check if project or unit already exists
- if new unit is the same as orginal unit name
- specify workspace location
Project/Space Creation
- Need to come up with layout and ideas about how a space is represented in the authoring tool suing views, lists, etc....
- Questions we want ask.
- What do authors want to see on a regular basis as far as projects are concerned? Their current projects? list of interested projects? projects that they are watching?
- How would they like to access their projects or main list of projects?
- Questions we want ask.
Notes
Classloading for introspection in the authoring tool
from eclipse wiki:
How do I instantiate a class from the runtime workspace?
http://eclipsewiki.editme.com/DeveloppingPluginsWithJDT
You shouldn't. It would be very dangerous if you did this, since the class would run code in the same VM that Eclipse is running in. Imagine what would happen if it has a static initializer that does a System.exit(0)!
Usually people want to do this so that they can use reflection to find out information about the class. The org.eclipse.jdt.core package already provides a rich set of APIs to do this without loading the class, or running any untrusted code in the IDE
How can I add resources in my workspace to the classpath of a plugin at runtime?
http://eclipsewiki.editme.com/PDEFaq
That is a dangerous thing to do. First is that you are loading user code into the IDE jvm. If it has bad errors or even calls System.exit() it could cause your IDE to go down or have severe problems. Second, since each project could have a different level of jvm from what the IDE is using you can't necessarily load them in. Third, unless you use your own classloader, any classes loaded will be seen by the entire IDE and only one version of the class can be loaded, if the class is changed the new version wouldn't be loaded. Fourth, it may difficult to get rid of the instances. Sometimes things you aren't aware of hold on to instances of classes and so they won't be GC'd.
In most cases you can get the analysis you need out of the JDT and AST model, which does a pretty good job of looking at the classes.
But to answer the question directly, you must provide your own class loader which loads, e.g., from the output directory. If you have loaded a class in this way and want to reload a new version, you will have to discard the class loader and create a new one. Be careful not to keep references to class loaders, user classes or instances, or old versions will pile up in memory. You take responsibility for any instability that may result. If you ask for help, you're quite likely to get a lecture, instead. On the other hand, if you go the JDT and AST route, you'll find lots of people eager to help you learn how.
