myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "GSoC2010_MAB_Status" by TobiasU
Date Sun, 06 Jun 2010 16:55:19 GMT
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)
 ||
  

Mime
View raw message