[Myfaces Wiki] Update of "GSoC2010_MAB_Status" by TobiasU

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "GSoC2010_MAB_Status" page has been changed by TobiasU.
http://wiki.apache.org/myfaces/GSoC2010_MAB_Status?action=diff&rev1=1&rev2=2

--------------------------------------------------

  
  <<TableOfContents(4)>>
  
+ = Structure =
+ At the moment, the MAB still uses Weld but a switch to OWB is planned for the next 1-2 weeks.
+ 
+ == Configuration ==
+ To standardize the configuration of the MAB, a number of predefined types of configuration objects exist.
+ The base configuration object contains a unique identifier and a message which is shown to the user (e.g. "Project name").
+ Furthermore, different configuration objects can have different characteristics.
+ 
+ Note: this list is not complete yet - a multi line text input is missing for example
+ 
+ * Yes/No: A simple Yes/No option which can have a default setting.
+ 
+ * Text: A simple text option which can have a default text
+ 
+ * Selection: A list of elements from which the user is able to choose from. Can have a default entry selected.
+ 
+ == Plugins ==
+ There are two types of plugins. Plugins should implement one of the plugin interfaces. I haven't figured out a nice way to exclude them if they don't (maybe it's not necessary to exclude them).
+ 
+ * UI Plugins: UI plugins can be chosen by a command line argument. If none is selected or if the selection is invalid, the default shell style interface is used. The shell style interface is still very basic at the moment. UI plugins have to be able to handle the different configuration objects otherwise they won't work anyway.
+ 
+ * "Normal" Plugins: There are no restrictions for normal plugins, they just have to observe the events in the following section in order to work.
+ 
+ == Events ==
+ There are several pre-defined life-cycle events. Plugins can observe these events to execute code if they need to.
+ 
+ Note: this list is probably not complete yet
+ 
+ * Startup: The purpose of this event is to allow plugins to check if necessary prerequisites are fulfilled (for example checking if Maven or Subversion binaries are available on the system)
+ 
+ * Configuration: Event to pass configuration objects between the plugin and the central class (which passes it to the UI). It is possible for plugins to pass configuration events to other plugins in case they rely on them (qualifier with the plugin identifier)
+ 
+ * Generation: For generating the application
+ 
+ * Finalization: Allows plugins to execute final code (e.g. executing the app, starting a jetty, ...)
+ 
+ == Generation/Templating ==
+ - Todo
+ 
+ == Workflow ==
+ The MAB has a central class with the purpose of managing the workflow, communicating with the UI and other central tasks.
+ At the moment, the MAB accepts a command line argument to allow the user to choose between different UI's.
+ On startup, the central class produces a Startup event (see Events) which allows plugins to check for prerequisites. Then, the central class checks which plugins are available and tries to validate them. At the moment, the validation is very basic (uniqueness of identifiers). A plugin can disable itself it the prerequisites are not fulfilled.
+ 
+ The central class passes a list of valid plugins to the UI. The selected plugin is executed. (I still need to decide on the method: event w/ qualifier, a plugin provided event or basically just executing a method on the plugin object).
+ With an event, the plugin can pass a list of configuration objects to the central class. Central class passes it again to the UI which shows it to the user. The user input is written to the configuration objects and passed back to the plugin. If the plugin needs more configuration, it can pass another list of configuration objects to the central class and so on (for a nested configuration for example).
+ If plugin A relies on plugin B, plugin A can pass a list of configuration events to plugin B.
+ If the plugin has finished the configuration phase, it needs to notify the central class. The central class then continues with the life-cyle.
+ The next steps are the generation event which allows the plugins to generate the code for the application and after that the finalization event.
+ 
  = Status =
  ||<tablewidth="99%">'''Week'''||<:90%>'''Status'''||
- ||<:> 1 ||  ||
+ ||<:> 1-2 || Application basics (events, configuration options, dummy plugins, etc)  ||