Full credit to Steven, who is the driving power behind the JHeadstart innovations!
]]>An evaluation version of JHeadstart 11.1.1 is not yet available. We plan to make an evaluation version available in the fall of calendar year 2009.
In addition to many small enhancements, the following features have been added to the second technical preview:
${JHS.pageDefGenerator.addBinding($JHS.page,"myBinding","#CUSTOM_BINDING()")}
${JHS.pageDefGenerator.addExecutable($JHS.page,"myIterator","#CUSTOM_BINDING()")}
${JHS.pageDefGenerator.addParameter($JHS.page,"myParam","#CUSTOM_BINDING()")}
Click here for a list of features added in the first technical preview:
For a complete list of all existing features in JHeadstart 10.1.3, use this link.
]]>Full credit to Steven, who is the driving power behind the JHeadstart innovations!
]]>The "poor-man's solution" to this problem is adding nested item nodes to the XML Menu Model for the detail pages. This technique is easy but can only be applied when there is no page-specific submenu that should be displayed with the pages. You simply create child itemNodes in the XML Menu model for the detail pages in the task flow, which will never be displayed as menu items because you do not include an af:navigationPane that displays this menu level.
A more sophisticated solution, that allows for page-specific submenus, is to subclass XMLMenuModel. The subclass looks up a MenuViewIdMapping managed bean that maps all viewIds of the secondary pages in the task flow to the viewId of the primary page that is defined as focusViewId in the XML Menu Model file.
Here are the steps to implement this technique:
1. Create a subclass of org.apache.myfaces.trinidad.model.XMLMenuModel and override method getFocusRowKey as follows:
public Object getFocusRowKey()
{
// first check whether default behavior results in focus of some menu item
Object focusRowKey = super.getFocusRowKey();
if (focusRowKey!=null)
{
return focusRowKey;
}
Map
// check whether there is a menu mapping for the current viewId
Map viewIdMapping = getViewIdMapping();
String viewId = FacesContext.getCurrentInstance().getViewRoot().getViewId();
if (viewIdMapping!=null && viewIdMapping.get(viewId)!=null)
{
String mappedViewId = (String) viewIdMapping.get(viewId);
List
Add the following helper method:
public Map getViewIdMapping()
{
ExpressionFactory ef =
FacesContext.getCurrentInstance().getApplication().getExpressionFactory();
ELContext context = FacesContext.getCurrentInstance().getELContext();
return (Map) ef.createValueExpression(context
,"#{pageFlowScope.MenuViewIdMapping}"
, Map.class).getValue(context);
}
2. Change the menu bean property managed-bean-class to reference your subclass:
<managed-bean>
<description>Menu Model Managed Bean</description>
<managed-bean-name>root_menu</managed-bean-name>
<managed-bean-class>view.MyXMLMenuModel</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>createHiddenNodes</property-name>
<value>false</value>
</managed-property>
<managed-property>
<property-name>source</property-name>
<property-class>java.lang.String</property-class>
<value>/WEB-INF/root_menu.xml</value>
</managed-property>
</managed-bean>
3. In each taskflow that can be launched from a menu item, add a managed bean named "MenuViewIdMapping" that defines the mapping between secondary pages and the page defined as focusViewId in the XML Menu Model. Here is an example:
<managed-bean>
<managed-bean-name>MenuViewIdMapping</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>pageFlow</managed-bean-scope>
<map-entries>
<map-entry>
<key>/task-flow-definition1/BoundedTaskFlow1DetailPage</key>
<value>/task-flow-definition1/BoundedTaskFlow1Page</value>
</map-entry>
<map-entry>
<key>/task-flow-definition1/BoundedTaskFlow1AnotherDetailPage</key>
<value>/task-flow-definition1/BoundedTaskFlow1Page</value>
</map-entry>
</map-entries>
</managed-bean>
That's it. You can download a sample workspace that illustrates the solution here. In a later post, we will discuss the solution for the "one-page application" design with dynamic regions. In that scenario the correct menu item should be highlighted based on the currently selected dynamic region.
The "poor man's" solution to this problem is hiding or disabling all menu items and other global actions that will launch a bounded task flow (like "Help" and "Preferences") until the user executes a bounded task flow return action and returns to a page in the unbounded task flow. Not a very user friendly solution....
Another technique is to use a bounded taskflow template for all your bounded task flows. In the template you duplicate all control flow rules and all task-flow call activities that are defined in the unbounded task flow. While this might seem to work at first sight, this is not a viable option. What happens with this approach is that each time you click on another menu item, a new bounded sub task flow is started in the context of the current task flow: in other words, you keep on nesting bounded task flows. This is highly undesirable and will cause problems sooner or later with memory resources and/or transaction management. Since the task flows are nested, taskflow resources are never released, and transactions are never rolled back. Don't do this!
The only proper solution is to execute a return activity to quit the current task flow before starting the new bounded task flow. In this post, I will describe how you can implement this in a generic way which hides the complexity for your developers. The outline of the solution is as follows:
Here are the detailed steps to implement this:
1. Prefix the value of the action property in all your menu items in XML MenuModel with "abandon:"
2. Create a custom navigation handler with the following code:
public class MyNavigationHandler
extends NavigationHandlerImpl
{
public static final String ABANDON_PREFIX = "abandon:";
private static final String CURRENT_MENU_ITEM = "currentMenuItem";
private static final String CALL_MENU_ITEM = "CallMenuItem";
public MyNavigationHandler(NavigationHandler navHandler)
{
super(navHandler);
}
public void handleNavigation(FacesContext facesContext, String action,
String outcome)
{
if (outcome != null && outcome.startsWith(ABANDON_PREFIX))
{
abandonTaskFlowIfNeeded(facesContext, action, outcome);
}
else
{
super.handleNavigation(facesContext, action, outcome);
}
}
public void abandonTaskFlowIfNeeded(FacesContext facesContext,
String action, String outcome)
{
String strippedOutcome =
outcome.substring(MyNavigationHandler.ABANDON_PREFIX.length());
TaskFlowContext tfc =
ControllerContext.getInstance().getCurrentViewPort().getTaskFlowContext();
if (tfc.getTaskFlowId() == null)
{
// we are not in a bounded task flow, do normal navigation
handleNavigation(facesContext, action, strippedOutcome);
}
else
{
String newOutcome = strippedOutcome;
Map requestMap =
FacesContext.getCurrentInstance().getExternalContext().getRequestMap();
requestMap.put(CURRENT_MENU_ITEM, newOutcome);
handleNavigation(facesContext, null, CALL_MENU_ITEM);
}
}
}
3. Register your custom navigation handler in the faces-config.xml. Go to the Overview tab, click on Application, and set your class name in the navigation handler property.
4. Create a bounded taskflow template used by all your bounded task flows, and add the following code to it:
<task-flow-return id="CallMenuItem">
<outcome>
<name>CallMenuItem</name>
</outcome>
</task-flow-return>
<control-flow-rule>
<from-activity-id>*</from-activity-id>
<control-flow-case>
<from-outcome>CallMenuItem</from-outcome>
<to-activity-id>CallMenuItem</to-activity-id>
</control-flow-case>
</control-flow-rule>
</task-flow-template>
When using declarative transaction management, you can add that a rollback should be performed as part of the return activity.
5. Create a Java class named DynamicRouter with the following code:
public class DynamicRouter implements Serializable
{
public String getOutcome(String outcome)
{
return outcome;
}
}
6. Add the following code to adfc-config.xml (the unbounded task flow):
<method-call id="CallMenuItem">
<method>#{dynamicRouter.getOutcome}</method>
<parameter>
<class>java.lang.String</class>
<value>#{requestScope.currentMenuItem}</value>
</parameter>
<outcome>
<to-string/>
</outcome>
</method-call>
<control-flow-rule>
<from-activity-id>*</from-activity-id>
<control-flow-case>
<from-outcome>CallMenuItem</from-outcome>
<to-activity-id>CallMenuItem</to-activity-id>
</control-flow-case>
...
</control-flow-rule>
<managed-bean>
<managed-bean-name>dynamicRouter</managed-bean-name>
<managed-bean-class>view.DynamicRouter</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
That's it. You can download a sample workspace that illustrates the solution here. In a later post, we will discuss how to add an alert to warn the end user about unsaved changes when he abandons a task flow.
These new possibilities imply that new design decisions must be made on how to build the required functionality. This is not a trivial task. Many of the concepts relate to each other, and choosing how to use one concept can have impact on the usage of other concepts. I admit that's pretty vague, but in this new "Core ADF 11" series, we (the JHeadstart team) will try to make this more concrete. In this series we will share with you the experiences, issues, challenges, design considerations, design decisions and best practices that we faced/encountered/developed when building JHeadstart release 11.
Note that we will assume that you have a basic understanding of the new ADF 11 concepts. If this is not the case, we recommend you take the ADF 11 course from Oracle University, or if you prefer self-study, take a look at the ADF Learning Center.
In this first post, we will start at the beginning: you want to build your first "serious" ADF 11 page, and you immediately need to choose: do I create a page or a page fragment, do I base the page (fragment) on a template, and do I put the page in an unbounded or bounded task flow.
Page Templates
This one is easy: we recommend to always use a page template. Design the template whatever way you want but make sure you include all the UI elements that need to be displayed on each and every page. Typical content of a page template include a branding image/application logo, global actions like Home, Help, Log Out, Preferences, the menu of the application (either a tree menu, or various levels of navigation panes like tabs, buttons or lists) and a footer area with for example a copyright message. Use page template attributes to pass in properties that might differ between pages like the page title, and to conditionally show/hide parts of the page template for specific pages. In a later post, we will go into more details on designing page templates.
Note that you can also dynamically change the page template associated with a page at runtime. Instead of hardcoding the page template path, you can use an EL expression that binds to a look and feel bean that contains the current page template path.
Bounded or Unbounded Taskflows
Each ADF 11 web application has one unbounded taskflow, and can have one or more bounded task flows. So, the choice is not so much about using bounded or unbounded task flows, but about putting a JSF page inside the unbounded taskflow, or inside a bounded task flow.
When building transactional applications, bounded task flows have major advantages over unbounded task flows. For a start, bounded task flows support additional features that can be very useful when building transactional applications:
In addition, bounded task flows allow you to benefit from concepts well-known in the world of object oriented programming and component-based development. Using bounded task flows:
In short, well-designed bounded task flows have many advantages over the unbounded task flow. We recommend to only use the unbounded task flow for introductionary pages like the home page or a UI shell page when using regions (see below). All application uses cases should be implemented using a bounded task flow. In a later post in this series, we will discuss in more detail how to design your task flows for maximum reusability.
Stand-alone Pages or Page Fragments with (Dynamic) Regions
For your page design, you basically have three choices
Some considerations and implications to take into account for each choice:
Stand-alone pages:
Static regions with shell page:
One-page application:
With the previous design option, a shell page is created for each ADF region. Typically, all these shell pages will be very thin and very similar: they are based on the same page template that renders the menu and other common page components, the only difference is the name of the ADF region that is embedded in the shell page. In a one page application, we create one UI Shell page and use a dynamic region to display the correct region. Here are the implications:
Summary
While JDeveloper makes it easy to later on convert stand-alone pages to fragments, and unbounded task flows to bounded task flows, it is better to make these design decisions upfront. The choices you make have impact on the usage of XMLMenuModel, menu-driven navigation in general, reusability, transaction management and performance.
We recommend to use bounded task flows with page fragments to maximize reusability. While traditional transactional applications are mostly menu-driven, composite, task-oriented user interfaces are likely to become mainstream in the future. When you start building your ADF 11 app today using (dynamic) regions accessible from a menu, you can reuse the same task flows when building more task-oriented user interfaces using the WebCenter and Human Workflow capabilities planned for JDeveloper 11 release 2.
An evaluation version of JHeadstart 11.1.1 is not yet available. We plan to make an evaluation version available in the fall of calendar year 2009.
In addition to many small enhancements, the following features have been added in JHeadstart 11.1.1:
From the Javadoc of EntityImpl: Note that if a Posting operation is performed, and the attribute value is sync'd with the database, that subsequent requests will return false, until the next time the attribute is changed.
As Jan Kettenis pointed out, this means that if you use isAttributeChanged for a business rule that is triggered at Commit time, it will always return false, even though the attribute was changed. Jan describes a workaround for this problem.
Another quote from the Javadoc of EntityImpl: Note that this method will return true if the value has been set to the same as the database value since it doesn't perform a value comparison.
This can be a problem for validations that apply only when the value changes: for example, the rule "Department Name cannot be changed if the Department has Employees". You might have implemented the rule in a method validator using isAttributeChanged:
return (!isAttributeChanged(DEPARTMENTNAME) || !hasEmployees());
Suppose a Department has Employees, and you change both the Department Name and the Department Manager. When you apply these changes, you obviously get an error because you are not allowed to change the Department Name. Suppose you now change the Department Name back to its original value, and try again, because you still want to change the Department Manager. You will still get the error, because isAttributeChanged(DEPARTMENTNAME) will remain false until you have posted the data, even though the attribute value is now the same as the value in the database!
To avoid this, you can define a variation on isAttributeChanged in your EntityImpl base class: isAttributeValueChanged (but note that when called from Commit level, it will still return false like Jan described).
/**
* Using getPostedAttribute and getAttribute this method retrieves the old and new
* values and compares whether it has changed. Alternative to isAttributeChanged,
* which returns true if the value was modified to the same value as the database.
* @param index index of the attribute.
* @return true if the value of the attribute at the given index
* is different from the one in the database.
*/
public boolean isAttributeValueChanged(int index) {
Object oldVal = getPostedAttribute(index);
Object newVal = getAttribute(index);
boolean valueChanged = true;
if ((oldVal == null) && (newVal == null)) {
valueChanged = false;
} else if (newVal != null) {
if (newVal instanceof String) {
if (((String)newVal).length() == 0) {
if (oldVal == null) {
valueChanged = false;
}
}
}
if (valueChanged && newVal.equals(oldVal)) {
// in new rows, the oldVal is always the same as the newVal,
// but if the value is not null in a new row, we want to return true
if (getEntityState() != Entity.STATUS_NEW) {
valueChanged = false;
}
}
}
return valueChanged;
}]]>
When you click the "Explore Now" button, you see a very nice tree with topics, where you can flip each node to see a small explanation, or expand it to see new nodes with subtopics.
There are still seats available. For a list of course topics and registration, use this link.
]]>
What are Business Rules?Let me first explain what I mean by business rules in this context. Business rules are used to preserve data integrity, to prevent inconsistent data from being entered into the database. They are checks and/or data corrections you want to perform in your entity objects, triggered by an insert, update or delete of certain data. The most common ones are validation rules or constraints: if the data changes do not satisfy a certain integrity rule, you return an error. For example: the End Date may not be before the Start Date. Another category of business rules is change event rules: if a certain change is made, you automatically want another change in the data to be made as well. For example: automatically converting a Code to uppercase (so that the integrity rule that a Code must be uppercase is implicitly maintained). The white paper Business Rules in ADF BC defines business rules as follows (in the intro of section 6, "Business Rule Classification Scheme"):
|
|
In Oracle JDeveloper 11g, ADF BC offers several new features for declarative validation rules support (see also the JDeveloper 11g New Features list):
)
Let me describe the ADF BC techniques (with links to relevant sections in the Fusion Developer's Guide for ADF or to paragraphs below) that I refer to later in this post, in order of preference. In fact, I have two lists of preferred techniques, depending on the question: Should the rule be implemented for more than one entity?
If the answer is Yes, the rule should be implemented in more than one entity, then my preferred techniques are:
If the answer is No, the rule should be implemented in only one entity, then my preferred techniques are:
(validates based on aggregate values in a collection)
(checks cache and database to see if value exists as a key in a
certain entity, useful for logical Foreign Keys that are not checked in the database)
(business-logic tier equivalent of a unique constraint in the
database)
(declarative validation rule used for creating Groovy validation
expressions). Applicable if
the Groovy syntax and constructs, see
Section
3.6
Overview
of
Groovy
Support,
are powerful enough to implement the rule, and the expression is
limited in length.
Now these lists need a little explanation. Why do I prefer these, and when can or can't you use one of these techniques?
My preferences for certain techniques are based on the following assumptions:
This avoids very large EntityImpl classes, in which it is hard to keep track of what was generated by ADF BC and what was added by you. If you follow these principles, there are only a few superclass methods that are likely to be customized (see Section 8.1 Introduction to Programmatic Business Rules). |
|
The preferred techniques mentioned above may or may not be possible, depending on the type of business rule you need to implement. Besides the decision if the rule should be implemented for more than one entity or not, what matters as well is the complexity of the rule, and at which point in the ADF Entity Object's validation cycle it needs to be triggered.
What you need to remember is that all techniques, except coding directly in the EntityImpl class, can only be called at the time a single Entity row is validated, or at the time all Entity rows are committed (the latter occurs if you defer the execution to transaction level, using a setting in the Entity "Add Validation Rule" dialog). That is the equivalent of overriding the entity superclass methods validateEntity or beforeCommit.
However, sometimes you need to trigger the rule from the superclass methods doDML, remove, or some other method. The Rule Classification Scheme of the Business Rules in ADF BC white paper can help: for the rule types "Delete", "Collection, no parent", "Collection within parent", "Change event with DML", and "Change Event without DML", it might not be possible to trigger them at validate or commit time.
Furthermore, validation rules are often not suitable for change event rules (that trigger a data change in some other attribute or entity). It might interfere with the Validation Cycle (see Section 7.2 Understanding the Validation Cycle).
The complexity of the rule determines if it is possible to implement it using one of the most preferred techniques, like a Compare validator or a Range validator. If that is not possible, it might be possible to implement it using a Groovy Script validator. If that is not possible, it might be possible to implement it with a Method Validator with a small number of lines of Java code in the method, etcetera.
If you apply all of these guidelines, you have the following summary algorithm for determining the best rule technique:
See the Fusion Developer's Guide for Oracle Application Development Framework Section 34.10: Implementing Custom Validation Rules. Essentially you create a new Java class that extends AbstractValidator and implements the JboValidatorInterface. This forces you to implement a method validate(JboValidatorContext). You can specify custom rule properties for the things that vary if you need to implement this rule for more than one entity or attribute.
If the rule must be triggered at commit time as opposed to validate time, you must also implement the JboTransValidatorInterface. This forces you to implement a method validateMany in addition to validate, but in our test case it was never called, even if you set the "Defer execution to transaction level" when assigning the rule to an entity or attribute. Still, a logical implementation of this method would be to loop over all JboValidatorContexts and call validate for each:
public void validateMany(ArrayList valCtxs) {
JboValidatorContext evObj;
for (int i = 0; i < valCtxs.size(); i++)
{
evObj = (JboValidatorContext) valCtxs.get(i);
validate(evObj);
}
}
When you have written the Java class, you must register it as a rule in your Model project, and then you can declaratively assign it to one or more entities, possibly setting some entity-specific properties for the rule. Those properties can be exposed simply by creating getters and setters for them in the Java class.
Note: if the rule should be applied to all Entity Objects, without any specific properties to configure for each individual entity, then it is easier to use the technique of Overriding a method in EntityImpl, so you don't have to do any work in the individual entities.
Note 2: You could also use the JboValidatorInterface when the trigger time is not validateEntity or commit, but it requires instantiating a JboValidatorContext like this:
JboValidatorInterface businessRule = new MyCustomValidator();
JboValidatorContext entityContext =
new JboValidatorContext(JboValidatorContext.TYP_ENTITY_OBJECT,
this, getEntityDef().getFullName(), null,
null, this);
businessRule.validate(entityContext); I find this less intuitive then the technique described below, and you don't have the added value that declarative rules have like traceability, bundling exceptions, and allowing changes through MDS. Besides, this codes gives a compiler warning, and it is not clear to me what the alternative for the deprecated constructor is:
constructor JboValidatorContext(int, java.lang.Object, java.lang.String, oracle.jbo.AttributeDef, java.lang.Object, java.lang.Object) has been deprecated
It works fine, though, so if you like it you can use this approach instead of the one described in How to apply OO Principles in EntityImpl.
Thank you Steve Muench and Jan Kettenis for helping me to position this technique in 11g.
This paragraph explains how I applied the Object Oriented Design Principles "Encapsulate what varies" and "Program to interfaces, not implementations", with the help of my colleague Gaurav Malhotra. I found that it helps separate out the rule implementation code from the Business Components classes, and clarifies the communication between the classes by using interfaces for different types of rules, if you want to use the technique of overriding a method in EntityImpl. In fact, the Custom Validator technique (see How to create a Custom Validator) also applies these OO principles.
Note: if the rule applies to multiple entities but not exactly the same for each entity, you can use Custom Properties in the individual entities to configure your business rule.
One of the most complex rules we had in a large project involved a private helper class, several static final constants, and several helper methods that need to be called several times. So you can imagine that it is not a good idea to put all that code in the EntityImpl class, mixed in with the code for other rules and/or the ADF BC framework generated code.
Borrowing a phrase from Antonio García's description of the Strategy Pattern, it is much simpler to keep track of them if each behaviour (in our case business rule) is a separate class, and not buried in the body of some method. That is how I interpreted the principle "Encapsulate what varies".
Now, in the business rule logic we probably have to call several EntityImpl methods for the row that triggered the rule, like the entity's getters, or the superclass generic getAttribute method. How do you do that if the rule logic is in a separate class?
The answer is: inject the Entity row into the rule class, using a setEntity method. The rule class can then call entity methods by coding getEntity().someMethod(). This way you can also retrieve values of Custom Properties of Entities in case of generic rules that apply to multiple entities: getEntity().getEntityDef().getProperty(customPropertyName).
Then, apply the "Program to Interfaces" principle by specifying an interface that defines which rule class methods should be callable from the EntityImpl class and which not. If you have multiple rules that have to be implemented in the EntityImpl, you can probably re-use the same interface for several rules.
An example of such an interface is the general-purpose EntityRule interface (note the use of a Java 5 generic method):
public interface EntityRule<T> {
public void setEntity(T entity);
public void process();
}An implementation of this interface might be:
public class MyComplexRuleImpl implements EntityRule<MyEntityImpl>
You call the rule by coding in the appropriate method of your MyEntityImpl class:
EntityRule myComplexRule = new MyComplexRuleImpl();
myComplexRule.setEntity(this);
myComplexRule.process();Of course you can have multiple RuleImpl classes each representing a different Entity Rule, which can be called from different places in the EntityImpl.
Using this approach you can give complex rules their own class, while still allowing calls to framework methods like the Entity's getters. In the rule class you can throw an exception if the validation fails. The use of an interface makes it clear how to call such a rule, without knowing the inner workings of the rule.
]]>The solution I found can be applied to any situation where you cannot easily influence the source code but still want to write some logging about the values of Java variables and method arguments. You can apply it to frameworks for which you have read-only access to the source code, like ADF and JHeadstart.
I didn't realize at first that JDeveloper 10.1.3 and JDeveloper 11 have an interesting debug feature called BreakPoint Actions. You can set breakpoints and configure them in such a way that they don't halt execution, but only write something to the log. That something can be the value of a Java variable or some other Java expression. So I let it write to the log which EL-expressions it was parsing, and then I could easily check which expression was written just before the NullPointerException.
Here is how you can add your own debug message (with values of class variables) to a (framework) class without having to modify any Java code:
A working set allows you to define a set of files (a subset of project source path contents) that you want to work with. For large projects, you may want to work with a small subset of the source files (for example, all the files in a given package, plus a few others). Typically, you would perform the following actions scoped to the working set:
When you have defined some useful working sets, you may want to exchange them with your fellow development team members. 2 years ago I blogged about how to share JDeveloper 10.1.3 Working Sets with your team, and here is how to do that in JDeveloper 11.
public void setLovSearchBean (JhsSearchBean lovSearchBean){
JhsSearchBean lsb = lovSearchBean;
if(lsb!=null && (lsb.getSearchText()!=null || lsb.getCriteria().size()>0)) {
lsb.setSearchText(null);
lsb.getCriteria().clear();
lsb.quickSearch();
}
super.setLovSearchBean(lovSearchBean);
}
Only when SearchText object is not null or Criteria object is not empty, the search criteria is cleared (lsb.setSearchText(null) lsb.getCriteria().clear()) and the search with no filter values is re-executed (lsb.quickSearch()).
<managed-bean>
<managed-bean-name>${bean.beanName}</managed-bean-name>
<managed-bean-class>new LovItemBean class created</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
…
</managed-bean>
See section 4.7 of the JHeadstart Developer's Guide for more information about customizing generator templates.
I will be hanging out on the campgrounds around the JDeveloper booth on wednesday september 24 from 11.00-13.30. So, if you are at OOW and missed my presentation, or want to see more, just step by and I am happy to tell and show everything about JHeadstart.
]]>